diff --git a/src/content/docs/AerynOS/contribute.mdx b/src/content/docs/AerynOS/contribute.mdx
index 3091001d..b25a0b89 100644
--- a/src/content/docs/AerynOS/contribute.mdx
+++ b/src/content/docs/AerynOS/contribute.mdx
@@ -18,7 +18,7 @@ We currently accept donations via [Ko-Fi](https://ko-fi.com/aerynos).
## Contributing to our codebases
-AerynOS utilizes GitHub to manage code changes, including updates our our websites. Each repository will have its own Readme that will include instructions on how to make updates to it. They can be found [here](https://github.com/orgs/AerynOS/repositories). To specifically make contributions to our websites, you can visit the following repositories:
+AerynOS utilizes GitHub to manage code changes, including updates to our websites. Each repository will have its own Readme that will include instructions on how to make updates to it. They can be found [here](https://github.com/orgs/AerynOS/repositories). To specifically make contributions to our websites, you can visit the following repositories:
- AerynOS.com site [repo](https://github.com/AerynOS/dotdev)
- AerynOS.dev site [repo](https://github.com/AerynOS/dotcom)
diff --git a/src/content/docs/AerynOS/faq.mdx b/src/content/docs/AerynOS/faq.mdx
index 1979e0e1..1a7c2189 100644
--- a/src/content/docs/AerynOS/faq.mdx
+++ b/src/content/docs/AerynOS/faq.mdx
@@ -14,7 +14,7 @@ import { Aside } from "@astrojs/starlight/components";
### What does AerynOS mean and how do I pronounce it?
-AerynOS is a stylised spelling of "Erin", alluding to the project's Irish roots. It is pronounced exactly the same as "Erin" - "AIR-in" OS. It's also a play on "aer" and the phonetic "air" sound, indicative of our desire to produce an open, trusted and high-performance operating system.
+AerynOS is a stylized spelling of "Erin", alluding to the project's Irish roots. It is pronounced exactly the same as "Erin" - "AIR-in" OS. It's also a play on "aer" and the phonetic "air" sound, indicative of our desire to produce an open, trusted and high-performance operating system.
It's pronounced as "AIR-in" OS.
@@ -36,7 +36,7 @@ Checking the currently supported x86_64 psABI feature level of a system can be d
### Does AerynOS offer NVIDIA GPU support?
-Due to the way NVIDIA distributes its drivers, maintaining them in a distro is labour intensive and frustrating when they do not work as advertised.
+Due to the way NVIDIA distributes its drivers, maintaining them in a distro is labor-intensive and frustrating when they do not work as advertised.
Given AerynOS is in the Alpha development stage, only limited, best effort NVIDIA enablement related to cards supported by the so-called nvidia-open-gpu-kernel-modules is currently offered.
@@ -55,12 +55,12 @@ You have been warned.
In practice, we recommend that you install AerynOS to a separate drive with:
- A >=256MB ESP FAT32 partition (type 1 in fdisk).
- - This must be manually formatted for the installer to recognise it.
+ - This must be manually formatted for the installer to recognize it.
- A 4GB XBOOTLDR FAT32 partition (type 142 in fdisk, bls_boot in gparted).
- - This must be manually formatted for the installer to recognise it.
+ - This must be manually formatted for the installer to recognize it.
- This partition is large, because it is where the AerynOS kernel+initramfs and (in the future) rescue image files will be saved.
- A >20 GB system xfs partition
- - This must be manually formatted for the installer to recognise it.
+ - This must be manually formatted for the installer to recognize it.
- The larger the xfs system (/ or root) partition is, the more OS /usr directory rollback states it can support in /.moss/.
```
@@ -88,7 +88,7 @@ nvme1n1
ermo@virgil:~
```
-NB: Remember, there is nothing stopping you from creating an extra partition, formatting it with a filesystem of your choice, and then configuring /etc/fstab to mount it as /home after AerynOS has been installed, if you want to use a different filesystem than xfs for your /home folders for whatever reason.
+NB: Remember, there is nothing stopping you from creating an extra partition, formatting it with a filesystem of your choice, and then configuring /etc/fstab to mount it as /home after AerynOS has been installed. You can do this if you want to use a different filesystem than xfs for your /home folders for whatever reason.
### Why do you recommend the xfs filesystem for the root partition?
@@ -163,19 +163,19 @@ Tack on ```--help``` to see the options for prune.
See the [blsforme repo readme](https://github.com/AerynOS/blsforme/?tab=readme-ov-file#filesystem-layout) for the expected format.
-Typically, it is necessary to change the installed system state with ```moss``` for command-line snippets to take effect.
+Typically, it is necessary to change the installed system state with `moss` for command-line snippets to take effect.
-One way of doing that is to do a ```sudo moss remove nano -y && sudo moss install nano -y```, followed by ```sudo moss boot status``` to check if the new cmdline snippet is now active.
+One way of doing that is to do a `sudo moss remove nano -y && sudo moss install nano -y`, followed by `sudo moss boot status` to check if the new cmdline snippet is now active.
# Package Questions
### How come your package repository is so small?
-We are still in heavy development ("Alpha") and are developing our back end and associated automated rebuild processes.
+We are still in heavy development ("Alpha") and are developing our backend and associated automated rebuild processes.
If we discover that it is necessary for us to rebuild our entire repository, we would like the ability to do so in the span of an afternoon (using multiple builders in parallel).
-Once our back end story and our automated rebuild process story are both further advanced, we will begin scaling out the repository to contain more packages.
+Once our backend story and our automated rebuild process story are both further advanced, we will begin scaling out the repository to contain more packages.
### Could you package (...) please?
@@ -210,17 +210,17 @@ AerynOS has been bootstrapped and built from scratch and is not based on any oth
This implies that AerynOS has its own:
-- package manager (```moss```)
-- package build tool (```boulder```)
+- package manager (`moss`)
+- package build tool (`boulder`)
- build pipeline consisting of:
- - the package build dashboard and controller (```summit```)
- - the builder-as-a-service middleware (```avalanche```)
- - the package repository manager (```vessel```)
+ - the package build dashboard and controller (`summit`)
+ - the builder-as-a-service middleware (`avalanche`)
+ - the package repository manager (`vessel`)
This also implies that AerynOS does NOT build upon or use either:
-- ```.rpm``` related tooling from Red Hat
-- ```.deb``` related tooling from the Debian Project
+- `.rpm` related tooling from Red Hat
+- `.deb` related tooling from the Debian Project
- Arch-related tooling
### When will AerynOS be considered stable?
@@ -229,4 +229,4 @@ AerynOS is taking on the ambitious task of creating a distribution from scratch,
As such, there is no official ETA.
-Now that the project has hit alpha status, you will see more frequent updates and progress reports.
+Now that the project has hit alpha status, you will see frequent updates and progress reports.
diff --git a/src/content/docs/AerynOS/index.mdx b/src/content/docs/AerynOS/index.mdx
index 8204edda..85003ec4 100644
--- a/src/content/docs/AerynOS/index.mdx
+++ b/src/content/docs/AerynOS/index.mdx
@@ -5,9 +5,6 @@ description: Documentation about the project and its technologies
---
import DirectoryList from '@components/DirectoryList.astro';
-AerynOS is an independent Linux-based operating system that diverges significantly from traditional
-distributions whilst still aiming to provide a familiar and comfortable environment. In this section
-of the documentation, you can find high level information about the project itself and what sets it
-apart from other distributions.
+AerynOS is an independent Linux-based operating system that diverges significantly from traditional distributions whilst still aiming to provide a familiar and comfortable environment. In this section of the documentation, you can find high level information about the project itself and what sets it apart from other distributions.
diff --git a/src/content/docs/AerynOS/overview.mdx b/src/content/docs/AerynOS/overview.mdx
index 19b5ff10..6384a0fa 100644
--- a/src/content/docs/AerynOS/overview.mdx
+++ b/src/content/docs/AerynOS/overview.mdx
@@ -6,22 +6,14 @@ description: Overview of the AerynOS project and its technologies
import { Aside } from '@astrojs/starlight/components';
-AerynOS is a Linux-based operating system designed to eliminate years of technical baggage. It is an engineering
-led effort in that the distribution is produced entirely by the tooling we have developed. Every new feature,
-technology or enabling is carefully considered, drawing on our own experiences and by studying the impact in similar
-decision spaces in other projects.
+AerynOS is a Linux-based operating system designed to eliminate years of technical baggage. It is an engineering led effort in that the distribution is produced entirely by the tooling we have developed. Every new feature, technology, or enabling is carefully considered, drawing on our own experiences and by studying the impact in similar decision spaces in other projects.
-Despite being heavily engineering led, we are not averse to design. We aim to provide the best in class user experience
-atop a solid, innovative foundation, whilst ensuring we have the scope and scalability to meet the needs of the future.
+Despite being heavily engineering led, we are not averse to design. We aim to provide the best in class user experience atop a solid, innovative foundation, whilst ensuring we have the scope and scalability to meet the needs of the future.
-In essence, we're producing a distribution based on sound technical principles, in order to deliver a "daily driver"
-that truly looks after itself, getting out of the way when you need it to, and providing the tools you need when you
-need them.
+In essence, we're producing a distribution based on sound technical principles, in order to deliver a "daily driver" that truly looks after itself. Its aim is to get out of the way when you need it to, and provide the tools you need when you need them.
-If anything, AerynOS is "operating-system-as-infrastructure", providing a solid foundation for your daily computing
-needs. We're not just a distribution, we're a platform for the future.
+If anything, AerynOS is "operating-system-as-infrastructure", providing a solid foundation for your daily computing needs. We're not just a distribution, we're a platform for the future.
diff --git a/src/content/docs/AerynOS/philosophy.mdx b/src/content/docs/AerynOS/philosophy.mdx
index d0c030fc..eb670459 100644
--- a/src/content/docs/AerynOS/philosophy.mdx
+++ b/src/content/docs/AerynOS/philosophy.mdx
@@ -28,32 +28,32 @@ System triggers do not run in an isolated container, but instead are run in the
## Atomic updates
-An atomic update is a series of changes to a system that are treated as a single, indivisible operation. If any part of this update fails, then the entire update is cancelled with all prior parts of the incomplete update being rolled back. This means that either an update completes fully as intended, or the system is left in the state it was in before the update was attempted. This is important because partial updates often cause significant issues such as bricked installs.
+An atomic update is a series of changes to a system that are treated as a single, indivisible operation. If any part of this update fails, then the entire update is canceled with all prior parts of the incomplete update being rolled back. This means that either an update completes fully as intended, or the system is left in the state it was in before the update was attempted. This is important because partial updates often cause significant issues such as bricked installs.
-AerynOS's approach to atomic updates is fairly different to the approach taken by other Linux distributions, which mostly use an A/B switch model using specific read-only filesystems to swap the whole system upon reboot. Atomic updates in AerynOS are managed by its package manager `moss` (which we also refer to as a `system state manager`). As such, AerynOS is not tied to using read-only filesystems and this allows for the use of XFS, ext4 and F2FS.
+AerynOS' approach to atomic updates is fairly different to the approach taken by other Linux distributions, which mostly use an A/B switch model using specific read-only filesystems to swap the whole system upon reboot. Atomic updates in AerynOS are managed by its package manager `moss` (which we also refer to as a `system state manager`). As such, AerynOS is not tied to using read-only filesystems and this allows for the use of XFS, ext4 and F2FS.
-As mentioned above, AerynOS utilises a stateless design where packages can only be installed to the `/usr` directory. The knowledge that packages can only be installed to this directory allows AerynOS to innovate in its approach to atomic updates.
+As mentioned above, AerynOS utilizes a stateless design where packages can only be installed to the `/usr` directory. The knowledge that packages can only be installed to this directory allows AerynOS to innovate in its approach to atomic updates.
AerynOS packages are packaged up as bespoke `.stone` moss-format files. Hence, AerynOS does not use or rely on e.g. Debian `.deb` format package files or Fedora/RHEL `.rpm` format package files. These `.stone` files contain a deduplicated set of hashed files compressed using zstd. When a `.stone` file is installed via `moss`, the files are decompressed and stored into a global, deduplicated content addressable store under`/.moss/`. Relevant metadata about these files is also stored in a database under `/.moss/`.
-As part of the final stages of an atomic transaction, `moss` creates (or "blits") a new `/usr` directory based on [hardlinks](https://www.virtualcuriosities.com/articles/4507/how-hard-links-and-inodes-work-on-linux) to the global content addressable store, and swaps this new `/usr` directory into place using the `renameat2` Linux kernel syscall with the `RENAME_EXCHANGE` flag, which allows for atomically exchanging an old path for a new path.
+As part of the final stages of an atomic transaction, `moss` creates (or "blits") a new `/usr` directory based on [hardlinks](https://www.virtualcuriosities.com/articles/4507/how-hard-links-and-inodes-work-on-linux) to the global content addressable store. It then swaps this new `/usr` directory into place using the `renameat2` Linux kernel syscall with the `RENAME_EXCHANGE` flag, which allows for atomically exchanging an old path for a new path.
As hardlinks do not take up any significant additional space on disk, and since the global content addressable store is always deduplicated as part of every transaction, `moss` stores every `/usr` directory from every transaction. This allows for retaining system snapshots with minimal overhead and provides the ability to perform atomic rollbacks to earlier states so long as the user does not prune those.
## Self healing
-As part of our boot management solution, every moss transaction ID is encoded into the kernel command line and is picked up during early boot into our initramfs, before `/sysroot` is pivoted to. Every kernel is correctly synchronised with the right rootfs based on the moss transaction it was associated to. Given that every transaction creates a new bootloader entry, AerynOS prunes all but the last 5 transactions from the bootloader list to keep it manageable.
+As part of our boot management solution, every moss transaction ID is encoded into the kernel command line and is picked up during early boot into our initramfs, before `/sysroot` is pivoted to. Every kernel is correctly synchronized with the right rootfs based on the moss transaction it was associated to. Given that every transaction creates a new bootloader entry, AerynOS prunes all but the last 5 transactions from the bootloader list to keep it manageable.
### What are the implications of this?
-On a Gnome based system, if you were to delete `gtk3`, `GDM`, and `gnome-shell` you would not be able to log back into the gnome session (as you've just deleted some really important part of the gnome session!). In this case, on boot you would be greeted by a linux console login prompt, which would only let you log into your user's command line shell, which is less than ideal.
+On a Gnome based system, if you were to delete `gtk3`, `GDM`, and `gnome-shell` you would not be able to log back into the gnome session (as you've just deleted some really important part of the gnome session!). In this case, on boot you would be greeted by a Linux console login prompt, which would only let you log into your user's command line shell, which is less than ideal.
-In AerynOS, instead of this scenario, you can enter the bootloader (by mashing your spacebar) on reboot, and in the bootloader, you can select the second to last entry and this will automatically switch to the `/usr` filesystem transaction where `gtk3`, `GDM` and `gnome-shell` had not yet been deleted. On activating this entry with the Enter key, you will boot back into a working GDM for a graphical user experience.
+In AerynOS, instead of this scenario, you can enter the bootloader (by mashing your spacebar) on reboot, and in the bootloader. Select the second to last entry and this will automatically switch to the `/usr` filesystem transaction where `gtk3`, `GDM` and `gnome-shell` had not yet been deleted. On activating this entry with the Enter key, you will boot back into a working GDM for a graphical user experience.
-Taking this a step further, if you were to remove `glibc`, given how integral it is to the functioning of AerynOS and how it specifically includes the `renameat2` function used by `moss` to complete transactions, the system would be left in a state where the atomic update did not complete and the whole system would be broken. In a traditional Linux distribution, this will be very difficult, if not impossible to resolve without resorting to a fresh re-install.
+Taking this a step further, if you were to remove `glibc`, given how integral it is to the functioning of AerynOS and how it specifically includes the `renameat2` function used by `moss` to complete transactions, the system would be left in a state where the atomic update did not complete and the whole system would be broken. In a traditional Linux distribution, this will be very difficult, or impossible to resolve without resorting to a fresh reinstall.
-In AerynOS, however, upon trying to boot into this last transaction, the system will discover that there is an issue with the transaction and will atomically roll back to the prior bootloader entry with the associated correct `/usr` directory that works. This rollback process only takes around a second (or a couple seconds, depending on your hardware) and you will automatically be dropped back into a live working AerynOS system.
+In AerynOS, however, upon trying to boot into this last transaction, the system will discover that there is an issue with the transaction and will atomically roll back to the prior bootloader entry with the associated correct `/usr` directory that works. This rollback process only takes around a second (or a couple of seconds, depending on your hardware) and you will automatically be dropped back into a live working AerynOS system.
### Could this happen?
-Whilst it is unlikely that a user would ever knowingly delete these very important packages (though it could happen), the more likely scenario on traditional Linux distributions is that there is a partial update that may have deleted very important aspects for a functioning system with the newer versions not having been yet installed before the update stopped. By the design features mentioned above, this is impossible on AerynOS.
+Whilst it is unlikely that a user would ever knowingly delete these very important packages (though it could happen). The more likely scenario on traditional Linux distributions is that there is a partial update that may have deleted very important aspects for a functioning system with the newer versions not having been yet installed before the update stopped. By the design features mentioned above, this is impossible on AerynOS.
diff --git a/src/content/docs/Developers/Stone/V1/header.mdx b/src/content/docs/Developers/Stone/V1/header.mdx
index b7105818..5451eeb0 100644
--- a/src/content/docs/Developers/Stone/V1/header.mdx
+++ b/src/content/docs/Developers/Stone/V1/header.mdx
@@ -4,8 +4,7 @@ lastUpdated: 2025-03-28T05:28:00Z
description: The v1 header of the stone format
---
-The v1 header contains 3 fields to denote the type of the `.stone` file as well as a count
-of the payloads. These are contained within the 24-byte `data` field of the agnostic header.
+The v1 header contains 3 fields to denote the type of the `.stone` file as well as a count of the payloads. These are contained within the 24-byte `data` field of the agnostic header.
## Fields
@@ -17,9 +16,7 @@ of the payloads. These are contained within the 24-byte `data` field of the agno
## The padding check
-While building the stone format, we built-in the `.data` field to permit future extensions in subsequent
-stone versions. As of v1, the `.padding_chk` field contains a statically initialised array as a mild corruption
-check.
+While building the stone format, we built-in the `.data` field to permit future extensions in subsequent stone versions. As of v1, the `.padding_chk` field contains a statically initialized array as a mild corruption check.
```rust
const INTEGRITY_CHECK: [u8; 21] = [
diff --git a/src/content/docs/Developers/Stone/V1/index.mdx b/src/content/docs/Developers/Stone/V1/index.mdx
index f426559f..d63fe49c 100644
--- a/src/content/docs/Developers/Stone/V1/index.mdx
+++ b/src/content/docs/Developers/Stone/V1/index.mdx
@@ -5,7 +5,6 @@ description: V1 Stone format
---
import DirectoryList from '@components/DirectoryList.astro';
-The V1 Stone Format is the format currently employed by AerynOS, and is the first revision of our format. Over time we will
-continue to enhance the format and introduce new features, gated explicitly to a version.
+The V1 Stone Format is the format currently employed by AerynOS, and is the first revision of our format. Over time we will continue to enhance the format and introduce new features, gated explicitly to a version.
diff --git a/src/content/docs/Developers/Stone/header.mdx b/src/content/docs/Developers/Stone/header.mdx
index 92ae753c..1eaf1071 100644
--- a/src/content/docs/Developers/Stone/header.mdx
+++ b/src/content/docs/Developers/Stone/header.mdx
@@ -4,9 +4,7 @@ lastUpdated: 2025-03-28T05:28:00Z
description: Stone archive header format
---
-Stone archives are encoded with a version agnostic header, ensuring that version-specific
-fields can be handled separately from version and format detection. This is a 32-byte header
-at the start of the archive.
+Stone archives are encoded with a version agnostic header, ensuring that version-specific fields can be handled separately from version and format detection. This is a 32-byte header at the start of the archive.
## Fields
diff --git a/src/content/docs/Developers/index.mdx b/src/content/docs/Developers/index.mdx
index 7379f6a2..50620754 100644
--- a/src/content/docs/Developers/index.mdx
+++ b/src/content/docs/Developers/index.mdx
@@ -8,12 +8,9 @@ import { Aside } from '@astrojs/starlight/components';
import DirectoryList from '@components/DirectoryList.astro';
-AerynOS includes some bespoke technologies and formats that are used to package, distribute, and introspect
-deployed software. This section of the documentation provides an overview of these technologies and formats.
+AerynOS includes some bespoke technologies and formats that are used to package, distribute, and introspect deployed software. This section of the documentation provides an overview of these technologies and formats.
diff --git a/src/content/docs/Packaging/Macros/autotools.mdx b/src/content/docs/Packaging/Macros/autotools.mdx
index 055e52e4..d8481c11 100644
--- a/src/content/docs/Packaging/Macros/autotools.mdx
+++ b/src/content/docs/Packaging/Macros/autotools.mdx
@@ -5,7 +5,6 @@ description: autotools macros
---
import RenderMacroActions from '@components/RenderMacroActions.astro';
-The `autotools` macros are used for projects that supply
-a `Makefile`, and potentially a `./configure` script.
+The `autotools` macros are used for projects that supply a `Makefile`, and potentially a `./configure` script.
diff --git a/src/content/docs/Packaging/Macros/cargo.mdx b/src/content/docs/Packaging/Macros/cargo.mdx
index cab2561f..9d846f8e 100644
--- a/src/content/docs/Packaging/Macros/cargo.mdx
+++ b/src/content/docs/Packaging/Macros/cargo.mdx
@@ -6,7 +6,6 @@ description: Rust project builds
import RenderMacroActions from '@components/RenderMacroActions.astro';
-When building "pure" [Rust](https://rust-lang.org) packages with the `cargo` build tool, ensure you use
-the `%cargo*` macros to allow `boulder` to control the various tuning options and debuginfo behaviour.
+When building "pure" [Rust](https://rust-lang.org) packages with the `cargo` build tool, ensure you use the `%cargo*` macros to allow `boulder` to control the various tuning options and debuginfo behavior.
diff --git a/src/content/docs/Packaging/Macros/index.mdx b/src/content/docs/Packaging/Macros/index.mdx
index 0eb39c8a..0c8b6b89 100644
--- a/src/content/docs/Packaging/Macros/index.mdx
+++ b/src/content/docs/Packaging/Macros/index.mdx
@@ -6,8 +6,6 @@ description: Tools to simplify life - macros
import DirectoryList from '@components/DirectoryList.astro';
-Every `stone.yaml` build has access to a number of **action** and **definition** macros.
-With these, we can ensure a greater degree of integration and consistency in our packaging,
-and vastly simplify common tasks to reduce maintainer burden.
+Every `stone.yaml` build has access to a number of **action** and **definition** macros. With these, we can ensure a greater degree of integration and consistency in our packaging, and vastly simplify common tasks to reduce maintainer burden.
diff --git a/src/content/docs/Packaging/Recipes/System Accounts/overview.mdx b/src/content/docs/Packaging/Recipes/System Accounts/overview.mdx
index fbf3f7d5..94f8aecc 100644
--- a/src/content/docs/Packaging/Recipes/System Accounts/overview.mdx
+++ b/src/content/docs/Packaging/Recipes/System Accounts/overview.mdx
@@ -8,17 +8,12 @@ description: "Stateless management of AerynOS user accounts"
import { Aside } from '@astrojs/starlight/components';
-As a stateless distribution, AerynOS does not permit the modification of `/etc/passwd` and co by
-packages or triggers. Instead, we integrate `nss-systemd` and `userdb`.
+As a stateless distribution, AerynOS does not permit the modification of `/etc/passwd` and co by packages or triggers. Instead, we integrate `nss-systemd` and `userdb`.
-The main benefit with this approach is ensuring that we do not directly mutate system files, and that
-unlike the `sysusers` mechanism, removal of a package ensures these system user and group definitions
-are no longer available.
+The main benefit with this approach is ensuring that we do not directly mutate system files, and that unlike the `sysusers` mechanism, removal of a package ensures these system user and group definitions are no longer available.
diff --git a/src/content/docs/Packaging/Recipes/System Accounts/users.mdx b/src/content/docs/Packaging/Recipes/System Accounts/users.mdx
index 6f70162c..e918fa01 100644
--- a/src/content/docs/Packaging/Recipes/System Accounts/users.mdx
+++ b/src/content/docs/Packaging/Recipes/System Accounts/users.mdx
@@ -25,8 +25,7 @@ Within the package tree `./pkg` add `gdm.user`:
}
```
-Note that these are the minimum required set of fields, and `disposition` should always be set to `system`. Also note that
-`homeDirectory` may need setting for some packages.
+Note that these are the minimum required set of fields, and `disposition` should always be set to `system`. Also note that `homeDirectory` may need setting for some packages.
In your recipe's `install` section, you must install the file by username *and* by uid to the `%(libdir)/userdb` directory:
diff --git a/src/content/docs/Packaging/Recipes/Triggers/overview.mdx b/src/content/docs/Packaging/Recipes/Triggers/overview.mdx
index 03eded03..8c9632c1 100644
--- a/src/content/docs/Packaging/Recipes/Triggers/overview.mdx
+++ b/src/content/docs/Packaging/Recipes/Triggers/overview.mdx
@@ -6,24 +6,17 @@ description: "Triggers match filesystem paths to actions"
---
-AerynOS supports the use of triggers, or actions, that run at the end of package installations.
-Given the significantly different architecture of AerynOS, these triggers may not be quite what
-you are used to in other distributions or package managers.
+AerynOS supports the use of triggers, or actions, that run at the end of package installations. Given the significantly different architecture of AerynOS, these triggers may not be quite what you are used to in other distributions or package managers.
## Basic mechanism
-After a new transaction is formed and `moss` has identified all of the paths used to compose a filesystem,
-the staging tree is built as the basis of the new `/usr`. Any trigger files (under `/usr/share/moss/triggers`)
-will be loaded, and any **matching** triggers will be executed at the appropriate stage.
+After a new transaction is formed and `moss` has identified all the paths used to compose a filesystem, the staging tree is built as the basis of the new `/usr`. Any trigger files (under `/usr/share/moss/triggers`) will be loaded, and any **matching** triggers will be executed at the appropriate stage.
-Note that trigger logic is based on `glob`-style path matches and are not incremental. Our triggers were so
-designed to avoid the uncontrolled execution of arbitrary scripts, instead relying on logical matching of
-patterns to handlers.
+Note that trigger logic is based on `glob`-style path matches and are not incremental. Our triggers were so designed to avoid the uncontrolled execution of arbitrary scripts, instead relying on logical matching of patterns to handlers.
## Capturing globs
-Our triggers use special string tokens to permit capturing groups from a glob-style string. At this stage we
-support `*` and `?` glob characters only, compiling to a regex internally. Support is planned for braces.
+Our triggers use special string tokens to permit capturing groups from a glob-style string. At this stage we support `*` and `?` glob characters only, compiling to a regex internally. Support is planned for braces.
```sh
/usr/lib/(GROUP_NAME:PATTERN)/dir
@@ -35,8 +28,7 @@ The parenthesis begin a non-greedy capture group named `GROUP_NAME` containing p
/usr/share/icons/(name:*)/index.theme
```
-This creates a capture group identifed by `name` matching `*` in `/usr/share/icons/*/index.theme`. As such,
-the path `/usr/share/icons/hicolor/index.theme`. with `name` being set to `hicolor`.
+This creates a capture group identifed by `name` matching `*` in `/usr/share/icons/*/index.theme`. As such, the path `/usr/share/icons/hicolor/index.theme`. with `name` being set to `hicolor`.
This is a powerful mechanism that allows us to control handler execution without relying on interim scripts.
@@ -46,7 +38,6 @@ Consider this example:
/usr/lib*/(libname:lib*.so.*)
```
-This will only match `lib*.so.*` glob, and set `libname` to `libz.so.1` for `/usr/lib32/libz.so.1`, but will not
-match for `/usr/lib64/libz.so`.
+This will only match `lib*.so.*` glob, and set `libname` to `libz.so.1` for `/usr/lib32/libz.so.1`, but will not match for `/usr/lib64/libz.so`.
These globs are then used for string substitution in the arguments passed to handlers.
diff --git a/src/content/docs/Packaging/Recipes/Triggers/tx-triggers.mdx b/src/content/docs/Packaging/Recipes/Triggers/tx-triggers.mdx
index f1fbb420..6fae710e 100644
--- a/src/content/docs/Packaging/Recipes/Triggers/tx-triggers.mdx
+++ b/src/content/docs/Packaging/Recipes/Triggers/tx-triggers.mdx
@@ -6,17 +6,13 @@ description: "Transaction triggers run in confinement to finish package configur
---
-Transactional scope triggers (`tx triggers`) are run after the new filesystem transaction has been
-blitted to disk, and just before the new `/usr` tree is activated. These triggers run within a specialised
-container and have read-write access to the new `/usr` tree, but only have read-only access to the `/etc`
-directory.
+Transactional scope triggers (`tx triggers`) are run after the new filesystem transaction has been blitted to disk, and just before the new `/usr` tree is activated. These triggers run within a specialized container and have read-write access to the new `/usr` tree, but only have read-only access to the `/etc` directory.
Transaction triggers must be installed in `/usr/share/moss/triggers/tx.d` with a `.yaml` suffix.
## Sample trigger
-This simple trigger will run `depmod -a 6.6.15` when any files are installed to `/usr/lib/modules/6.6.15/`.
-Note that identical commands (after expansion) will be collapsed automatically to a single run.
+This simple trigger will run `depmod -a 6.6.15` when any files are installed to `/usr/lib/modules/6.6.15/`. Note that identical commands (after expansion) will be collapsed automatically to a single run.
```yaml
name: depmod
diff --git a/src/content/docs/Packaging/Recipes/build-deps.mdx b/src/content/docs/Packaging/Recipes/build-deps.mdx
index 5c1f0ffb..66dd3dcc 100644
--- a/src/content/docs/Packaging/Recipes/build-deps.mdx
+++ b/src/content/docs/Packaging/Recipes/build-deps.mdx
@@ -4,16 +4,13 @@ description: "Build dependency types"
lastUpdated: 2024-09-07T23:52:00Z
---
-Every build of a recipe by `boulder` will create an entirely new root, with only the absolute minimum support dependencies in place.
-In order to build most software, you will need to add to the `builddeps` key in `stone.yml`. Luckily, our tooling supports more than
-one kind of dep.
+Every build of a recipe by `boulder` will create an entirely new root, with only the absolute minimum support dependencies in place. In order to build most software, you will need to add to the `builddeps` key in `stone.yml`. Luckily, our tooling supports more than one kind of dependency.
Note that AerynOS packages are also capable of storing **providers** that make the following kinds of dependencies work.
## `$name` - standard deps
-Simply listing a name will create a dependency on that package name. This is discouraged as automatically resolved providers offer a
-far more resilient system.
+Simply listing a name will create a dependency on that package name. This is discouraged as automatically resolved providers offer a far more resilient system.
```yaml
builddeps:
diff --git a/src/content/docs/Packaging/Recipes/metadata.mdx b/src/content/docs/Packaging/Recipes/metadata.mdx
index 19b3b3e3..845c3a51 100644
--- a/src/content/docs/Packaging/Recipes/metadata.mdx
+++ b/src/content/docs/Packaging/Recipes/metadata.mdx
@@ -24,14 +24,11 @@ Could generate `zlib`, `zlib-devel`, `zlib-dbginfo`, etc.
### `version`
-This string tells users what version they are using, and isn't used at all for any kind of version comparison logic in the tooling. It is
-essentially a freeform string. It **should** be identical to the upstream identifier so that we can detect new releases automatically of the
-source project.
+This string tells users what version they are using, and isn't used at all for any kind of version comparison logic in the tooling. It is essentially a freeform string. It **should** be identical to the upstream identifier so that we can detect new releases automatically of the source project.
### `release`
-A monotonically incrementing integer. This field is bumped whenever we need to issue a new build ("release") of a package as an update to users.
-Without incrementing this field, no build is scheduled.
+A monotonically incrementing integer. This field is bumped whenever we need to issue a new build ("release") of a package as an update to users. Without incrementing this field, no build is scheduled.
### `homepage`
diff --git a/src/content/docs/Packaging/Recipes/overview.mdx b/src/content/docs/Packaging/Recipes/overview.mdx
index e43a987f..5ddd55df 100644
--- a/src/content/docs/Packaging/Recipes/overview.mdx
+++ b/src/content/docs/Packaging/Recipes/overview.mdx
@@ -4,8 +4,7 @@ lastUpdated: 2026-01-26T09:00:00Z
description: Introduction to the `stone.yaml` format
---
-Simply put, a recipe is some metadata to describe a software package, and the associated *instructions* required to build that package in a reproducible fashion. Doing so allows us to automate builds, and provide software updates. At a surface level, our `stone.yml` recipe format
-has an awful lot in common with other packaging systems.
+Simply put, a recipe is some metadata to describe a software package, and the associated *instructions* required to build that package in a reproducible fashion. Doing so allows us to automate builds, and provide software updates. At a surface level, our `stone.yml` recipe format has an awful lot in common with other packaging systems.
## A basic recipe
diff --git a/src/content/docs/Packaging/Recipes/upstreams.mdx b/src/content/docs/Packaging/Recipes/upstreams.mdx
index dad542f2..62f96984 100644
--- a/src/content/docs/Packaging/Recipes/upstreams.mdx
+++ b/src/content/docs/Packaging/Recipes/upstreams.mdx
@@ -10,8 +10,7 @@ The majority of packages are built using upstream release sources. While it is p
## Plain sources
-A plain source is one that simply has an upstream URI and can be unpacked in some fashion, i.e. a tarball. The hash must be provided for the
-upstream and accompanied by the SHA256 sum.
+A plain source is one that simply has an upstream URI and can be unpacked in some fashion, i.e. a tarball. The hash must be provided for the upstream and accompanied by the SHA256 sum.
```yaml
upstreams:
diff --git a/src/content/docs/Packaging/Workflow/basic-workflow.mdx b/src/content/docs/Packaging/Workflow/basic-workflow.mdx
index 958c5684..ed3a4ee7 100644
--- a/src/content/docs/Packaging/Workflow/basic-workflow.mdx
+++ b/src/content/docs/Packaging/Workflow/basic-workflow.mdx
@@ -4,47 +4,35 @@ lastUpdated: 2025-06-23T00:00:00Z
description: "Building packages locally and testing them"
---
-Once the [prerequisites](/packaging/workflow/prerequisites/) have been handled, it is time to learn how to install
-newly built local moss-format `.stone` packages.
+Once the [prerequisites](/packaging/workflow/prerequisites/) have been handled, it is time to learn how to install newly built local moss-format `.stone` packages.
## Understanding moss-format repositories
-When building and testing packages locally, boulder (and moss) can be configured to consult a local
-moss-format repository containing moss-format `.stone` packages and a `stone.index` local repository
-index.
+When building and testing packages locally, boulder (and moss) can be configured to consult a local moss-format repository containing moss-format `.stone` packages and a `stone.index` local repository index.
### `stone.index` files
-The `stone.index` file is what both moss and boulder consult when they check which packages are
-available to be installed into moss-maintained system roots.
+The `stone.index` file is what both moss and boulder consult when they check which packages are available to be installed into moss-maintained system roots.
-Adding a moss-format repository is as simple as registering a new location from where to fetch
-`stone.index` files, which will be shown in detail later on this page.
+Adding a moss-format repository is as simple as registering a new location from where to fetch `stone.index` files, which will be shown in detail later on this page.
### `moss` build roots
-Every time a package is built, `boulder` calls out to `moss` to have it construct a pristine build root
-directory (called a 'buildroot') with the necessary package build prerequisites installed.
+Every time a package is built, `boulder` calls out to `moss` to have it construct a pristine build root directory (called a 'buildroot') with the necessary package build prerequisites installed.
-The packages in this buildroot are resolved from one or more moss `stone.index` files, sorted in
-descending priority, such that the highest priority repository "wins" when package providers are
-resolved.
+The packages in this buildroot are resolved from one or more moss `stone.index` files, sorted in descending priority, such that the highest priority repository "wins" when package providers are resolved.
-The lowest priority repository will typically be the official AerynOS upstream package
-repository.
+The lowest priority repository will typically be the official AerynOS upstream package repository.
-If higher priority repositories are added, packages from these will in turn override the packages
-available in the official AerynOS upstream package repository.
+If higher priority repositories are added, packages from these will in turn override the packages available in the official AerynOS upstream package repository.
-The next section deals with how to create and register a higher priority local moss-format
-repository, which is colloquially referred to as a "local repo".
+The next section deals with how to create and register a higher priority local moss-format repository, which is colloquially referred to as a "local repo".
## Creating a local repository
-After the helper script has been activated in `bash`, open a new tab or a new terminal, and execute
-the following commands:
+After the helper script has been activated in `bash`, open a new tab or a new terminal, and execute the following commands:
```bash
# create a new tab or open a new terminal
@@ -53,14 +41,12 @@ just create-local
just index-local
```
-The `just create-local` invocation will set up an empty `~/.cache/local_repo/x86_64/` directory,
-and the `just index-local` invocation will create a `stone.index` file for the directory.
+The `just create-local` invocation will set up an empty `~/.cache/local_repo/x86_64/` directory, and the `just index-local` invocation will create a `stone.index` file for the directory.
### Making boulder use the local repository
-Boulder will need to have its list of "build profiles" be updated before it will consult the
-`~/.cache/local_repo/x86_64/stone.index` moss-format repository index created above:
+Boulder will need to have its list of "build profiles" be updated before it will consult the `~/.cache/local_repo/x86_64/stone.index` moss-format repository index created above:
```bash
boulder profile list
@@ -128,21 +114,14 @@ moss repo list
#### Package resolution order
-In the above priority tower, each moss-format package would first get resolved via the `local`
-repository (priority 100), then from the `volatile` repository (priority 10), and finally from the
-`unstable` repository (priority 0), the latter of which is the official upstream AerynOS
-moss-format `.stone` package repository.
+In the above priority tower, each moss-format package would first get resolved via the `local` repository (priority 100), then from the `volatile` repository (priority 10), and finally from the `unstable` repository (priority 0). The latter of which is the official upstream AerynOS moss-format `.stone` package repository.
#### Disabling moss-format repositories
-Users of AerynOS should generally _not_ have the `volatile` repository be enabled, because this
-repository is where new `.stone` packages land right after being built, which means the repository
-can potentially be in an undefined and volatile state when building large build queues (hence the
-name).
+Users of AerynOS should generally _not_ have the `volatile` repository be enabled, because this repository is where new `.stone` packages land right after being built. This means the repository can potentially be in an undefined and volatile state when building large build queues (hence the name).
-Therefore, it can be useful to disable moss-format repositories without deleting their definitions
-from the local system:
+Therefore, it can be useful to disable moss-format repositories without deleting their definitions from the local system:
```bash
sudo moss repo disable volatile
@@ -157,12 +136,9 @@ moss repo list
#### Enabling moss-format repositories
-However, when testing locally built packages, they _must_ be built against the `local-x86_64`
-boulder build profile, which in turns relies on the `volatile` repository via the boulder
-`local-x86_64` build profile.
+However, when testing locally built packages, they _must_ be built against the `local-x86_64` boulder build profile, which in turns relies on the `volatile` repository via the boulder `local-x86_64` build profile.
-Hence, when testing locally built packages, you may need to _**temporarily**_ enable the `volatile`
-repository for moss to resolve from.
+Hence, when testing locally built packages, you may need to _**temporarily**_ enable the `volatile` repository for moss to resolve from.
```bash
sudo moss repo enable volatile
@@ -200,8 +176,7 @@ just ls-local
Note that the basic packaging workflow in AerynOS assumes that you are using a local repository.
-If you are building multiple package recipes, you will need to `just build` and `just mv-local`
-for each package recipe sequentially.
+If you are building multiple package recipes, you will need to `just build` and `just mv-local` for each package recipe sequentially.
## Updating the installed system state
@@ -220,8 +195,7 @@ Testing your package(s) is now as simple as:
## Cleaning the local repository
-Often, it will be prudent to clean out the local repository after the associated recipe PR has been
-accepted upstream.
+Often, it will be prudent to clean out the local repository after the associated recipe PR has been accepted upstream.
```bash
gotoaosrepo
@@ -231,16 +205,12 @@ sudo moss repo disable local
sudo moss sync -u
```
-This will sync the the local system to a new installed system state made only from the upstream
-`unstable` moss-format `.stone` package repository state.
+This will sync the the local system to a new installed system state made only from the upstream `unstable` moss-format `.stone` package repository state.
-This will effectively make the new system state "forget" the nano version installed from the local
-repository in the previous system state.
+This will effectively make the new system state "forget" the nano version installed from the local repository in the previous system state.
## Ending notes
-If you have made it this far, congratulations! You should now understand the basic workflow of
-packaging and managing repositories with AerynOS.
+If you have made it this far, congratulations! You should now understand the basic workflow of packaging and managing repositories with AerynOS.
-Tip: execute `just -l` to see a list of supported `just` 'recipes', which are common actions that
- have been automated by the AerynOS developers.
+Tip: execute `just -l` to see a list of supported `just` 'recipes', which are common actions that have been automated by the AerynOS developers.
diff --git a/src/content/docs/Packaging/Workflow/prerequisites.mdx b/src/content/docs/Packaging/Workflow/prerequisites.mdx
index 51664f4c..807fe6b6 100644
--- a/src/content/docs/Packaging/Workflow/prerequisites.mdx
+++ b/src/content/docs/Packaging/Workflow/prerequisites.mdx
@@ -10,8 +10,7 @@ installed, and a new directory for storing local build artifacts needs to be set
## Installing the `build-essential` package
-We maintain a `build-essential` metapackage that should contain the basics for getting started
-with packaging on AerynOS.
+We maintain a `build-essential` metapackage that should contain the basics for getting started with packaging on AerynOS.
```bash
sudo moss sync -u
@@ -21,8 +20,7 @@ sudo moss it build-essential
## Activating the AerynOS helper scripts
-The easiest way to create a local repository is to use the helper script distributed with the
-AerynOS recipe repository in the `tools/` directory.
+The easiest way to create a local repository is to use the helper script distributed with the AerynOS recipe repository in the `tools/` directory.
Start by cloning the recipes/ git repository:
@@ -47,8 +45,7 @@ cd ~
gotoaosrepo
```
-If the helpers script has been correctly loaded, the `gotoaosrepo` command should switch to
-the directory containing the recipes/ git repository clone.
+If the helpers script has been correctly loaded, the `gotoaosrepo` command should switch to the directory containing the recipes/ git repository clone.
### Setting up git hooks and linters
@@ -93,8 +90,7 @@ Edit your `~/.gitconfig` file to contain the following:
## Adding /etc/subuid and /etc/subgid entries
-Since `boulder` uses user-namespaces to set up isolated build roots, it is necessary to set up
-a subuid and a subgid file for the relevant users first:
+Since `boulder` uses user-namespaces to set up isolated build roots, it is necessary to set up a subuid and a subgid file for the relevant users first:
```bash
sudo touch /etc/sub{uid,gid}
diff --git a/src/content/docs/Packaging/Workflow/submitting-a-pr.mdx b/src/content/docs/Packaging/Workflow/submitting-a-pr.mdx
index ab53939e..bf2e94dd 100644
--- a/src/content/docs/Packaging/Workflow/submitting-a-pr.mdx
+++ b/src/content/docs/Packaging/Workflow/submitting-a-pr.mdx
@@ -25,9 +25,9 @@ To keep git summaries readable, AerynOS requires the following git summary forma
## Content of Pull Request descriptions
-Git commits should be self-contained and self-explanatory. They serve as documentation for the changes made to a codebase so that others can understand and review them and also refer back to them later down the line. It is important to provide high quality git commit messages so that you or other contributors can understand the changes you are making and why.
+Git commits should be self-contained and self-explanatory. They serve as documentation for the changes made to a codebase so that others can understand and review them and refer back to them later down the line. It is important to provide high quality git commit messages so that you or other contributors can understand the changes you are making and why.
-While you know what you're doing in the moment, other contributors may not, and as time goes by, bisecting changes becomes more difficult if commit messages give you no clue as to why you made a change or what regressions might be caused if you alter it.
+While you know what you're doing in the moment, other contributors may not. As time goes by, bisecting changes becomes more difficult if commit messages give you no clue as to why you made a change or what regressions might be caused if you alter it.
### Commit message format
diff --git a/src/content/docs/Packaging/index.mdx b/src/content/docs/Packaging/index.mdx
index 66bec449..4215c5b9 100644
--- a/src/content/docs/Packaging/index.mdx
+++ b/src/content/docs/Packaging/index.mdx
@@ -5,6 +5,6 @@ description: Get to grips with packaging for AerynOS
---
import DirectoryList from '@components/DirectoryList.astro';
-Here you can find all of the packaging documentation.
+Here you can find all the packaging documentation.
-
\ No newline at end of file
+
diff --git a/src/content/docs/Users/Desktops/cosmic.mdx b/src/content/docs/Users/Desktops/cosmic.mdx
index 684de3a6..7de1922a 100644
--- a/src/content/docs/Users/Desktops/cosmic.mdx
+++ b/src/content/docs/Users/Desktops/cosmic.mdx
@@ -10,7 +10,7 @@ The [COSMIC Desktop](https://system76.com/cosmic) from [System76](https://system
### Installing COSMIC on AerynOS
-AerynOS currently only offers one iso with a GNOME live environment. However, `lichen` is a net based installer that allows users to select their Desktop Environment at install time. As such, you can install AerynOS COSMIC edition directly from the GNOME based AerynOS installer iso.
+AerynOS currently only offers one iso with a GNOME live environment. However, `lichen` is a net based installer that allows users to select their Desktop Environment at install time. As such, you can install AerynOS COSMIC edition directly from the GNOME based AerynOS installer ISO.
If you are already using GNOME, you are able to install Cosmic Desktop side by side and select which Desktop Environment to use in `GDM` at login. You do this by installing one of three package sets:
diff --git a/src/content/docs/Users/Desktops/gnome.mdx b/src/content/docs/Users/Desktops/gnome.mdx
index b1ac48d9..85a117d8 100644
--- a/src/content/docs/Users/Desktops/gnome.mdx
+++ b/src/content/docs/Users/Desktops/gnome.mdx
@@ -4,7 +4,7 @@ lastUpdated: 2026-01-13T11:10:00+07:00
description: "GNOME Desktop"
---
-The default desktop environemnt for the AerynOS live environment and for installs using `lichen` is [GNOME](https://www.gnome.org/). We utilise Wayland display server protocol and do not offer X11 (or any fork of X11).
+The default desktop environment for the AerynOS live environment and for installs using `lichen` is [GNOME](https://www.gnome.org/). We utilize Wayland display server protocol and do not offer X11 (or any fork of X11).
GNOME has been chosen as the default environment due to our familiarity with the GNOME software stack and therefore our ability to maintain it whilst we work on fleshing out the AerynOS tooling and infrastructure.
diff --git a/src/content/docs/Users/Getting Started/downloading.mdx b/src/content/docs/Users/Getting Started/downloading.mdx
index f9c1ad9f..c8cd44d2 100644
--- a/src/content/docs/Users/Getting Started/downloading.mdx
+++ b/src/content/docs/Users/Getting Started/downloading.mdx
@@ -15,7 +15,7 @@ import { Aside } from '@astrojs/starlight/components';
There may be multiple versions available with different desktop environments denoted by `AerynOS---.iso` where `` is the desktop environment.
-3. Click on the download link to start downloading the ISO file and assiocated checksums denoted by `AerynOS---.iso.sha256sum`.
+3. Click on the download link to start downloading the ISO file and associated checksums denoted by `AerynOS---.iso.sha256sum`.
Once the download is complete, you can proceed with creating a bootable USB drive or burning the ISO to a DVD to install AerynOS on your machine.
diff --git a/src/content/docs/Users/System Management/moss-state-management.mdx b/src/content/docs/Users/System Management/moss-state-management.mdx
index 58d3b5e3..6f70fd02 100644
--- a/src/content/docs/Users/System Management/moss-state-management.mdx
+++ b/src/content/docs/Users/System Management/moss-state-management.mdx
@@ -4,7 +4,7 @@ lastUpdated: 2025-09-28T16:14:34Z
description: Learn how to inspect and switch states, search for software, and keep an AerynOS system up to date with moss.
---
-Moss keeps track of packaging-related operations that change the state of the /usr directory by creating a new filesystem transaction (fstx) for each associated moss operation, be it package installation, removal or upgrades.
+Moss keeps track of packaging-related operations that change the state of the /usr directory by creating a new filesystem transaction (fstx) for each associated moss operation, be it package installation, removal, or upgrades.
Use the commands below to inspect and manage those states, discover software, and keep your system current.
@@ -41,7 +41,7 @@ sudo moss state activate 128
moss state active
```
-Activating a state atomically swaps the currently active state's /usr directory with the new states's /usr directory, using the Linux kernel [`renameat2` syscall](https://www.man7.org/linux/man-pages/man2/rename.2.html).
+Activating a state atomically swaps the currently active state's /usr directory with the new state's /usr directory, using the Linux kernel [`renameat2` syscall](https://www.man7.org/linux/man-pages/man2/rename.2.html).
On successful activation of the new state, it is recommended to reboot the system, so that long-running services start with the expected binaries, libraries, and configurations.