Merge pull request #81 from AerynOS/spelling

Spelling: Correct and standardize around US English

Author: CookieSource

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)

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.

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.
 
 <DirectoryList/>

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.
 
 <Aside type="caution">
-    Remember, AerynOS is still in development. Despite our goals, we must be clear
-    that we've deemed ourselves to be alpha quality software.
+    Remember, AerynOS is still in development. Despite our goals, we must be clear that we've deemed ourselves to be alpha quality software.
 </Aside>

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.