From 1d39ff5c0848b984bd6ef76fd421b72b5c9a79ff Mon Sep 17 00:00:00 2001 From: khaga87 Date: Tue, 13 Oct 2026 19:51:37 +0100 Subject: [PATCH 1/8] Tooling: Update copy **Summary** - Update the wording around our tooling to be clearer about what it is doing with less hyperbole **Testing** - Ran the site locally to make sure it worked Signed-off-by: khaga87 --- src/content/docs/tooling/index.mdx | 49 ++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 10 deletions(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index 4d4cd148..405a37b9 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -8,28 +8,57 @@ tableOfContents: false --- import { Card, CardGrid } from '@astrojs/starlight/components'; +As part of our mission statement, we first want "to build modern, ergonomic and high-performance tooling and infrastructure for distribution engineering." -Here at aerynOS, we love good tooling. Our language of choice is [Rust](https://rust-lang.org) for creating lightning quick tooling with high cadence feature work and minimal debt. Our belief is that by providing great tooling, the overall maintainer load is greatly reduced, allowing everyone to enjoy a greater developer and user experience. +Simply put, we are building the tooling and infrastructure that will deliver, as an output, "an atomic operating system that is fast, predictable, reliable and a joy to use and maintain." +Rather than relying entirely on existing distribution tooling, we are developing our own tools in-house, primarily in [Rust](https://rust-lang.org). + +By taking a ground up approach, we are able to build the focused tooling we want and need to deliver the type of atomic distribution we want without any prior technical debt. + +The code is therefore focused, maintainable and efficient leading to a better experience for our developers and eventually a better user experience also. + +## Core system tooling + +Our primary tooling that make the foundation of aerynOS: {/* */} - - The star of the show is certainly moss, the package and system management tool. With **atomic updates** and **deduplication** at the core of the design, it delivers with performance and reliability. + + `moss` manages the installation and removal of software through atomic transactions. Behind `moss` we have a deduplicated content-addressable store (CAS) that allows files to be shared between system states (transactions) which in turn allows for aerynOS to store all previous system states for easy rollbacks without requiring full system snapshots. - [read more](/tooling/moss) + [Learn more about moss](/tooling/moss) - - The build partner for moss is boulder, an extremely powerful, flexible and easy to use package build tool. Making use of a simple `YAML` format and enriched shell scripts, building consistent packages has never been easier. + + `boulder` turns `YAML` based package recipes into `.stone` packages for `moss` to install on aerynOS systems. It has been designed to include a consistent build environment, reusable packaging macros, dependency handling and caching to help our maintainers package and update our growing software repository. - [read more](/tooling/boulder) + [Learn more about boulder](/tooling/boulder) - - Nobody should need to manage their boot configuration manually. That's exactly why moss leverages the blsforme project to automatically manage the EFI System Partition (and `XBOOTLDR`..) and manage boot entries. + + Nobody should need to manage their boot configuration manually. That's exactly why `moss` leverages the blsforme project to automatically manage the EFI System Partition (and `XBOOTLDR`..) and manage boot entries. - [read more](https://github.com/aerynOS/blsforme) + [Learn more about blsforme](https://github.com/aerynOS/blsforme) {/* */} + +## How it all fits together + +We are building our tooling so that they work together to become more than the sum of their individual parts: + +1. Our recipes repository contains the `YAML` based recipes that we use to describe how software is packaged for aerynOS. + +2. `boulder` uses these recipes to build the packages and outputs them as `.stone` package archives. + +3. Our build infrastructure coordinates our various builders that use `boulder` to build packages centrally in a controlled manner. + +4. Once built, packages are immediately published to our volatile repository. After a period of testing, packages are then promoted to our unstable repository. The repository makes package versions and their associated metadata available to the system. + +5. `moss` checks for available updates to the repositories it is subscribed to. When updates are available, it will download the corresponding `.stone` package archives, extract them to it's CAS and then create a new system state which it will swap to as part of it's atomic transaction. + +6. `blsforme` works within the wider context of an installed aerynOS system to handle boot management to ensure the system is bootable regardless of underlaying updates. + +:::note +Whilst we currently use `YAML` based recipes, we are actively investigating a transition towards `KDL` based recipes. From 68d8dd4551fe40d9d9d6a3eaf30f0ce40c048c23 Mon Sep 17 00:00:00 2001 From: khaga87 Date: Wed, 14 Oct 2026 12:17:17 +0100 Subject: [PATCH 2/8] Update src/content/docs/tooling/index.mdx Co-authored-by: Rune Morling --- src/content/docs/tooling/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index 405a37b9..b4fbe10d 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -25,7 +25,7 @@ Our primary tooling that make the foundation of aerynOS: {/* */} - `moss` manages the installation and removal of software through atomic transactions. Behind `moss` we have a deduplicated content-addressable store (CAS) that allows files to be shared between system states (transactions) which in turn allows for aerynOS to store all previous system states for easy rollbacks without requiring full system snapshots. + `moss` manages the installation and removal of software through atomic transactions. Behind `moss` we have a deduplicated content-addressable store (CAS) that enables files to be shared between system states (transactions) which in turn enables aerynOS to store as many previous system states for easy rollbacks as free disk space allows. [Learn more about moss](/tooling/moss) From 70a7319c61773eeaecbc2c3341594b1dcbc8ee70 Mon Sep 17 00:00:00 2001 From: khaga87 Date: Wed, 14 Oct 2026 12:17:51 +0100 Subject: [PATCH 3/8] Update src/content/docs/tooling/index.mdx Co-authored-by: Rune Morling --- src/content/docs/tooling/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index b4fbe10d..33836903 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -46,7 +46,7 @@ Our primary tooling that make the foundation of aerynOS: ## How it all fits together -We are building our tooling so that they work together to become more than the sum of their individual parts: +We are building our tools so that they work together to become more than the sum of their individual parts: 1. Our recipes repository contains the `YAML` based recipes that we use to describe how software is packaged for aerynOS. From 439cdf17f2d3cc9f69904cc5d455073f06b9b5bd Mon Sep 17 00:00:00 2001 From: khaga87 Date: Wed, 14 Oct 2026 12:18:06 +0100 Subject: [PATCH 4/8] Update src/content/docs/tooling/index.mdx Co-authored-by: Rune Morling --- src/content/docs/tooling/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index 33836903..bd904a70 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -50,7 +50,7 @@ We are building our tools so that they work together to become more than the sum 1. Our recipes repository contains the `YAML` based recipes that we use to describe how software is packaged for aerynOS. -2. `boulder` uses these recipes to build the packages and outputs them as `.stone` package archives. +2. `boulder` uses these recipes to build and emit `.stone` package archives. 3. Our build infrastructure coordinates our various builders that use `boulder` to build packages centrally in a controlled manner. From c96d3a6804da70b93200ca423bca0b5e3959bd6e Mon Sep 17 00:00:00 2001 From: khaga87 Date: Wed, 14 Oct 2026 12:19:03 +0100 Subject: [PATCH 5/8] Update src/content/docs/tooling/index.mdx Co-authored-by: Rune Morling --- src/content/docs/tooling/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index bd904a70..9fc238c0 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -52,7 +52,7 @@ We are building our tools so that they work together to become more than the sum 2. `boulder` uses these recipes to build and emit `.stone` package archives. -3. Our build infrastructure coordinates our various builders that use `boulder` to build packages centrally in a controlled manner. +3. Our build infrastructure coordinates which tasks from the centrally managed build queue are sent to which builders and in which order. 4. Once built, packages are immediately published to our volatile repository. After a period of testing, packages are then promoted to our unstable repository. The repository makes package versions and their associated metadata available to the system. From 7bc16b2b1a1abc72b4caade7c0dfbb3b7994cce4 Mon Sep 17 00:00:00 2001 From: khaga87 Date: Wed, 14 Oct 2026 12:19:23 +0100 Subject: [PATCH 6/8] Update src/content/docs/tooling/index.mdx Co-authored-by: Rune Morling --- src/content/docs/tooling/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index 9fc238c0..7ff7bf4f 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -54,7 +54,7 @@ We are building our tools so that they work together to become more than the sum 3. Our build infrastructure coordinates which tasks from the centrally managed build queue are sent to which builders and in which order. -4. Once built, packages are immediately published to our volatile repository. After a period of testing, packages are then promoted to our unstable repository. The repository makes package versions and their associated metadata available to the system. +4. Once built, packages are immediately published to our volatile repository. After a period of testing, packages are then promoted to our unstable repository. The repository makes package versions and their associated metadata available to `moss`-based installs. 5. `moss` checks for available updates to the repositories it is subscribed to. When updates are available, it will download the corresponding `.stone` package archives, extract them to it's CAS and then create a new system state which it will swap to as part of it's atomic transaction. From 7b9b001c1bcaa352351afae79ac08439a7025724 Mon Sep 17 00:00:00 2001 From: khaga87 Date: Wed, 14 Oct 2026 12:19:52 +0100 Subject: [PATCH 7/8] Update src/content/docs/tooling/index.mdx Co-authored-by: Rune Morling --- src/content/docs/tooling/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index 7ff7bf4f..49b75fab 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -58,7 +58,7 @@ We are building our tools so that they work together to become more than the sum 5. `moss` checks for available updates to the repositories it is subscribed to. When updates are available, it will download the corresponding `.stone` package archives, extract them to it's CAS and then create a new system state which it will swap to as part of it's atomic transaction. -6. `blsforme` works within the wider context of an installed aerynOS system to handle boot management to ensure the system is bootable regardless of underlaying updates. +6. `blsforme` works within the wider context of an installed aerynOS system to handle boot management to ensure the system is bootable regardless of underlying updates. :::note Whilst we currently use `YAML` based recipes, we are actively investigating a transition towards `KDL` based recipes. From 0324e90bb6d7cd0777987d55d1f1d2081eb8b63d Mon Sep 17 00:00:00 2001 From: khaga87 Date: Wed, 14 Oct 2026 12:20:15 +0100 Subject: [PATCH 8/8] Update src/content/docs/tooling/index.mdx Co-authored-by: Rune Morling --- src/content/docs/tooling/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/tooling/index.mdx b/src/content/docs/tooling/index.mdx index 49b75fab..c2a47715 100644 --- a/src/content/docs/tooling/index.mdx +++ b/src/content/docs/tooling/index.mdx @@ -56,7 +56,7 @@ We are building our tools so that they work together to become more than the sum 4. Once built, packages are immediately published to our volatile repository. After a period of testing, packages are then promoted to our unstable repository. The repository makes package versions and their associated metadata available to `moss`-based installs. -5. `moss` checks for available updates to the repositories it is subscribed to. When updates are available, it will download the corresponding `.stone` package archives, extract them to it's CAS and then create a new system state which it will swap to as part of it's atomic transaction. +5. `moss` checks for available updates to the repositories it is subscribed to. When updates are available, `moss` will download the corresponding `.stone` package archives, extract them to its CAS and then create a new system state which it will swap to as part of its atomic transaction. 6. `blsforme` works within the wider context of an installed aerynOS system to handle boot management to ensure the system is bootable regardless of underlying updates.