Ermo

13 posts by Ermo

A post we never want to have to make!

May 3, 2026

NomadicCore

Comms

Ermo

Co-founder

An image showing the word "Sorry" with three exclamation marks

This is the post we never want to make, where we made errors with our previous ISO release and are having to take steps to fix the issue, including releasing an updated ISO.

Over the course of April, the team worked on systemd-presets as a workstream we didn’t actually talk about in our April blog post. We thought that all the work had been completed in such a fashion that users wouldn’t see any discernible difference whilst allowing us to move closer to “best-practice” approaches.

Unfortunately, due to the way systemd functions, it doesn’t natively support a global preset-all approach on first boot, one of the preset approaches we had recently adopted. In combination, our lichen installer was creating an /etc/machine-id file in new installs, which is what systemd uses to detect whether a machine is in its first boot or not.

As such, users on existing systems did not have an issue, but new installs could be broken and we did not detect this as part of our ISO testing process.

Thanks to user feedback, we were able to narrow down, identify and resolve the issue within 24 hours of the ISO release, and we had an updated ISO up for testing within our server by the end of the first day of the original release. The fix came via two commits:

Lichen: Fix first boot
Systemd: Preset-all user services on first-boot

Following additional testing with a wider audience on our Zulip server, we have updated the links on our download page to our new ISO so any users downloading the latest ISO won’t see these issues.

How we view the project and our roles in creating it

Since taking over stewardship of AerynOS last year, we have consciously reset our own expectations of what we aim to deliver to our users / early adopters. It is a deliberate decision to keep the distro at an alpha tag, as there are certain expectations / deliverables for our core tooling we have not yet met.

We know we haven’t publicly laid out our roadmap, another deliberate decision, but this is all in service of delivering a product that early adopters (and eventually users) can rely on without having to worry about “what the hell might go wrong”.

There is an ethos within the team that we take seriously our craft, that being to create new and modern tooling that will make delivering and maintaining a Linux distribution significantly easier and more ergonomic.

In retrospect, we’re glad that in the year that we have collectively had stewardship of the project, this is the first and only time we have had to rush out a new ISO to fix an issue. We hope to not have this occur again in the future.

NVIDIA driver issues for certain GPUs

In the background, we have been offering a “best effort” approach to supporting NVIDIA GPUs. This is primarily because nobody on the core team are actually using NVIDIA GPUs, and because NVIDIA’s approach to open source leaves a lot to be desired from a package- and distro-maintenance point of view.

For an alpha tag distribution that is primarily focused on dogfooding itself, NVIDIA GPU support has been — and remains — fairly low priority.

That said, Reilly identified an issue with our build ordering that caused the NVIDIA module to fail to work for GPUs that require GSP firmware. With this knowledge, we have implemented a manual fix for now. The underlying issue was already known to the team, we just hadn’t caught that it presented an issue for this particular case. Fixing that issue in our infrastructure tooling is therefore moving up on our list of priorities.

Why have monthly ISOs anyway?!

The issue with new installs only presented because of our new ISO release. Had users installed AerynOS from any of our previous ISOs, the distribution would have installed without issue. Last year, we made a decision to move to a monthly ISO cadence as part of a wider “hearts and minds” effort, to demonstrate that AerynOS is in good hands, and that we are able to consistently deliver progress at a time when there was uncertainty of whether the project would be able to survive during Ikey’s initial (and, as it turned out, eventually permanent) absence from the project.

However, as a rolling release distro with a net-installer, it doesn’t strictly matter which ISO you boot to install AerynOS on your system (or in a VM), given that Lichen will always install from the latest unstable stream version of AerynOS. As such, we are reviewing our release cadence and will likely align releases around a couple of key factors:

Major Linux kernel versions for new hardware support
Updates to our installer

which will also have a benefit of reducing bandwidth consumption. This won’t however affect the frequency of our blog posts, as we have found it helpful to communicate often with those following along with the project.

We actually delivered quite a lot in the last couple of days!

Package / stack updates for this iteration include:

Updates:

linux stable & gaming 7.0.3
linux LTS 6.18.26
thunderbird 150.0.1
asciinema 3.2.0
enchant 2.8.16
faugus-launcher 1.18.10
flatpak 1.16.6
glib2 2.88.1
gtk-4 4.22.4
inetutils 2.8
libvirt 12.3.0
rssguard 5.1.0
wine 11.8

Fixes:

boulder: Ensure that failing to set thread priority to SCHED_BATCH does not cause a panic w/ backtrace.
nm-connection-editor: It’s now a separate package and can be installed without networkmanager-applet
strawberry: Fixed not supporting common audio formats

Added:

envision 3.2.0 (VR gaming)
gitui: A graphical git client
hexyl: A terminal based hex viewer with coloured output
pkgset-oxidize: A set of pkgsets for different WM environments designed to work with the oxidize theme tool
oxidize: A tool for atomically changing themes in supported WMs
yt-dlp 2026.03.17

oxidize Window Manager theming

One of our community members, Christian Bendiksen, has been working on automated theming of window managers over the last couple of months with his oxidize tool.

His work is now ready to be included in AerynOS, and can be used to automate theme setup for the four window manager options we have within AerynOS. There are many popular themes already included, and Christian has taken the initiative to play around with our new brand colour palette to make a new Aeryn theme as well!

This work builds on top of the great work Christian and a number of other dedicated contributors have been putting in to build out AerynOS’ Window Manager credentials with the inclusion of packages to bolster our offering in this area. Taking this further, Christian has also created a package set around oxidize. This package set will help simplify the process of getting set up with a great Window Manager configuration without having to go through all of the steps to get there. The next step is to take this further by utilizing our system-model approach to further develop this approach with the goal being to eventually have a simple preconfigured Window Manager option available out of the box.

Of course, for those wishing to configure their Window Manager experience from scratch, this option is of course available to you as well.

ISO refresh

With this blog post, we already have a new 2026.05.2 ISO available on our download page.

It incorporates all the changes and package updates highlighted above and as usual, serves as a vessel for you to use lichen to install AerynOS onto your system or into a virtual machine.

Next Steps

The primary focus on the development side is (still) to attempt to get the Versioned Repos, phase2 feature over the finish line as soon as feasible.

Frankly, we have been so focused on getting the Versioned Repos, phase2 feature right, that we’ve scarcely had the mental bandwidth to focus on anything else from the perspective of our larger development arc.

That said — and assuming we succeed in landing the Versioned Repos, phase2 feature soon — we will then spend some time on sketching out the details of the upcoming avenues of development that will open up as a result.

In parallel to that, we hope to spend some time getting our systemd-preset story straight from a packaging perspective, which will give us the ability to enable services as a packaging operation. This will be especially useful when leveraged via our declarative system-model capabilities.

Supporting the project

Outside of financial donations through Stripe and Ko-fi mentioned above, we are always looking for people to get involved with development and packaging efforts and welcome anyone curious about AerynOS to join us in our Zulip server!

If any hardware vendors are interested in sponsoring the project either financially or through hardware sponsorship, this would be warmly received.

Sponsor AerynOS

If you wish to discuss other sponsorship opportunities, such as hosting or hardware sponsorship, please reach out to us at contact@aerynos.com.

Thank You!

We are very grateful for your support, be it financial or via project contributions in the form of carefully written bug reports, code contributions, design contributions, documentation updates, general feedback, package updates and overall enthusiasm around the project.

We hope that you will continue showing enthusiasm for our project, and that you will want to get involved in whichever way, shape, or form works for you!

Rebranding, Upgrading, and Wallpapering: AerynOS’ April glow-up!

Apr 30, 2026

NomadicCore

Comms

Ermo

Co-founder

Image captured by a drone camera of wintery snowy fields with a river meandering through the middle

No, this isn’t a suspicious phishing attempt! AerynOS has officially gone through a rebrand 🎉

Over the course of April, we rolled out a new logo and refreshed colour palette across the entire project. It took a bit of time to thread this through every corner of the OS and our web presence, but we’re happy to say it’s now fully in place.

Alongside the new branding, we’ve also been collaborating with community member ziegenmelker5, licensing a selection of his photography for use as wallpapers (and the title image above). A handful of these have already landed in our artwork repository and will show up on user systems after the next sync. On top of that, the team has created an abstract wallpaper inspired by the new logo, so there’s a bit of something for everyone.

On the software development side, a big chunk of April was spent improving our core tooling, especially moss and boulder:

Boulder:

Added boulder cache size to show cache size of both boulder and moss.
Added boulder cache clean to free up space on system by deleting the cache.
Updated boulder recipe update to use ent to check for recipe updates and appropriately update the stone.yaml accordingly.

Moss:

moss state prune is now faster and shows a progress bar when removing states.

In addition, we’ve continued our reuse compliance work, extending it from our recipes repository into our os-tools repository. This brings us closer to full compliance across the board.

Lastly, we have expanded our kernel configurations and now offer an LTS, stable and gaming kernel, though switching away from the stable kernel isn’t yet a simple process.

What’s new in the distro

Package / stack updates for this iteration include:

COSMIC DE 1.0.11
GNOME 50.1
KDE Frameworks 6.25.0
KDE Gear 26.04.0
KDE Plasma 6.6.4
dankmaterialshell 1.4.6
dash 0.5.13.3
docker 29.4.1
eza 0.23.4
firefox 150.0.1
fresh 0.2.23
jujutsu 0.40.0
kitty 0.46.2
kmscon 9.3.5
linux-gaming 7.0.2
linux-lts 6.18.25
linux-stable 7.0.2
llvm 22.1.4
ly 1.3.2
maven 3.9.15
mesa 26.0.6
niri 26.4
ntpd-rs 1.7.2
openvpn 2.7.2
pipewire 1.6.4
qemu 11.0.0
python 3.14.4
rust 1.95.0
thunderbird 150.0
uutils-coreutils 0.8.0
wine 11.7
zig 0.16.0
zls 0.16.0
zed 1.0.0

… along with sundry additions and updates.

Infrastructure and Tooling Updates

boulder cache subcommands with clean and size options

Screenshot showing boulder cache size command with output

This month, Joey has added additional subcommands for boulder to calculate cache sizes (both for boulder and moss). Additionally, a boulder cache clean command was added that will delete the cache to help free up space on a user’s system.

This will be particularly helpful for our packagers who after building packages will have increasing amounts of space taken up by the boulder cache. The team itself frequently moves between our unstable and volatile repositories so having the ability to delete the moss cache will also be helpful to ensure predictable outcomes.

boulder recipe automation

Screenshot of a terminal session after running boulder recipe update on the yq package recipe, resulting in the automatic update of the corresponding stone.yaml recipe file

Using our self built ent tool (which integrates with Anitya for release monitoring), we’ve taken another step toward automating package maintenance by combining it with our boulder recipe update command. When invoking this command, boulder will:

Check for updates using ent
Resolve the source URL of the latest update
Download the latest version source archive
Appropriately update the stone.yaml recipe

…all in one go.

There’s also JSON output support, which will be useful as we expand our automation tooling further down the line.

For simple package updates, this helps consolidate some of our mundane workflow steps and help make packaging a more streamlined affair on AerynOS, letting packagers focus on logic and problem solving, not administrative minutiae.

Faster `moss state remove`

Screenshot of a terminal session after running sudo moss state remove 56-77, resulting in a confirmation prompt and log of the deleted state directories

State removal is now faster thanks to parallelization, and it finally provides real-time feedback via a progress bar.

Behind the scenes, moss intelligently handles our deduplicated CAS storage, which is why removal order might look a little unusual, it’s working out which files are safe to delete across shared states.

Improved `moss search`

A new contributor, otherJL0, has made some great improvements to our moss search command:

Support for using provider syntax in search, e.g. sysbinary(...)
Smarter grouping of results based on name or summary
Highlights matched substrings in output by name or summary

This is especially useful for packaging workflows as our packagers can get a better understanding of which packages provide a given binary or library.

Continuation of our Versioned Repository feature set

We’ve continued work on phase 2 of our Versioned Repositories feature, and a draft PR with the basic workflow and new configuration format has been opened for moss. The vessel repository manager companion work has been mapped out, but no PR has yet been opened for this.

As mentioned in previous posts, the key goal of phase 2 is to enable moss to upgrade itself seamlessly, which in turn enables us to add support for new repository features and .stone format features without manual intervention.

In practical terms, this moves us closer to a true install-once, update-forever model, where we can evolve the capabilities of the system over time, without leaving users on older moss versions behind.

We hope to land the phase 2 related feature PRs in the near future.

Wider Project Updates

New Branding: A Fresh Look for AerynOS

April was a big month for us here at AerynOS, as we made some exciting strides in our rebranding efforts. We’re thrilled to finally roll out a brand-new logomark, a version of the triquetra that was originally proposed by community member Petru Jenach, and later refined by community member platlas when AerynOS was rebranded from SerpentOS last year.

Working closely with platlas and the wider community, we’ve spent the last few months refining the design and selecting a brand new colour palette. Special thanks to sammypanda, who suggested the colour scheme that we ended up using.

So, what’s behind the triquetra? This symbol has deep meaning across cultures, but we’ve chosen it particularly for its Irish roots, as a nod to AerynOS’ founder, Ikey Doherty. The triquetra represents themes of life, death, and rebirth, which felt fitting for a project that’s always evolving. It also symbolises unity and commitment, values that align with our community driven approach.

Design-wise, we’ve divided the three points of the triquetra into two colours: green and orange. The green is all about nature, while the orange ties directly to Rust, the programming language at the heart of our project. We love how the orange section can be interpreted as an ‘O’ and the green section as an ‘S’, coming together to form “OS”. It’s subtle, but we think it’s a nice touch.

We’re really excited about this fresh new look, and the fact that it’s something the whole community helped us shape. We’ve spent the month rolling it out across the operating system and our web presence, and we’re happy with how it all ties together.

New Wallpapers: Bringing Nature to Your Desktop

Screenshot of a newly installed virtual machine instance of AerynOS, Gnome edition showing the about this system page with the new default AerynOS wallpaper

Next to the new logomark, we’ve also worked with community member Gabriel Janich (aka ziegenmelker5) to bring some stunning new wallpapers to AerynOS. Gabriel has an amazing collection of photos, and choosing just a handful to feature was no easy task!

In the end, we selected seven that we felt best represented the spirit of AerynOS. You’ll see two of them as the new default wallpapers for Cosmic and GNOME (we have some work to do to properly customise our KDE Plasma defaults). Each one has its own vibe, but all of them bring a touch of nature and tranquility to your desktop.

We hope these new wallpapers, paired with the fresh logo, help make your AerynOS experience even more enjoyable as you dive into the project in the coming days and months.

Screenshot of a newly installed virtual machine instance of AerynOS, Cosmic edition showing the about this system page with the new default AerynOS wallpaper

Python stack upgrade

We mentioned last month that we planned a Python stack upgrade. Due to diligent prior preparation work by Reilly, this stack upgrade landed in a fairly seamless manner with only minor fixes required over the course of a day. The process saw Python being upgraded from 3.11 to 3.14.4 as of this writing.

Our python stack isn’t currently very large (only around 200 packages) which also played a role in the fairly seamless nature of this update. From what we can tell, the updated has enabled our early adopters to continue using Python packages without any regressions.

Kernel updates

We have packaged two alternative kernel options, though we have yet to finish the supporting work required to let users easily switch between them:

linux-lts (6.18): Latest LTS release for our most stable offering.
linux-stable (7.0): Follows the latest stable release with very few optimisations for a current stable offering.
linux-gaming (7.0): Also follows the latest stable release, but with patches for handheld gaming and miscellaneous performance optimisations.

Switching away from our linux-stable kernel to either of the other two alternative options isn’t a smooth process just yet. Improving that experience is on our roadmap.

ISO refresh

We are releasing our newest Alpha ISO, AerynOS 2026.05, which includes the updates we’ve worked on since the start of April, and which features the 7.0.2 linux-stable kernel.

As usual, this is a Live GNOME ISO that merely serves as a delivery vehicle for our Alpha/PoC lichen installer. Hence, installing AerynOS requires a network connection over which the latest pkgsets can be downloaded and subsequently installed onto a hard drive.

Please note that for now, Ventoy cannot be used to install AerynOS ISOs for which we have submitted a bug report upstream. Not to worry, multiple other options work such as Etcher, DD and GNOME Disks.

The link for our 2026.05 ISO can be found on our download page.

Next Steps

The primary focus on the development side is to attempt to get the Versioned Repos, phase2 feature over the finish line as soon as feasible.

Supporting the project

Over the last year, the project has been through a significant period of change. As detailed in our October 2025 blog post, we had to update our sponsorship accounts to receive future sponsorship funds once it became clear our previous project leader had permanently stepped away from the project.

This left us in a position where we had to build up our sponsor income from scratch having lost previous sponsors. We are very grateful that many sponsors (old and new) have joined or stayed with us on this journey and our income is again able to cover our fixed project costs with a little surplus each month.

As of this month, we are now in a net neutral position having borne the project costs for a year whilst receiving sponsorship income for 6 months. We are very appreciative of all who have ever sponsored the project, we wouldn’t be here without your support! ❤️

Ideally we would like to grow our monthly income (and therefore surplus). Doing so would allow us to:

Support our staff who currently work without compensation (apart from occasional hardware donation)
Scale and/or upgrade infrastructure over time
Consider purchasing hardware for compatibility testing
Fund future initiatives for the betterment of the project

Sponsor AerynOS

If you wish to discuss other sponsorship opportunities, such as hosting or hardware sponsorship, please reach out to us at contact@aerynos.com.

Thank You!

We hope that you will continue showing enthusiasm for our project, and that you will want to get involved in whichever way, shape, or form works for you!

March 2026 project update

Mar 31, 2026

NomadicCore

Comms

Ermo

Co-founder

AerynOS: March 2026 project update

Climbing

Another month brings another project update. In some respects, March has felt somewhat quieter than usual for the project. However, in the background, things have been fairly busy on the development front, as we prepare for larger and more visible tooling updates to land in the months to come.

On the packaging front, notable package & stack updates include GNOME 50, KDE Plasma 6.6.3, LLVM 22.1.1, Wayland 1.25.0, QT6.11.0, FFmpeg 8.1 and mesa 26.0.3 which have kept our builders busy with a significant number of package builds and rebuilds. The team mentioned last month that there is a soft-freeze in place for our repository, in terms of accepting new package recipes. This is not a full freeze as packages with little or no reverse dependency rebuild chains are still being accepted where we believe they will prove useful.

The development work this month has centered around the features we offer in terms of automating recipe updates and how we can better support bootstrap builds on the boulder side, along with the usual clean-up and refactoring work across the moss and boulder code bases.

Lastly, we want to take a moment to thank Framework for their on-going hardware sponsorship of our project. This month, they have provided the project with an AMD AI 300 based Framework 16 that Joey Riches is now using as a dedicated device for AerynOS development.

What’s new in the distro

Package / stack updates for this iteration include:

GNOME 50.0
KDE Frameworks 6.24.0
KDE Gear 25.12.3
KDE Plasma 6.6.3
awww 0.12.0
dankmaterialshell 1.4.4
firefox 149
fish 4.6.0
fresh 0.2.20
jujutsu 0.39.0
linux 6.18.19
mangowm 0.12.7
mesa 26.0.2
pipewire 1.6.2
qemu 10.2.2
riftbar 0.1.8
thunderbird 149.0.1
wine 11.5
dash 0.5.13.2
wlroots 0.19.3
wayland 1.25.0
maven 3.9.14
gparted 1.8.1
kitty 0.46.1
systemd 257.13
zls 0.15.1
sudo-rs 0.2.13
llvm 22.1.1
Qt6 6.11.0

… along with sundry additions and updates.

Desktop Updates

GNOME

Gnome Install

This month sees a significant update to the GNOME stack with the delivery of GNOME 50. We have not received any reports of any issues but if you do find any bugs, please report them back to us via GitHub Issues or through our Zulip community.

Some key updates include:

Improved parental controls
VRR and Fractional Scaling are now stable and enabled by default
Wayland only, coming in line with AerynOS’ default of having no X11 session

Plus many more features and fixes.

KDE Plasma

KDE Install

KDE Plasma has been updated to 6.6.3, KDE Frameworks to 6.24.0 and KDE Gear to 25.12.3.

The latest KDE Plasma update brings:

KWin’s screencasting feature has become robust when using PipeWire 1.6 or newer
Reduced CPU and GPU load for full-screen windows for screens using more fractional scale factors
Improve support for mice with high-resolution scroll wheels in the built-in remote desktop server

Wayland Compositor Environments

Our packaging community has really taken to the Wayland Compositor Environment choice we have in AerynOS. With new packagers getting involved with AerynOS, we are seeing faster package updates and submissions for packages that specifically enhance people’s ability to rice their environments just the way they like them.

A few key updates this month include:

mangowm 0.12.7
dankmaterialshell 1.4.4
elephant 2.20.3
bluetui 0.8.1
impala 0.7.4
awww 0.12.0
riftbar 0.1.8

On top of this, several packages have been rebuilt for better performance, support or defaults. The default terminal in our Sway package set has been swapped from alacritty to foot as this is the default terminal proposed by Sway itself. Elephant has had upstream support for moss included and this version has now been added to our own repository. Niri has seen a few upstream improvements backported into our repository also.

Infrastructure and Tooling Updates

Use CDN for the default volatile stream

As part of our content delivery strategy, we had already moved to using a CDN for delivering updates through moss on our Unstable repository. This month, we have made the transition to also using the CDN for our Volatile repository as well.

The Volatile repository is primary used for those who do their own packaging and/or submit packages to our repository. This change helps speed up downloads for those users as they disproportionately engage with our repositories for packaging purposes.

We have updated our documentation accordingly, so if you do any packaging work on AerynOS, please refer to the updated documentation on our dotdev site.

moss: Search for binaries

Moss searching has been updated to add the ability to search by binary provider.

Currently, the command line to do so is moss search --provides some-binary

Example:

$ moss search --provides cat
uutils-coreutils   Cross-platform Rust rewrite of the GNU coreutils

The current implementation is somewhat limited, and work is ongoing to improve and generalize this functionality.

moss: Enable removal of ranges of states

Moss works by utilizing a Content Addressable Storage architecture. This means that all package related files are stored in a deduplicated manner in the CAS and then hardlinked to transaction numbers /usr trees. This has the benefit of allowing for all historic states of a system to be kept without significant overhead of duplicating the majority of all data, as would happen with simple snapshots.

Space is not infinite on our systems however, so moss was designed to be able to delete transactions. This could be done, either individually, or by automatically deleting all but the last 10 transactions. Any unique files in the CAS related to these transactions would be deleting, help free up space on a users system.

Thanks to a contribution by one of our long time trusted contributors, AnonAlly, this moss state removal command now has the ability to either delete multiple states by state number or by ranges of states. This is a nice usability improvement as otherwise, users had to individually delete states one at a time. Given that some of our systems are now reaching into the hundreds of states, this is a nice time saving QoL improvement.

Example:

$ sudo moss state remove 2 5-14 17 23-28

boulder: Add support for control files

After a feature request from Reilly, ermo and tarkah designed a flexible control file format for boulder, which is initially intended to help support bootstrapping efforts for major stack updates.

During these updates, the tests within our recipes can fail though this is expected behavior. In part to conveniently address this failure mode, the control file format enables packagers to override, prepend or append phases within our build recipes.

Initially, we have created a shared control file that outright disables tests, which can be activated by symlinking it in next to recipes whilst bootstrapping them. This will enable initial bootstrapping builds to succeed before final builds are completed with the control file removed and tests therefore re-enabled.

The benefit of the shared control file approach in this instance, is that it does away with the need to go in and manually edit each recipe to disable (and subsequently re-enable) the check phase for the stack that is being bootstrapped.

We have built the control file using the KDL format as part of our wider transition to this file format within our tooling.

To those wondering why we didn’t just add a boulder build flag for this, the reason is that we have a few other future use cases in mind for this feature that are also projected to benefit from a control file, hence settling on the current design.

Wider Project Updates

Recipe repository REUSE compliance

Unless otherwise stated, all packaging recipes in our recipes repository are available under the terms of the MPL-2.0 license. This was managed both at the repository level in the readme and as a header on individual files.

Over time, the application of our header text has varied, specifically in relation to our move from the SerpentOS name to AerynOS. Fabio has reviewed the best practices for ensuring REUSE compliance and updated all files in our recipe repository to standardize the header text to these best practices.

For anyone doing local packaging work, you will need to ensure you update your local forks of the recipe repository and update boulder to ensure that you are working from the latest version of the files, and that new recipe files are created with the correct header text. You may also need to rebase existing PRs to ensure compliance to the new standard.

In addition, a new CI process has been created to check for this REUSE compliance for package recipes. This will ensure compliance with our licensing standards into the future rather than letting the files deviate over time again.

Framework hardware sponsorship

Framework

Back in August 2024, Framework provided the project (then SerpentOS) with an AMD Ryzen 7840u based Framework 13. At the time, this was helpful for Ikey (our project founder and former project lead) to have a separate and dedicated laptop for working on the project following the appropriate hardware enablement.

Fast forward to 2026, the Framework team have provided additional hardware sponsorship in the form of an AMD AI 300 based Framework 16 laptop which is being utilized by Joey Riches. Our project, whilst still in Alpha has matured significantly since 2024 so once Joey disabled secure boot, the installation occurred without a hitch without any further hardware enablement required.

Joey is coming from a desktop Ryzen 3000 based system so coming to this new Framework 16 has provided a nice upgrade in performance whilst also acting as a dedicated device for this work on AerynOS.

Unfortunately, when Ikey stepped away from the project, we lost access to the Framework 13. However, I (NomadicCore) also personally own an AMD 7840u based Framework 13 so can ensure continued hardware support for the device.

As a team, we like the repairable nature of Framework hardware and appreciate them supporting an up-and-coming distro such as ours!

ISO refresh

We are releasing our newest Alpha ISO, AerynOS 2026.03, which includes the updates we’ve worked on since the start of March, and which features the 6.18.20 kernel.

We did notice an issue in our 2026.02 ISO whereby it would not boot from Ventoy USB sticks. The issue reoccured with our 2026.03 ISO and we believe we have identified the issue. We have raised an issue with Ventoy and hopefully will have this resolved soon.

The link for our 2026.03 ISO can be found on our download page.

Next Steps

Python upgrade and repository rebuild

Next month, we are aiming to upgrade our Python stack (which is a notoriously invasive undertaking), along with doing a full repository rebuild across our ~1500 recipes. This effort deliberately coincides with us having landed LLVM 22 this month.

Our last full repository rebuild was completed in June 2025, following the then recent transition to our Rust-based infrastructure. With almost a year of infrastructure and tooling updates, it will be interesting to see how the rebuild process pans out this time.

The AerynOS build infrastructure currently runs with four permanent builders. In addition, it is trivial for us to add temporary builders to help manage peak demand periods.

For this rebuild trek, we will likely add one or two temporary builders to help keep the queue flowing past the larger builds that would otherwise clog up the queue.

Full repository rebuilds like this are important for a couple of reasons:

They test our infrastructure and help highlight any deficiencies that we need to address
They ensure full repository ABI compliance, to help minimize the risk of packages not working due to incompatible dependencies
They help ensure that our recipes and our build artefacts are all valid and up to date
They demonstrate that we can rebuild our repository if we need to for whatever reason

The current iteration of our infrastructure is at ~2750 builds, and is no longer a frustration point for the team when submitting packages for build.

This stands in stark contrast to our original Proof of Concept infrastructure that, in the background, became quite fickle and had increasingly become a source of frustration until it was replaced.

Versioned Repositories, phase2

This month we have been steadily building towards phase2 of our Versioned Repos feature set. We highlighted this in last month’s blog post, and the aim remains to be to teach moss how to seamlessly upgrade itself on user systems, in a way that automagically enables support for new repository and .stone format features.

This will set us up nicely from an “install once, update forever” perspective, as we will always be able to add new features to our tooling without requiring fresh installs or manual upgrade interventions on user systems.

Supporting the project

If any hardware vendors are interested in sponsoring the project either financially or through hardware sponsorship, this would be warmly received.

If you wish to discuss other sponsorship details, please reach out to us at contact@aerynos.com.

Sponsor AerynOS

Thank You!

In that vein, we would also like to (in this case, once again) give Framework Computers a shout out for their generous support in the form of hardware sponsorship for project members now and in the past.

February 2026 project update

Feb 28, 2026

NomadicCore

Comms

Ermo

Co-founder

AerynOS: February 2026 project update

Being Forged

February has been a busy month for the project with a lot of activity around our tooling and infrastructure. We have merged a number of smaller improvements, which have both led to an increase in useful features, correctness and maintainability. Moss has become significantly quicker in usage, boulder has seen improvements to help automate recipe creation & updates to a set standard, and our summit dashboard has seen improvements to better represent build queues live and dynamically in graphical form.

The website re-design is progressing nicely. Last month we shared that we are using the Hextra theme. Over the last month, we have coordinated with the Hextra developer around conformance to WCAG 2.2 Level AA (Web Content Accessibility Guidelines) and have been really impressed with their rate of development in this area.

Documentation has seen continued focus. We have reworked our FAQ section, the installation section has been re-written to make it clearer, and we have conducted a site-wide documentation spelling review to conform to American English.

We have also seen packagers becoming more active in helping flesh out the recipes repository and helping keep existing packages up-to-date.

During the last week of February, we have shared with our packaging community that we will likely be more focused on maintaining our existing set of packages and becoming more selective on adding new packages in the coming months, whilst our tooling capabilities mature to where they need to be for efficiently managing long term growth.

What’s new in the distro

Package / stack updates for this iteration include:

COSMIC 1.0.8
GNOME 49.4
KDE Frameworks 6.23.0
KDE Gear 25.12.2
KDE Plasma 6.6.1
awww 0.11.2+git.2c86d41
bazaar 0.7.10
dankmaterialshell 1.4.3
docker 29.2.1
dracut 110
firefox 148
fish 4.5.0
fresh 0.2.4
ironbar 0.18.0
jujutsu 0.38.0
libinput 1.31.0
linux 6.18.15
lucien 0.1.0+git.ee18358
mangowc 0.12.4
mesa 26.0.1
pipewire 1.6.0
qemu 10.2.1
riftbar 0.1.4
thunderbird 148.0
waybar 0.15.0
wine 11.3
yazi 26.1.22
zoxide 0.9.9

… along with sundry additions and updates.

Desktop Updates

Cosmic

Cosmic Install

With Cosmic Desktop landing frequent updates, the AerynOS team have landed on a nice rhythm for packaging and landing these point releases into our own repository shortly thereafter.

We are currently on 1.0.8 with all the updates that the System76 team have landed over the last month. The team are not aware of any specific AerynOS regressions or bugs on the Cosmic Desktop Environment, so you should have a pleasant experience using it.

Some key updates include:

Addresses possible VLC freezing with COSMIC Applets
Removal of unsupported actions from the Recents section in File Manager
Copy the current path by pressing Shift in File Manager

If you do become aware of any issues, as with any other DE, you can report these in our recipes repository issue tracker.

Gnome

Gnome Install

Similarly with the GNOME stack, the team are in a nice rhythm of packaging updates as upstream updates come through.

This is an area where the team could use some support. If you are able and interested, we are looking for packagers who would be interested in helping maintain the GNOME stack.

This month we have updated to Gnome 49.4 which is a stable bug fix release with updates across the Gnome stack.

Some key updates include:

Fix tab focus behavior in the Quick Settings menu
Prevent the recreation of the default folders after they are removed
Fix screen sharing of monitors with no frame rate

Plus many more fixes.

KDE Plasma

KDE Install

KDE Plasma has been updated to 6.6.1, KDE Frameworks to 6.23.0 and KDE Gear to 25.12.2. With this update, Plasma Login Manager has been promoted to become the default KDE install option in lichen, with SDDM being the backup alternative.

The latest KDE Plasma update brings:

Introduction of Plasma setup as a new first-run wizard
Spectacle now supports OCR which allows you to pull text from screenshots
Accessibility features such as a new gray scale filter inside the Color Blindness Correction settings in System Settings

Wayland Compositor Environments

Last month we shared how, through wider packager interest, we were able to add several Wayland compositor environments to the AerynOS repository. Over the last month, we have seen continued interest in using Wayland compositors on AerynOS with examples of different configurations being shared in the “Show and Tell” channel on our Zulip server.

One area of feedback we received was that the “Console-only” only installer option did not have the necessary packages installed to ensure wifi was available and working following a reboot out of the AerynOS live environment into the actually installed Console-only environment. This was a problem for some users who don’t have an Ethernet connection to their device and rely on wifi.

In response, we have created an additional “Console-only” installation option and included it in the latest ISO release this month. As a result, we now offer both the existing “Headless Install” option which is primarily intended for a server type scenario where Ethernet connectivity is expected to be present, and the aforementioned “Console-only” option which will also include the necessary packages for wifi.

In time, we would like to use our system-model approach to allow people to share their configurations with other users. This will become a straight-forward way of being able to test pre-riced versions of AerynOS with Wayland Compositor environments, whilst also allowing users to conveniently switch back to more traditional Desktop Environments without requiring full system reinstalls.

Infrastructure and Tooling Updates

Boulder and recipe updates

The team have made a number of updates to our package build tool, boulder, as part of our wider efforts to make packaging easier for all involved.

Due to design decisions in YAML, the format we currently use for our recipes, the field version: 0.010 would be parsed into version: 0.01, which is not ideal. This is particularly important for our ent version checking tool as it would incorrectly assume packages were out of date.

To solve this, we have batch converted all recipe version fields from floats to strings, and updated boulder (specifically the boulder recipe new or boulder recipe update commands) to automatically quote version fields as well. Our CI tooling now also checks that versions fields are quoted.

Finally, Boulder now also caches upstreams fetched with boulder recipe new or boulder recipe update. This is important as the prior workflow meant that packagers were wasting time and bandwidth downloading upstream sources twice.

Summit queue visualization

The team have added new visualization functionality to our Summit dashboard to show the dependency graph of the current build queue. If builds are blocked, the queue visualization will help show what blocks the queue, which will in turn give the team greater insight on where they need to look to fix the issue and unblock the queue.

This dependency graph is live and dynamic so will update itself as it works through the package queue. This looks pretty cool when our builders are flying through large stack updates such as the monthly KDE point releases.

Boulder `--verify` flag for manifest checks

Boulder has gained the ability to verify newly rebuilt manifests against existing repo manifests. This enables us to fail builds where the rebuilt manifest does not match the existing manifest, indicating the recipe and its associated .stone package artefacts are out of date with respect to the current infrastructure or tooling.

This will come in handy when doing larger-scale rebuilds.

Moss blitting speeds

A combination of recent updates within the AerynOS project, alongside what we expect to be improvements within the Linux Kernel, have led to a drastic improvement in blitting speeds as part of the AerynOS atomic update process.

We ran a fresh battery of tests on a test system to represent how blitting performance is impacted based on different drive types and filesystems.

CPU: Intel i7-13700T
Memory: Samsung DDR05 16gb 4800 MT/s (2x 8gb sticks)
HDD: Seagate ST1000LM035-1RK172 1tb (Sata 6Gb/s)
SSD: SanDisk SDSSDH32000G 2tb (Sata 6Gb/s)
NVMe: Western Digital SN 810 512gb (Gen4 NVMe)
Operating System: AerynOS 2026.01
DE: Cosmic 1.0.6
Kernel: 6.18.9-126.desktop
Date: 16/02/2026

Type	F2FS	ext4	xfs
HDD SATA3 Cold	0.4k/s	0.3k/s	3.1k/s
HDD SATA3 Hot	13.8k/s	33.4k/s	155.1k/s
SSD SATA3 Cold	34.0k/s	66.7k/s	387.2k/s
SSD SATA3 Hot	69.9k/s	805.1k/s	809.3k/s
Gen4 NVMe Cold	104.8k/s	176.4k/s	428.4k/s
Gen4 NVMe Hot	258.7k/s	765.0k/s	683.1k/s

A brand new install of AerynOS has around 65k files meaning the blitting performance of any measure in the table above with a performance of ~65k/s will be performed in roughly 1 second after a “cold” boot on all SSD drives.

The “cold” stats are where the system has just been turned on and has not yet performed a transaction yet. The process of creating a new transaction caches disk inodes and dentries into the kernel vfs cache in memory, meaning any subsequent transactions will be significantly faster.

We call these subsequent transactions “hot” and as you can see, the hot transactions are much faster than the “cold” transactions on the same system and the same drive.

For reference, when Serpent OS hit pre-alpha in August 2024, the Gen4 NVMe drive with XFS was hitting around 70k on “hot” transactions so there has been a significant speed up since then.

It is important to stress that the numbers above specifically relate to how quickly each filesystem can update hardlinks in dentries when using moss to generate hardlinked filesystem /usr transactions. The numbers should not be taken to indicate any general measure of performance.

Trigger speeds

Hidden from this table above is how long it takes for our triggers to complete. On the slowest variation above with the SATA3 HDD, the trigger step could take up to 7 minutes, however on the Gen4 NVMe it would be done in about 2 seconds.

The team is looking at how to improve trigger performance, as any improvements in this area are the last real hurdle to having moss updates feel subjectively fast and smooth across a variety of less than ideal scenarios, such as older hardware and/or in virtual machines.

Our performance enthusiast, Joey Riches, is already testing various approaches, including parallelizing and/or coalescing the trigger actions as a way of improving the overall trigger wall clock run time. The real world impact of this will vary on a system by system basis, depending on how many cores/threads a system has available.

Wider Project Updates

Website redesign

The team have been working on the new project website re-design over the last month as a background activity. This will continue as a background task as and when the team have time, however progress is still being made.

The team aligned on the Hextra website theme last month, however there were a few features we would have liked to see included within the team (to avoid us having to use custom CSS to deliver what we needed).

Fortunately, the developer of Hextra is very active and a number of these features had already been requested and delivered in the main git branch of the theme.

One area we felt is important is accessibility. We fed back to the Hextra developer and he delivered a whole suite of updates to the theme to better conform to the WCAG 2.2 Level AA standard in the space of two weeks!

We see this as the benefit of open source projects and as part of our commitment to championing great open source projects, we would say, if you want to build a website, the Hextra theme is really good and the developer is active and engaged!

If you are interested or experienced in website design and want to help us out, join our Zulip server and get to know the team.

Documentation

Work is continuing on the documentation site with a focus this month on our FAQ section.

The team have split out the FAQ section into sub-sections and also reviewed the content and updated it based on the latest position of the project.

Notable changes include:

Split the FAQ section into sub-sections
Reviewed the documentation site for spelling mistakes and standardized around American English
Tweaks to existing content to ensure it is up-to-date
Added a clarification of why we don’t have a Discord server
Formalised our LLM policy on the documentation site

Donation methods

Over the last 3 months, we have been promoting the use of Ko-fi as our primary method of accepting donations. This month, the team reviewed its options, and subsequently created donation links directly through Stripe. Going forward, we are requesting that people donate through Stripe as the primary option, though we will still maintain Ko-fi as a secondary option.

The project already had a Stripe account as this is required for the easiest payment process from Ko-fi into our bank account. NomadicCore did a comparison of fees on a €5 donation (converted to local currency) from both Ko-fi and Stripe and found the following:

Donation method	Ko-fi	Stripe	Difference
Payout	37.34	37.35	0%
Stripe conversion fees	-0.75	-0.75	0%
Stripe processing fees	-3.01	-2.36	-1.74%
Ko-fi fees	-1.87	0	-5%
Voluntary Stripe Climate contribution	-0.37	-0.37	0%
Total	31.34	33.87	-6.77%

Note that the total payout does not match as these transactions were on different dates with slightly different conversion rates.

As such, total fees on a €5 donation reduce from 16.07% down to 9.32% when done via Stripe instead of Ko-Fi.

The downsides we have noted with Stripe donation links so far, is that donators are getting a confirmation screen but no confirmation email to confirm their donation has gone through.

Additionally, one area Ko-fi is justifying their 5% fee is the engagement aspect of being able to send us a message when making a donation and for us as a project to provide updates through Ko-fi.

At this stage, we believe our donors would prefer as much of their donation as possible to come through directly to the project, but will continue offering both options so as to enable supporters to make their own choice in this regard.

ISO refresh

We are releasing our newest Alpha ISO, AerynOS 2026.02, which includes the updates we’ve worked on since the start of February, and which features the 6.18.15 kernel.

The link for our 2026.02 ISO can be found on our download page.

Next Steps

Package addition soft-freeze

As mentioned in the intro section, we are putting new package additions in soft freeze, until our tooling and infra capabilities mature to where they need to be for efficiently managing long term growth.

During this period, additions with little or no reverse dependency rebuild chains will be strongly preferred. Luckily, most Rust (and Go) packages follow this pattern.

Invasive toolchain and full-repo rebuilds

During March, our goal is to complete a set of relatively invasive stack upgrades, including upgrading our Python stack from 3.11, and updating to LLVM 22, once the latter has seen a point update or two.

Once both have been completed, we plan to do a full recipes repository rebuild to ensure all of our packages are up to spec.

General recipes repository housekeeping

As part of our documentation push, we are cleaning up our recipes repository to simplify management and increase reliability.

The stringification of version fields represents one of these cleanup tasks.

In March, we expect to also simplify our recipe license headers and look at how we might make our recipes repository properly REUSE compliant.

Versioned Repos, phase2 work

Last month, we reported that this was now a short term target. We are happy to report that during February, we successfully completed the overall design of our moss-format upgrade process.

This includes a revised on-disk repository format that reuses the design work we did for Versioned Repos, phase1, but which rejiggers (yes, that’s the scientifically accurate term) things to account for our new moss-format repository “root index” feature.

The “root index” feature will show older moss clients how to seamlessly update themselves and user systems, in a way that automagically enables support for new repository and .stone format features.

It will also be responsible for handling repository “tag” versions as well as our “stream” concept.

This is the final step towards realising the core tenet of tooling-based “Install once, update forever” support across packaging format upgrades, which has been our guiding star since the inception of the project.

When completed, this will in turn enable us to begin to tackle some long-standing issues in our tooling and our recipes repository, that we have until now been unable to rectify without significant disruption to installed systems.

Supporting the project

If any hardware vendors are interested in sponsoring the project either financially or through hardware sponsorship, this would be warmly received.

If you wish to discuss other sponsorship details, please reach out to us at contact@aerynos.com.

Sponsor AerynOS

Thank You!

In that vein, we would also like to give Framework Computers a shout out for their generous support in the form of hardware sponsorship for project members now and in the past.

January 2026 project update

Jan 30, 2026

NomadicCore

Comms

Ermo

Co-founder

AerynOS: January 2026 project update

Fresh Start

Kicking off 2026, activity across the AerynOS project has been moving at pace. As covered in our 2025 retrospective, last year the team laid the groundwork for the project’s future growth and development. Starting off 2026, the team is building upon this foundation to keep delivering progress across the project.

From a core tooling perspective, we are preparing for the next phase of our Versioned Repository feature set. During January, we have been refining our existing codebase to make future improvements easier to implement. Once delivered, moss will be able to update itself seamlessly through what would otherwise have been breaking changes to its codebase. This functionality will be very important for our long term goals as a rolling release distro where you never have to reinstall to receive the latest updates.

Progress has been made around our branding with efforts towards a new website design and a healthy discussion and proposals for a new AerynOS logo.

You may recently have seen that AerynOS is taking a stronger stance against the use of LLMs and generative AI. Our LLM policy can be found on GitHub and will be replicated on our website in due course.

Additional progress has been made project-wide on our documentation and we have also made improvements to our CDN setup for improved package delivery.

Our efforts seem to be received well, as we are seeing an influx of new members joining our Zulip server and getting involved with AerynOS, whether through general discussion or through packaging efforts. We have also seen a jump in our followers across our various social media accounts and generally a more positive reception of what AerynOS is trying to achieve in the Linux space.

What’s new in the distro

Package / stack updates for this iteration include:

COSMIC 1.0.3
GNOME 49.3
KDE Frameworks 6.22.0
KDE Gear 25.12.1
KDE Plasma 6.5.5
brush 0.3.0-dev (bash compatible shell written in Rust)
dankmaterialshell 1.2.3 (build your own wayland desktop experience in material design style)
firefox 147.0.2
fish 4.3.3 (user friendly shell written in Rust)
foot terminal 1.25.0 (fast, wayland-native terminal emulator)
ghostty terminal 1.3.0-dev (virtual terminal written in zig)
glibc 2.43+git.144ba302
lact 0.8.3 (gui for tweaking gpu voltages, fan curves and frequencies)
linux 6.18.7
mangowc 0.10.10 (wayland compositor with eye candy effects)
mesa 25.3.4
nodejs 24.13.0
pipewire 1.4.10
prism-launcher 10.0.2 (minecraft launcher)
qemu 10.2.0
quickshell 0.2.1 (building blocks for wayland compositor-based desktop experiences)
ruby 4.0.1
thunderbird 147.0.1
vscode 1.108.2
vscodium 1.108.10359
wine 11
zed 0.221.4 (text editor written in Rust)

… along with sundry additions and updates.

Desktop Updates

Cosmic

Cosmic Install

Given System76’s move to a more regular release cycle for Cosmic DE, we are able to land updates to our repository more frequently. This month, System76 landed Cosmic 1.0.3 with some key updates including support for rounded corners and window shadows across all applications and additional appearance settings being made available.

Cosmic context
Section titled “Cosmic context”

AerynOS is following System76’s “Epoch” git branch for Cosmic DE. This is where System76 stages new updates to the Cosmic ecosystem before publishing new point releases. As such, our Cosmic package is actually somewhere between 1.0.3 and 1.0.4.

Given that Cosmic 1.0.4 has been released, it will be included in our repository shortly. It may already be there by the time you read this blog post.

Gnome

Gnome Install

This month sees the inclusion of Gnome 49.3 which is a stable bug-fix release with updates across the Gnome stack.

Some key updates include:

Nautilus file manager no longer wastes resources on images with larger dimensions
GNOME Control Center fixes for time zone searching and monitoring app filter changes in the Applications panel
Loupe improvements in performance

Plus many more fixes. See the upstream changelog for more details.

KDE Plasma

KDE Install

KDE Plasma has been updated to 6.5.5, KDE Frameworks to 6.22.0 and KDE Gear to 25.12.1.

The latest KDE Plasma update brings:

Improved XWayland app support
Krunner having better matching algorithms for what users are searching for
A bug fix to kwin to properly handle drag-and-dropped text

New Wayland Compositor Environments

With the increased interest surrounding AerynOS, we have seen some new contributors join the community and wanting to package up their favourite wayland compositors and supporting packages. Hence, after some mentoring, MangoWC and a gaggle of ancillary packages were landed this month, and they join the existing Niri and Sway wayland compositors in the package repository.

As a result, if you’re the sort who prefers to assemble your own Desktop Experience, we now have foot, quickshell and dankmaterialshell as a few examples of packages you can use as a base to make your Desktop Experience “just so”.

As a reminder, we do not include MangoWC, Niri or Sway as options to install directly from our lichen installer. Users interested in building their own Desktop Experiences on AerynOS can use our terminal-only option and then install their preferred Wayland Compositor and associated packages of choice from the command line.

Why not use our system-model?
Section titled “Why not use our system-model?”

Our new system-model approach can be used as a way of significantly simplifying the process of setting up a new AerynOS install by declaratively stating which packages you want installed on your system from a given repository (currently either Unstable or Volatile) and even being able to lock your environment to any given fixed-in-time stream update tag.

For more information about our system-model approach, please refer to the our previous 2025 in retrospect blog post

Infrastructure and Tooling Updates

debuginfod

This month, courtesy Joey Riches, we brought up a debuginfod instance at https://debuginfod.aerynos.dev! For those unaware, debuginfod is a service that finds and collects debug information in packages and hosts them to be downloadable over a simple Web API.

In practice, this means that debuggers such as gdb can automatically download the correct debuginfo files matching an executable’s build-id. No more manually searching for and installing the correct -dbginfo packages to successfully populate a backtrace with symbols.

To use AerynOS’s debuginfod service ensure you have https://debuginfod.aerynos.dev in the $DEBUGINFOD_URLS environment variable. Assuming you have libdebuginfod installed, this should be set up to work out of the the box.

-dbginfo packages are still available in the repository in case you don’t want to use debuginfod, or your tool of choice doesn’t yet support it.

This was only possible due to the work Cory Forsstrom put in that made our custom .stone binary interface available over FFI to C via libstone. This in turn allowed him to write a downstream patch to libarchive, the library used by debuginfod for extracting debuginfo from packages, for supporting our .stone package format.

moss error handling

The team have started work on refactoring error handling in moss with an early benefit being that download/unpacking errors will now mention the specific package that caused the error.

This is useful when troubleshooting, as it allows us to diagnose whether there is an issue with the user’s internet connection, or with the package itself on our server.

This error handling workstream will continue in the background to further improve the quality of human readable error output in our tooling.

Wider Project Updates

Website redesign

It has been clear to us for a while that the AerynOS website needs an update and this is something we have highlighted in previous blog posts. Following a review, the team has settled on using the Hugo static site generator with the Hextra theme.

Without going into a lot of detail, the Hextra theme is well maintained and has a lot of functionality built-in, meaning it is well suited to our use case.

NomadicCore has created a new branch on the dotcom repository to work on this in the background. Given the move between Static Site Generators and more generally the different content we want to present on the site, there is still a fair way to go.

If you are interested and want to help out, join our Zulip server and get to know the team.

CDN hit rate

Last year, the team set up Cloudflare as a CDN for our package repository and saw an improvement in download speeds. This was our first real experience administering Cloudflare and we left it pretty much in its default configuration.

This month, we spent a little time tweaking which parts of our repository it was caching for how long. The result has been a respectable jump in the cache hit rate.

The end result should serve to increase the consistency and speed of downloads within moss when using AerynOS from the unstable stream.

Documentation

CookieSource and NomadicCore have continued working on the documentation site over the last month.

The team have also updated documentation on the GitHub org including topics such as contributing, licensing, readmes and more. Some of these had fallen behind our latest position or had never been adequately fleshed out.

This effort is all intended to help interested parties get a better understanding of AerynOS and help them be able to contribute more quickly.

Notable changes include:

A new “Creating a new package recipe” page
Addition of a “How to submit a PR” page
The ability to view our documentation site as a single PDF
Updates to our contributing.md file across our GitHub organisation
The introduction of a policy around prohibiting the use of LLMs when engaging with AerynOS

GitHub vs Codeberg

One area of potential interest is around our use of GitHub. Over time, the team has become increasingly dissatisfied with GitHub for various reasons, including the increased push towards AI and the concern of not having control / sovereignty over our code and/or being locked out with no warning.

Looking to other solutions, Codeberg has come up as a potential alternative and one which the team has started using for internal operational documentation and personal projects, with the initial experience being generally positive.

Codeberg doesn’t do everything that GitHub can do, so if the team does look at moving its core repositories over, this would need to be planned carefully to ensure a smooth transition.

As and when we do make the transition to Codeberg, we would also like to sponsor them at the same time. An important tenet of AerynOS is to support and promote open source projects where we can. By way of example, its why we use Zulip (and previously Matrix) over something like Discord.

Sponsorship, where we are able, is another way we feel we can support the open source community and as our own sponsorship / income grows, we will be in a better position to contribute to the upstream projects on which we rely.

ISO refresh

We are releasing our newest Alpha ISO, AerynOS 2026.01, which includes the updates we’ve worked on since the start of December, and which features the 6.18.7 kernel.

The link for our 2026.01 ISO can be found on our download page.

Next Steps

We have spent the month of January taking stock of our future development direction, including short and medium term goals.

This has resulted in several nice refactors to how moss works internally, which will in turn make it significantly easier for us to implement some of the medium term features we have planned. It has also already helped us prepare a few planned features, such as better error messages and the in-progress moss fetch feature, which can be used to download packages in advance for testing purposes.

Next to that, we are steadily working towards delivering the Versioned Repos, phase2 infrastructure feature set, which is about teaching moss how to seamlessly auto-update itself across breaking on-disk moss-format changes with no user-interaction.

Currently, we are focusing on defining the necessary repository disk-layout and the format of the file at the root of the moss-format repo. This will show moss which updates need to be made in which order before the new package repository versions — containing new packages that rely on new package-management features — can be used.

Once complete, we will likely move our current repository layout to a legacy folder and test that older installs can update seamlessly in the process.

Due to the work done during 2025 on the infrastructure code-base, enabling the seamless format-upgrade process is now a short-term goal, which — when achieved — will in turn open up the ability to focus on medium term goals that were previously gated on this specific functionality.

We’re very, very excited about what this will enable us to do in the future!

Supporting the project

As mentioned in our previous blog post, our sponsorship goals in 2026 will be to continue growing our recurring sponsorships to help recover the backlog of historic project costs, and also to build up towards future hardware investments such as an x86_64-v4 capable builder.

If any hardware vendors are interested in sponsoring the project either financially or through hardware sponsorship, this would be warmly received.

Similarly, we are interested in and open to EU-based CDN sponsorship as a way of strengthening our package delivery and ISO download capabilities, and to lessen our dependency on US-based CloudFlare as a defensive measure. If you are in a position to help make this happen, we would love to hear from you.

If you are following along with our project and are in a position to support us, please consider donating via our Ko-fi page. If you wish to discuss other sponsorship details, please reach out to us at contact@aerynos.com.

Sponsor AerynOS

Thank You!

In that vein, we would also like to give Framework Computers a shout out for their generous support in the form of hardware sponsorship for project members now and in the past.

2025 in retrospect

Jan 2, 2026

NomadicCore

Comms

Ermo

Co-founder

2025 has been a year of significant change for the AerynOS project, not just in terms of development itself but also in name and in the staff working on the project.

We know many people will be following along, waiting for our beta and/or stable releases but for now we want to take a look back at 2025 and summarize what we have delivered and how that is positioning us strongly for 2026.

Camp Fire

The TL;DR summary:

We changed our name from Serpent OS to AerynOS. Aeryn is a different form of Erin, which means Ireland in Irish Gaelic.
The project founder, Ikey, stepped away from the project in mid April. A few weeks later, he sent an invitation to project co-founder and co-architect, Rune Morling (ermo), to be his Github account successor.
After these events, ermo asked the team if they would be interested in carrying on working on the project under his stewardship while waiting for Ikey to potentially make contact, and the team voted unanimously in favour of doing so.
Since then, the team has continued to deliver per the project roadmap:
- We completed the transition of all core tooling to Rust.
  - The new Rust-based infra has now delivered thousands of package builds while proving to be much more stable and robust than the previous implementation.
  - Leveraging Rust has enabled us to confidently deliver new tooling solutions like versioned repositories and a system-model approach to declaratively describe system installs.
- We improved upon the Cosmic DE offering whilst delivering new KDE Plasma and Console-based install options
- We onboarded several new staff members onto the project over the course of the year with differing strengths and interests
- We reworked our cloud hosting setup to deliver more build capabilities at lower cost base
- We renewed our media strategy through increased blog posts and engagement across social media platforms

What’s in a name

The first and biggest change we made this year was changing our name from Serpent OS to AerynOS. We are aware that, to some, this move was somewhat controversial. Our stance has been simple: A name takes on the meaning you give it.

Over time, we have continued to work to deliver on our goals for AerynOS. In return, people have become less focused on the name and more focused on what we are setting out to do, and what we are continuously delivering.

As an aside, we originally utilised AI tooling to create our logo, but this is not something we are overly comfortable with for the long run. We are looking at our options around either iterating on or creating a new “human made” logo where we can feel a lot more confident around licensing and ownership of the artwork itself.

The project founder steps away

In mid April of this year, Ikey went offline as part of a move, and subsequently never returned.

At the time, the team tried to reach out in multiple ways, however there has sadly been no reciprocation, other than ermo receiving a Github request sent from Ikey’s Github account to become Ikey’s account successor towards the end of the first week of May.

Taking into account Ikey’s experiences up until his move, we have made the assumption that his stepping back from the project was related to ongoing personal health problems for him and his family, which were compounded by significant financial strain as we understand it.

Note that, out of respect to Ikey and his family, we will not be elaborating any further on this. Needless to say, we wish him and his family the best and hope that they will have found a way through their travails.

As Ikey has left us with no way to contact him, we cannot share with you how to directly support him financially. All we can say is that you may be able to do so via his personal GH sponsors account, @ikeycode, though we stress that we have no way of knowing whether he will actually be receiving any money you decide to send that way.

Team regroup and reset

To ensure the project would be able to continue in the short and medium term, and on the basis that he felt that the promise of the tech and the underpinnings of AerynOS were too good to be left to languish and wither away, ermo asked the team whether they would like to continue working under his stewardship while we awaited news from Ikey. The team voted unanimously in favour of doing so.

Hence, for the initial couple of months, our focus was to continue delivering as a project, while allowing Ikey the space and the time to return once he’d had a chance to regroup and recover. This included letting all project sponsorship (including Ko-fi sponsorship) flow directly to Ikey.

As time progressed and the likelihood of Ikey getting in contact and returning grew dim, we needed to be in a position to actually have control of project assets and went about gaining said control in order to be able to keep the proverbial lights on.

With the exception of the original AerynOS X account, we have regained access to all relevant accounts, and have continued delivering on the project goals in the meantime.

We have done our best to not let any of this negatively impact our early alpha testers’ experience of the project, and feel that we have largely succeeded in doing so. The only real hiccup was a few months of reduced package delivery from mid April to late May, where we worked flat out to restore our ability to deliver package updates via the then under-development Rust infra port, after the old Proof-of-Concept DLang infra broke down completely.

We are now 9 months on from Ikey stepping back, and taking into account that we have not heard from him and that he explicitly designated ermo as his GH account successor, we are in the final stages of offboarding him into an inactive project alumni role.

We would like to stress that, as a project, we hold no ill will towards Ikey, and that we simply wish him the best. There is no hiding that his work was foundational to AerynOS with respect to both the tooling, the distribution itself, and the vision & ethos he promulgated for the project. We simply would not be where we are now as a project without his years of forward-looking engineering efforts.

At the same time, we think the present blog post will serve to outline why, based on our ability to deliver up until now, we are confident in our ability to continue developing AerynOS and its tooling into the future.

Infrastructure & Tooling development

Late March and April also saw the start of the porting effort of our infrastructure from DLang to Rust. The approach for this porting effort was to develop a so-called “Minimum Viable Product” (MVP) code base that could iteratively be improved.

After several months of development, in late May we started delivering packages to users again, which had all been built from the new Rust based infrastructure code base. This effort included a full rebuild of the whole recipe repo at the time to ensure ABI sanity of the newly built packages.

The development of our infrastructure didn’t stop there. Throughout the year, the code has been continually developed and expanded upon to land new features. In the last three months, the team has successfully delivered an MVP of the Versioned Repositories feature and an accompanying system-model feature as two very important examples of this.

Versioned Repositories

When fully fleshed out, Versioned Repositories will allow the team to seamlessly deliver improvements to our os-tooling (moss and boulder) in a controlled fashion. This is important as AerynOS is a rolling release distribution, meaning we need to be able to deliver improvements to users’ systems without breaking them or requiring complex manual upgrade procedures.

From a user perspective, it will open up the ability to decide which version or “update stream” of our repositories they want to use, for example opening up the capability to “lock” their system to a specific release or point in time, or eventually opening up the capability to use release-candidate or in-testing package builds that wouldn’t otherwise make their way into the “standard” AerynOS Repository.

In short, users will be able to use Versioned Repositories to easily choose a more stable and cautious repository or conversely to choose a more bleeding edge repository based on their needs and desires for their systems.

More broadly speaking, Versioned Repositories will also eventually allow for layered repositories for x86_64-v3 and -v4 packages to sit above our baseline x86_64-v2 repository where we see worthwhile improvements in building -v3 and -v4 packages. AerynOS’s approach here will not be to rebuild full repositories of -v3 and -v4 packages, but instead to overlay these packages on top of the x86_64-v2 repository only where there are verifiable gains to be found by doing so.

In a similar vein, this development workstream will eventually enable us to build repositories targeting ARM and RISC-V instruction sets. This will be a ways down the road and the team would need to acquire ARM and RISC-V builders at the appropriate time, but we want to foreshadow this to highlight that our current up front planning of our infrastructure development roadmap will enable very flexible use cases down the road.

system-model

The system-model approach we are currently developing, is at its heart a declarative definition of the packages comprising a system and where they come from. The team has just landed the first iteration of this to users, and this — along with Versioned Repositories — will continue being a development focus into 2026. The system-model approach declares the repositories & packages a user wants to sync their system against. This is currently an opt-in solution with moss now automagically generating a system-model.kdl file each time a moss transaction successfully completes.

The team has multiple future ideas of how this system-model can be used with a few examples including:

Sharing your system-model.kdl file for reproducing your system state for issue tracking and resolution
Using your system-model.kdl file as part of your install to get your system exactly how you want it at first boot
Changing your system by updating packages and then reverting back to your desired system-model on next sync
Being able to pin to older Versioned Repositories (for stability’s sake) or if issues occur on the latest rolling Versioned Repository until it’s fixed

All of these features, particularly where users could potentially face issues with their installs, are complemented by our offline rollback feature, which gives the ability to manually go back to either of 5 earlier states from the bootloader. This will ensure that users have both offline and online protections to help them recover from a misbehaving system.

Team organisation

We kicked off the year with looking for support in 4 key areas:

Community management
Documentation
Translation
Web development

As the year has gone on, NomadicCore, Jplatte, bhh32 and CookieSource have joined the team bringing with them a vast amount of experience and enthusiasm.

It’s fair to say that community management and documentation development have taken significant steps forward. Web development is a work in progress area with plans being formulated for an eventual re-write of our main website, which frankly needs a lot of work. Translation efforts have been paused (or more accurately never started). The team is prioritising building out the core infrastructure and tooling first, with distro polish taking a back step until the tooling is ready for it.

Website development

The current state of our website leaves a lot to be desired. We are aware that it needs a full refresh, not only for presentation, but also to include important information as a bare minimum.

The team are looking at options such as Zola and Hugo as alternative Static Site Generators however this is a low priority workstream for now. We are open if anyone has experience in website design and would like to work with the team to develop our website into something to be proud of.

Distro updates

DE and WM updates

Over the course of 2025, the team have continued to keep Gnome packaging updated whilst improving upon Cosmic through to its latest stable release. In addition, Reilly Brogan was able to get KDE Plasma packaged up, which expanded our recipe repo size by almost 50%.

All three desktop environments have proved to be stable, though it needs to be said that Cosmic overall has a way to go for true maturity.

We also decided to include a terminal-only option in our installer, which can be used to install and tweak e.g. Sway, Niri (and soon MangoWC) based custom Wayland environments almost from scratch.

For now, we don’t have any concrete plans to package up additional DEs or WMs for AerynOS. There are “enough” options for early alpha testers and our core team to work from, and any additional options would simply add an extra maintenance burden on the team that would in turn detract from necessary tooling, infra and overall feature and integration work.

In terms of future potential, it’s worth mentioning that AerynOS is first and foremost a forward-looking, Wayland-aligned project, which means that Wayland session support is a minimum requirement for any future DE or WM additions to the repository.

Installer

At the start of this year, Ikey shared initial screenshots of a GUI based installer that would eventually replace our text based installer as the primary installation method. With Ikey stepping back from the project, the development of this GUI installer took a back seat to allow the team to focus on higher-priority items such as delivering working infra.

Recently, one of our new staff members, Bryan Hyland, began working in the background on a new GUI based installer to eventually fill this role.

To put it simply, the idea is to eventually use the newly developed system-model approach to define the packages that would be installed per DE / WM and also allow users to use their own custom system-model.kdl files as the basis of an installation.

Sponsorship

With Ikey stepping away earlier this year, for a period of time, it was unclear whether he would be returning or not. As the months passed by, the prospect of his return grew less and less likely. Therefore, as covered earlier in this blog post, we are now in the latter stages of formally retiring Ikey from the project.

As mentioned previously, at the start of this year, the sponsorship was set up in such a way that all funds were sent directly to Ikey in order to enable him to afford to spend time working on the project and its underpinnings.

However, in light of Ikey’s continued absence, the team has taken control of the AerynOS Ko-fi account and redirected the funds from it so they can be used to cover ongoing project running costs.

All other references to sponsorship routes have been removed, leaving Ko-fi as our only official sponsorship medium.

Due to the way Ko-fi sponsorships work, at the point of transition, we had to cancel all existing sponsorships. We are not yet at the point where we are at parity in sponsorship income compared to before they were cancelled, however, we are fully covering direct project costs.

Part of this ability to cover direct project costs can be attributed to how we are spending our money and how we are utilizing as much of our own internal resources (such as ermo’s machines) for build capacity. We have also been developing our infrastructure code base to make it as flexible as possible in terms of adding new builders and scheduling builds efficiently based on individual builder resources.

Our sponsorship goals in 2026 will be to continue growing our recurring sponsorships to help cover the backlog of historic project costs, and also to build up towards future hardware investments such as an x86_64-v4 capable builder.

If any hardware vendors are interested in sponsoring the project either financially or through hardware sponsorship, this would be warmly received.

Similarly, we are interested in and open to CDN sponsorship as a way of strengthening our package delivery and ISO download capabilities. If you are in a position to help make this happen, we would love to hear from you.

If you wish to discuss sponsorship details, please reach out to us at contact@aerynos.com.

Sponsor AerynOS

Going into 2026

For now, there is a deliberate, continued focus on our os-tooling and infrastructure code bases, somewhat at the expense of delivering a fully featured Linux distribution for end users.

As time goes on, the goal is for this balance to naturally shift as our code bases become more capable and featureful.

Over time, and as logical consequence of this shift, we hope to be able to onboard more contributors to help us scale out the recipe repo, once the tooling is in a state where it conveniently allows for this.

If any of this has piqued your interest and made you want to contribute, we invite you to join us over at our Zulip chat platform.

Hope to see you there!

November + early December 2025 project update

Dec 9, 2025

NomadicCore

Comms

Ermo

Co-founder

AerynOS: November + early December 2025 project update

As we near the end of the year, the team has been reflecting on how best to position itself going into 2026. Over the course of November and early December, the team has made a number of changes, some of which have been public facing which you may have already seen if you’ve been following our socials.

On the public side, the two most visible changes has been our transition away from Matrix to Zulip for our instant messaging chat platform, and our transition to netcup for our server requirements. In the background, the team has also changed email hosting providers, however no one would really have noticed any difference there.

Packaging updates are progressing nicely with a nice rhythm for Cosmic and KDE stack updates, which along with fixes to reported issues is all helping to improve the overall experience for the people testing and checking out AerynOS.

On the infrastructure side of things, we have landed simple auto-pruning logic into our Vessel repository manager. This sort of automation ensures that we keep our repository lean and mean.

Things are progressing nicely in terms of getting phase 1 of our Versioned Repositories infra feature ready for production use. It was designed to from the outset to mesh nicely with our Moss system-model feature. Internal testing on a private infra instance has been running smoothly with these new features so far.

What’s new in the distro

Package / stack updates for this iteration include:

COSMIC Beta9
GNOME 49.2
KDE Frameworks 6.20.0
KDE Gear 25.08.2
KDE Plasma 6.5.4
bash 5.3.8
buildah: Add at v1.42.2
docker 29.0.4
ffmpeg 8.0.1
firefox 146.0
gamemode: Add at 1.8.2
linux 6.17.10
llvm 21.1.7
mesa 25.3.1 (with Vulkan anti-lag support enabled)
openvpn 2.6.17
prism-launcher 9.4
scx-scheds 1.0.17
sudo-rs 0.2.10
uutils-coreutils 0.4.0
vim 9.1.1896
vscodium v1.106.37943
wine 10.19
xwayland-satellite 0.8
zed 0.210.4
zlib-ng: 2.3.2

… along with sundry additions and updates.

Desktop Updates

Cosmic

Cosmic Install

Our Cosmic packaging team have automated much of the update process based around the more frequent git tags that the System76 team are now publishing for the Cosmic Beta phase. As such, we are more quickly able to push updates out to our volatile repository for eventual availability in our unstable repository.

As an aside, we believe we have fixed the issue for Cosmic DE sessions where USB devices were not automatically showing up, by adding gvfs as part of the Cosmic pkgset. This is a fairly important usability feature so great to have it fixed.

We have also fixed the issue we reported in our October Project Update blog post about sudo-rs not functioning correctly on Cosmic Terminal and Ptyxis in our Cosmic session.

Overall, Cosmic is progressing nicely in general and we are polishing the experience on AerynOS in lockstep with Cosmic Beta9 having landed in our repositories.

Additional details about Cosmic can be found on System76’s website.

Gnome

Gnome Install

As usual, there isn’t really much to say wrt. GNOME. The team has updated it to 49.2 and it is running nicely as expected.

KDE Plasma

KDE Install

KDE Plasma has been updated to 6.5.4, KDE Frameworks to 6.20.0.

As part of these updates, Reilly added a few custom patches to better support monitors with high refresh rates.

Infrastructure Updates

Auto-pruning in vessel

The new auto-pruning feature in our Vessel repository manager service means that our infra will periodically (currently daily) review what packages are present on our server storage versus which packages are reachable via a repository index.

If packages are no longer reachable via a repository index, they are considered surplus to requirements and pruned.

Automating this workload ensures that our storage doesn’t fill up and that our repository looks after itself over time, freeing the team from encountering unpleasant surprises in the form of having to take corrective action as storage fills up.

Wider Project Updates

Transition to netcup for our server requirements

As part of a wider review of our requirements, the team looked at how we were using our server and whether it was “right-sized” for where we are as a project. The project has shifted over the last 7 months to more heavily using ermo’s four private servers, meaning the “main” AerynOS build server hasn’t been utilised as effectively. Therefore, the team took the decision to sunset this server and look for a server better specified for repo hosting and infra coordination. To this end, we settled on a netcup “root server” based in Germany (where the old server was based in Finland). The netcup server has a 2.5Gbit NIC and has — for European users at least — yielded significantly faster download speeds.

It is still early days, however we are very pleased with our transition to netcup. Their support offering during our initial set up phase was both responsive and very helpful.

Transition from Matrix to Zulip

We want to preface this by saying we love what Matrix is doing by providing a federated open source instant messaging chat solution for users.

However, for AerynOS specifically, we have been having a few issues with our matrix space, partially in administration and partially around federation and delays in messaging (or in some cases, some users not able to see messages from other users in one room but they could in others).

As a team, we looked at what other options were available, and considered what our requirements were before eventually deciding to try Zulip on for size.

After trying it internally for some time, it quickly became clear that it offers great instant messaging capabilities like Matrix whilst also offering many other features such as asynchronous conversations (threads/topics) that allow users, contributors and staff to better focus on the various project conversations that fall in their sphere of interest or responsibility.

Like Matrix, Zulip is an Open Source Project and it also has hundreds of integrations that help elevate the overall User and Moderator experience.

Initial feedback from our wider user base has been overwhelmingly positive and we are excited to continue on this journey!

For transparency, Zulip has a policy of supporting Open Source Projects, and has generously sponsored the AerynOS project with a standard cloud server instance at no cost.

Please feel free to join our Zulip server and get to know the community that is building up around AerynOS.

Transition to Migadu for emails

The team had a look at the options available in the market for emails and decided to make a transition to Migadu’s offering, after Migadu offered us an OSS project discount.

While it does require a little more set up than other providers out there, it has the substantial benefit that you can set up as many email addresses on your account as you want or need, without this impacting the cost base.

This will undoubtedly prove helpful for the project going forward.

Logo / Branding / Website progress

The team has been looking at our branding and reviewing our requirements. It’s safe to say that if we didn’t have to update these, we would keep them as is as there are other higher priority activities.

However, if we take the logo itself, it was created using AI tools, so doesn’t really line up with our project ethos and does leave questions over licensing and ownership.

As such, we have been looking at what we might want from a logo and how it can best represent AerynOS. In keeping with this, we have also been looking at our wider branding including the colour schemes that we use.

Given that the naming conventions for AerynOS’s infrastructure and tooling projects all link to nature, we are leaning towards a nature oriented colour scheme going forward.

Lastly, we have been looking at our website which is in dire need of work. We currently use Astro for the website, however we have found that to be a complex solution. This is especially true as none of the current team / wider contributor base has much experience with Astro. We have been looking at the field of Static Site Generators (SSGs) and have shortlisted it down to Zola and Hugo, both of which are meant to be much easier to work with than Astro.

Zola is the preferred option with it being Rust based, however it’s fair to say that it is a much smaller project so doesn’t have anywhere near as extensive a theme library to choose from. Hugo is a larger / more mature project with greater theming, but is tied to Go which would create an additional maintenance burden outside of the team’s core focus.

Outside of existing themes, one option is to create (and subsequently maintain) a brand new theme, but this requires expertise and would place a burden on the team to ensure compatibility and that everything is updated within the template as time progresses.

If you have experience in website design and would like to help create / shape a redesign for our main website, then please join us on our Zulip server so that we can discuss how to move things forward.

Documentation website progress

With new contributors coming on board, our documentation website has seen significant updates in both content and in presentation. Whilst still a work-in-progress project, it is becoming more usable with less gaps. The team and wider contributor base continues to push updates, the big outstanding one being how to create new package recipes from scratch.

Once these gaps are filled in, it will become an iterative exercise to make sure our documentation stays updated and potentially go down into further detail where feedback suggests this is necessary.

Download choices and BitTorrent

Another area we have been reviewing is how we serve ISO downloads to our users. We currently only offer a direct download via our package server behind a CDN. As a small operation, this has suited us well enough, however users in certain locations don’t necessarily benefit from this solution.

We have had the BitTorrent option on the board for a long while now, and over the last couple of weeks, we silently added a torrent link for the AerynOS 2025.10 ISO. With the 2025.12 ISO we are taking this approach forward. This will have a secondary benefit of reducing the load on our server / CDN at the point of ISO releases, as bandwidth is naturally distributed due to the torrenting approach. We will continue to offer direct downloads for anyone who prefers this option.

ISO refresh

We are releasing our newest Alpha ISO, AerynOS 2025.12, which includes the updates we’ve worked on during the month of November and the first week of December, and which features the 6.17.10 kernel at the time of upload.

As usual, this is a Live GNOME ISO that contains our Alpha/PoC lichen installer. Hence, installing AerynOS requires a network connection over which the latest pkgsets can be downloaded and subsequently installed onto a dedicated AerynOS target hard drive.

The link for our 2025.12 ISO can be found at our download page.

Next Steps

The rest of december is dedicated to bringing phase 1 of the Versioned Repositories feature PR here and its associated Moss system-model companion feature PR here up to snuff and landed for the general public.

As mentioned in the introduction, these PRs are already in testing, and merely need some final bits and bobs wrapped up before they can be landed and put in production.

The fully realised Versioned Repositories feature will enable us to deploy new Boulder and Moss features in a seamless fashion. It will allow us to introduce breaking code and on-disk format changes, that would otherwise cause installed systems to require manual intervention for them to continue to receive updates.

Once Versioned Repositories are in place, the goal is that users will be able to simply update and sync their system as normal via the sudo moss sync -u command.

With this:

Users will be upgraded to the new versions of Moss that uses a new repository format, without having to pay special attention.
It will enable AerynOS to iteratively expand the capability of Moss and Boulder on existing systems without breaking user systems in the process.

Going further, we consider Versioned Repositories a pre-requisite for what we call “try-builds” and eventually for multi-arch support.

Automated try-builds denotes the process whereby the infrastructure discovers an update to the upstream source repository of a package, attempts to auto-update the recipe and then attempts to build the updated package recipe in question.
We think this will be a useful tool for contributors as it will automate some of the packaging tedium related to simple package version updates. It will also help enable automated regression testing and build flag optimisation in a future workstream.
Included under the multi-arch umbrella is our ability to target ARM, RISC-V, and different x86 architecture levels such as x86-64-v3 and v4.

Supporting the project

Following the October blog post, we had a flurry of new donors whom we want to thank for supporting our project. Their support is greatly appreciated, especially given the global cost of living crisis leaving less money in peoples pockets each month. Your support means a lot to everyone on the project as it shows the faith you have in the work we are doing!

2025 has been a significant year for the project, with the team having landed our new Rust based infrastructure, repository-wide rebuilds along with landing KDE and significantly improving our Cosmic offering whilst also landed new features into our tooling. We see our Versioned Repository work continuing into 2026, and this will eventually help lift AerynOS into becoming a serious offering in the Linux distribution space. Onwards and upwards!

If you are following along with our project and are in a position to support us, please consider donating via our Ko-fi page.

October 2025 project update

Oct 31, 2025

NomadicCore

Comms

Ermo

Co-founder

We are firmly in the final quarter of 2025 and what a year it’s been so far. In our last blog post at the end of September, we mentioned that we were delaying the release of our next ISO into October to give our Gnome 49 stack (and the wider extensions ecosystem) more time to mature.

Coming into the final week of October, the team made the decision to transition from clang’s libc++ to GNU libstdc++ and work through the associated rebuild requirements across our repository.

We also mentioned in our September blog post that we had reached the point of having stable build infrastructure. However, over the course of October, we had an old problem re-appear, which proved somewhat vexing to solve initially.

After the issue was debugged, and a fixed version of boulder was deployed to the build infrastructure, we used the transition back to libstdc++, which included hundreds and hundreds of rebuilds, and the landing of the KDE Plasma 6.5 stack to verify that that we have put this particular issue behind us.

In addition to the build infrastructure related boulder fixes, the team has also found the time to hash out a design for, and prepare an early prototype PR of, the moss declarative system-model feature, as well as landing a few small user experience improvements and correctness fixes to both moss and boulder.

With that all said and done, we are ready with our 2025.10 GNOME Live ISO refresh for you to enjoy along with this blog post.

Whats new in the distro

Package / stack updates for this month include:

KDE Plasma 6.5.1
Cosmic Beta3
Gnome 49.1
Linux 6.16.12
Mesa 25.2.5
KDE Frameworks 6.19
KDE Gear 25.08.2
llvm 21.1.4
uutils-coreutils 0.3.0
sudo-rs 0.2.9
ffmpeg 8.0
pipewire 1.4.9
Wine 10.17
nodejs 22.21.0
zed 0.206.6
virt-manager 5.1.0
bash 5.3.3
scx-scheds 1.0.16
vim 9.1.1829
systemd 257.10
uv 0.9.5
perl-module-build: Add at v0.4234
libdovi: Add at v3.3.2
openconnect: Add a v9.12

… along with sundry additions and updates.

Desktop Updates

Cosmic

Our Cosmic environment has seen additional testers and contributors coming on-board to support Bryan who we highlighted in the previous blog post. Our Cosmic packaging team’s approach is to use System76’s repo-release repository rather than waiting for git tags. The team are running roughly on a bi-weekly update cycle keeping us up to date with Cosmic’s development where we had previously fallen behind. At the time of this blog post, our versions are tagged at Cosmic Beta3, however the code is somewhere between Cosmic Beta3 and Beta4, and Beta4 is being worked on as we write this.

Known issues

We are currently experiencing an issue with sudo-rs in Cosmic Terminal and the GNOME Ptyxis terminal emulator in our Cosmic session, however the issue doesn’t present with e.g. the Kitty terminal emulator, which can therefore be used as a workaround for the issue. We are tracking this issue in our bug tracker.

Additional details about Cosmic can be found on System76’s website.

Gnome

The Gnome packaging team has updated our Gnome environment to 49.1. The team has also expanded the number of available Gnome packages in our repository, and we now include Showtime and Gnome-contacts in our gnome pkgsets accordingly. For clarity, these were added in September but were not mentioned in our previous blog post.

Gnome continues to work very well on AerynOS and remains as our default live installation environment.

KDE Plasma

Reilly Brogan has done a fantastic job landing KDE Plasma 6.5, KDE Gear 25.08.2 and KDE Frameworks 6.19.0 into our repository over the last month. The overall KDE Plasma experience continues to improve with users providing largely very positive feedback on its performance and fluidity on AerynOS.

Over the last couple of months, KDE Plasma has now also been promoted as a recommended installation option alongside Gnome.

Distribution Updates

Switching back to GNU libstdc++ from LLVM libcxx

The team decided to switch back to the GNU libstdc++ library from the LLVM libcxx C++ library as a defensive measure. This has resulted in us having to carry fewer patches across the stack, and has resolved a few bugs as a bonus. In particular, this has squashed an annoying bug related to the Firefox Widevine DRM plugin that in turn previously made certain video conferencing tools crash.

Packaging License Matching

New this month, when packagers use the boulder recipe new invocation to create a new recipe from an upstream source archive, boulder will attempt to identify the applicable license of the package, and add it to the autogenerated skeleton stone.yaml recipe file.

This is a nice quality of life and user experience feature for our packagers. The AerynOS ethos is to try to help lessen the burden on packagers by automating things that are simple in nature, yet time-consuming. This in turn, we hope, will enable packagers to spend more of their time on the parts of the packaging process that genuinely benefit from a human touch in terms of building a distro that they and users enjoy.

Parallelize the `moss state verify` command

Until recently, when employing the moss state verify command to ensure the integrity of all moss states, boulder was limited to running on a single thread. The team updated the moss state verify command to run certain tasks in parallel (using rayon) which has significantly reduced the time to complete the verification process.

The moss state verify command currently does not have any indication of progress such as a progress bar. As such, a user may be unsure if their system is frozen. Whilst parallelizing performance-sensitive aspects of this task significantly reduces the time to completion, we have an issue raised to add a progress bar to the command for an improved user experience.

Infrastructure Stabilization

As it turned out, the issue we kept seeing (and have kept seeing since May) where build tasks would hang for no apparent reason, was actually related to the boulder threading code leaving threads running at the point where we called the clone2 syscall to enter a user-namespace container for build isolation purposes — fearless concurrency indeed…

However, as these issues only manifested for us when boulder was invoked by the build infrastructure, and even then only rarely, it was not a problem we could trigger on demand.

After some head-scratching and debugging sessions where we attached debuggers to live builds that had happened to hang, we finally found the root cause, and in turn were able to simplify our threading code significantly by always using a dedicated, explicit runtime that gets automatically shut down once the parallel (rayon) or threaded (tokio) work unit goes out of scope.

This in turn now ensures that all threads have been shut down as required, before entering the cloned user-namespace container.

Massive thanks to Cory Forsstrom for the work he put into solving this problem very elegantly over a couple of Pull Requests.

moss `system-model` prototype feature

The system-model feature is inspired by the feature of the same name from the Conary system and package manager. However, in practice, it will likely end up more like a hybrid of the Conary feature and e.g. the simpler and more limited Gentoo (and FreeBSD) ‘world’ set.

We are still hoping to be able to, when the time comes, offer versioned system-models that match our planned versioned repository work.

The goal of the moss system-model feature is that it will eventually enable us to define, and switch between, system installs declaratively and seamlessly. This feature is slated to be suitable for use on both live systems, recovery initramfs environments, and for installing new systems.

It is important to note that the system-model feature will be an opt-in feature, and that it will continue to be possible to use moss in an imperative fashion, where the system state is defined by the sum total of historical moss operations executed on the command line.

The design we have settled on makes it possible in the future to import (“resolve”) a declarative system-model to an imperatively defined system, just as it will be possible in the future to export (“derive”) a declarative system-model of any given imperatively created moss system state.

We hope that, as we evolve and flesh out the system-model feature work, this will give both users and system integrators the flexibility they need to define their systems in ways that matches their requirements and preferences.

Wider Project updates

Donations

During October, we have made changes to our donation accounts and updated our site accordingly. Most importantly, the primary way to now provide donations to AerynOS is via our Ko-fi page.

Due to the way Ko-Fi works, we have had to cancel all existing recurring donations as the money would not automatically flow to our new accounts. We have sent messages out to our donors and are hoping that they will want to sign-up again to provide continued donations towards the project.

All donations received by AerynOS are going towards paying our running costs, reimbursing ermo for his project hardware investments, and building a buffer for acquiring new hardware once the current hardware reaches its End of Life.

Taken together, these three budget items result in a target income of around €500 per month, with a third of that projected to go to each of the outlined items.

Due to the cancellations mentioned above, we are currently down to €25 of new/committed monthly recurring donations.

Rest assured however, that this will not impact the project’s long term viability as we have the ability as a team to cover these costs. However, if you are able to provide any sort of donation, it would be greatly appreciated.

As a side note, we have also moved away from taking donations in USD by default and switched to EUR as this is the currency we are primarily spending in for our project costs. This does not preclude us from accepting USD based donations however.

Presenting the 2025.10 ISO refresh

Whilst we provide a bootable ISO image with a live GNOME environment, its main purpose is to serve as a vehicle for our ‘lichen’ installer which is able to install all of our ‘GNOME’, ‘KDE Plasma’, ‘Cosmic’ and ‘Terminal Only’ versions of AerynOS. Given that ‘lichen’ is a net installer, it will always pull the latest packages from our repository at the time of installation and as such, it requires an active internet connection. This means there is less of a need for regular ISO updates, as we have carefully designed our installation routine and our pkgsets to not be tightly coupled to the packages that happened to be available at the time of the live ISO creation.

Installer preview

That said, with the addition of some significant updates in the Gnome stack, we felt it was a good opportunity to land a new live ISO for you all to try out. The link for our 2025.10 ISO can be found at our download page.

Next steps

Going into November, the team will continue to execute on our development plans related to improving our infrastructure in terms of both capability and user experience, just as we will be continuing to work on improving our moss and boulder tools via their planned workstreams, particularly the moss system-model related workstream.

On a final note, we are progressing on the documentation front, and work is steadily trickling into our documentation site. Thank you to everyone who has contributed!

If you are interested in our work or generally want to hang out, the best place to join us is in our Matrix space. Alternatively, our Forums can be found on GitHub

September 2025 project update

Oct 1, 2025

NomadicCore

Comms

Ermo

Co-founder

As we reach the end of September, it’s time for another monthly update. For this month, we are deferring our technical blog post into October but wanted to provide wider project updates.

Kernels

AerynOS is currently running on 6.16.8. While we are aware that Linux 6.17 was released on 28th September 2025, the AerynOS team takes the view that for larger software stacks, the wise thing to do is to hold back for a few point releases after a major version update to ensure there are no unexpected issues.

Even though AerynOS is a rolling release distribution, we don’t aim to be on the bleeding edge just for the sake of being on the bleeding edge.

Gnome 49

The team updated to Gnome 49 within a couple of weeks following its release meaning it’s now available in our repository. Given the way Gnome updates and how extensions then follow suit, we are aware that many extensions have not yet been updated for compatibility with Gnome 49.

As such, we are holding back our next live installer ISO release until a larger number of extensions have had time to go through their own update cycles.

Infra stabilization

2025 has seen a massive lift in our infra code with the rewrite to Rust taking place in Q2, and its stabilization being pursued from the end of Q2 and up until now.

In this period, the team has been incrementally refining the code, and resolved bugs as they have arisen. This is work that average users will not have seen or been aware of as it only affects workflows behind the scenes. However, this has been extremely important work that has increasingly allowed us to become more confident in our new infra foundations.

We are now at the point where we are confident in calling our new infrastructure “stable”, with no bugs having presented themselves in several weeks and hundreds of packages built.

It cannot be overstated how much better the state of our infra is compared to the start of the year. In turn, this now allows us to focus our efforts in other areas of our technology stack to similarly work through bugs, implement features and generally refine our code base.

Cosmic maintainership

A couple of months ago we had a new contributor, Bryan Hyland, join us and begin working on the Cosmic stack. Bryan’s contributions have been invaluable to the team and we thank him for his engagement.

Unfortunately, due to personal reasons, he is having to take a temporary step back from the project. He has shared his methodology for providing updates to the Cosmic packages and we already have willing contributors from our community picking up the in-flight tasks.

We know he will be back once his circumstances improve, but in the meantime, if you are curious about supporting Cosmic on AerynOS, please do get in touch in our Matrix packaging channel as it’s always good to have several people capable of maintaining each of our DE stacks.

Web development

One area in which we often receive feedback is our website. Given we are in an alpha state, it has not been our highest priority to improve it. We do have a couple of interested contributors wanting to work on our website to help improve the overall look and feel of the project, though.

Hence, if you are interested in website design and want to lend a hand, please feel free to join our Matrix webdev channel as we will likely begin work on this area in parallel to our core development work.

Documentation

Similarly to our web development work, we are seeing increasing numbers of contributors willing and able to help with our documentation. Outside of our core tooling development, this is arguably our second most important workstream and another area in which we often receive feedback.

If you are interested in supporting our documentation drive, feel free to join us in our Matrix documentation channel.

Holidays

NomadicCore has been leading our social media presence for the last few months. Someone (unwisely) gave him permission to go on holiday for the next three weeks, which means that our social media presence is likely to be less active than usual in the interim.

Please do not take this as any indication of the project slowing down. If anything, we have an increasing number of developers working on different areas of our tooling stack and are seeing our development and packaging activity picking up.

October plans

We hope to release out next ISO in October, once:

We have landed the Cosmic Beta packages and have had a few weeks to shake out any bugs
Gnome extensions have had more time to update for compatibility with Gnome 49
We are a few point releases into the Linux 6.17.x kernel cycle and there are no confirmed bugs we need to address

We are also aware of the planned release of KDE Plasma 6.5 on the 21st of October 2025. Similarly to Linux 6.17.x, we are not planning / trying to be first out of the gate with a large stack update. This will likely land at a later point after a few weeks / a point release or two.

That’s it for this monthly roundup. Thanks for reading, and we hope to see you around in our community.

August 2025 project update

Aug 31, 2025

NomadicCore

Comms

Ermo

Co-founder

Closing out August 2025, we are proud to announce our third release of the year. This release follows an intense development period where the team has reevaluated its priorities / timelines and refocused efforts on “delivering core Linux distribution tooling that will simplify our ability to scale out over time”.

We have documented some of our progress in our last two blog posts and spent the last two months further progressing towards these goals. We have implemented a basic version of virtual packages (Package Sets), continued our hardware (and VM) enablement efforts and have selectively been growing our repository where we feel it’s beneficial to our users.

What’s new Distro-wise

Whilst not an exhaustive list, some of the top line repository updates include:

GNOME 48.4
Plasma 6.4.4
Sway 1.11
Cosmic Alpha 7
Linux 6.15.11
Mesa 25.2.1
LLVM 20.1.8
uutils-coreutils 0.1.0
sudo-rs 0.2.8
ffmpeg 7.1.1
fastfetch 2.51.1 (adds AerynOS logo)
Waydroid: Add at 1.5.4
openvpn: Add at 2.6.14
protontricks: Add at 1.13.0
winetricks: Add at 20250102

In addition, we fixed a subtle issue with our PATH configuration that mostly affected our console logins. With this fix, we have made our login experience fully stateless. We have also enabled sulogin for a single-user root shell to diagnose and repair boot failures.

Package sets

AerynOS is transitioning to a package set model for core packages installed on a user’s system.

Package sets are a collection of packages that are related or used together for a specific purpose. In AerynOS, they are used for consolidating our base system packages and for each of our offered Desktop Environments / Window Managers.

Each Desktop Environment offered by AerynOS has an associated package set (usually “recommended”). Depending on the environment, we may optionally offer a “minimal” and/or “full” solution with less or more packages to better suit our users requirements.

The package set model we have implemented is a stepping stone technology, not the final solution we are looking to implement. It introduces the basic premise of virtual sets of packages and is a precursor to our “system-model” work that will allow for exact reproduction of a user’s installed system.

Our installation experience with lichen

To fully integrate the new package set model within the AerynOS project, we have adapted lichen to install Desktop Environments based on the associated package set. The TUI (Text User Interface) prompts guide a user to select which DE they want, and depending on the DE, the version we have curated for the install (recommended for the DE’s, minimal for sway) with moss determining what dependencies are required for a successful install based on that package set.

Lichen is a network installer meaning that it downloads the latest set of packages from the AerynOS repository for installation. Tweaks to our package sets don’t necessarily require a new ISO. Whilst the “live environment” may not be up to date, the user will get a fully up-to-date installation without requiring a post-install update step.

lichen usability updates

In its current state, lichen requires that a user pre-format their disk prior to attempting to install AerynOS. Given its nature of being a network installer, lichen also needs an active internet connection to complete an install. Before, if either of these prerequisites were not met, the installer would output a very unhelpful Rust code error. We have added the appropriate prompts to guide users to ensure they have an active internet connection and to remind them that they need to pre-format their disk.

Whilst we could fix the pre-format requirement, a conscious decision has been made to keep this “anti-usability” feature as a barrier to entry for “beginner Linux users”. This may seem very counter intuitive, however whilst we are in an alpha state, we need to be careful not to position ourselves as a “beginner Linux distro” that could attract many support requests. We need to focus our time on developing our tooling and infrastructure.

Do note that in time, we will fix this issue and become more beginner friendly!

Virtual Machine usage and hardware enablement

Significant work has taken place to enable virtual machine support, both with AerynOS as the host and as the guest.

For host support, we have packaged virt-manager into our repository. The team utilised VMs for testing package set configurations and other potential breaking changes over the last month. It has sped up our development pace as VMs are more disposable by their nature.

For guest support, we have enabled a significant amount of hardware in our kernel and specifically enabled HyperV (based on user requests). We are also actively seeking user feedback for other VM environments. If you try AerynOS in other VM solutions and have any problems, you can report those issues here.

By better supporting both VM host and guest scenarios, we hope to unblock potential contributors from exploring our distribution and tooling.

Please note that we still classify AerynOS as alpha status project. We do not recommend anyone install it on hardware required for “production environments”! Our key goal is to enable the hardware / software that developers and contributors may need to make the transition to and/or explore AerynOS.

Other updates

Reilly Brogan has added scx-scheds to our repository and set scx_flash as our default scheduler. Scx_flash is a scheduler that is focused on ensuring fairness among tasks and performance predictability. More details about it can be found on the sched-ext website.

For our use case, this is helpful as it allows an AerynOS system to still be responsive whilst heavy tasks such as building packages are happening in the background.

Whilst this has been implemented in our ISO (ie. for new installs), it will not retroactively apply for existing installs. If you want to transition to this, you will need to install scx-scheds.

What’s new DE-wise

There has been considerable effort around our DE provision this year, some of which is yet to materialise. We are happy to report that we are now offering KDE Plasma in our repository and it will be installable from our ISOs going forwards.

In addition, we have created a console only installation option for more advanced users and for our own testing purposes.

KDE Plasma

It’s fair to say that KDE Plasma has been one of the biggest requests we have received and we are happy to report that it is now available in our repository. Reilly Brogan has done a fantastic job packaging up the latest 6.4.4 version into our repository with both sddm and plasma-login-manager offered as login managers.

A running bug tracker can be found here to report any issues. Please do test it out and help us find and resolve any undocumented bugs that remain.

We are far enough in our bring up and testing process for KDE Plasma that we are comfortable offering it as an installation option in our ISO’s going forwards.

Cosmic

Within the AerynOS repository, Cosmic DE sits at the release tag of Alpha 7. Given the significant pace of development of Cosmic, we are looking to move to a more frequent update cycle to incorporate bug fixes and new feature releases tracking System76’s repo-release repository. Whilst still in flux, we are looking at a bi-weekly update frequency to balance maintainer burden with keeping the DE up to date. The first of these updates bring Cosmic DE packages to their most recent versions will land in the AerynOS repository in the coming days.

Following recent engagement efforts, we have been seeing new users and contributors checking out AerynOS and specifically our Cosmic spin. Through this additional testing, we are seeing more active engagement on keeping Cosmic updated and bugs squashed. Given its alpha status, we don’t expect a fully bug free user experience so please bear this in mind if choosing Cosmic. We are classifying our Cosmic spin as a “Technical Preview” given that both Cosmic and AerynOS are currently in alpha status.

Moving forward, we are looking to package up more of the available Cosmic applets and generally polish the Cosmic experience on AerynOS. If you have an interest in packaging and specifically in the Cosmic Desktop, feel free to get in touch as we could always use more support in testing and improving upon our DE experience.

Sway

We have had Sway within our repository since early last year but did not really highlight its inclusion. Sway has been updated to v1.11 and we have also included Waybar and a few other packages to make ricing Sway a nicer experience on AerynOS.

We debated including Sway as an installable option from our ISO, however we have made the decision to defer this for a future release. We have created an initial “minimal” package set for Sway which includes the bare minimum to get started on ricing it. However, it has not yet been validated to a level that we are comfortable shipping it to users, even in our alpha state.

It remains in our repository and will continue being worked on as we progress into the second half of the year. In time, we would also like to develop a couple of pre-configured Sway configs as additional package sets so users not already familiar with Sway can jump right in without having as much background experience.

Console-only

In addition to the other environments, we have created a very minimal package set that will boot into the Linux console without any Desktop Environment. Users can use this console-only option as a starting point to configure a system install exactly to their requirements with only the packages they wish to have included or as the basis for a new DE/WM to be included within AerynOS.

Given the way we have layered DE/WM package sets over our base package sets, a user is able to install any of the other DE/WM options on top of this console only solution. This has been very helpful for the AerynOS team in testing our different offerings.

Gnome

Other than updating to the latest 48.4 version, there is not else much to say on GNOME. To its credit, it has been working smoothly on AerynOS so there has not been any major work required.

It remains our default option for our ISO live environment and should only require updating to new versions as they release. If you do happen to discover an “undocumented feature”, please feel free to report it here.

What’s new tooling-wise

Moss state diff

Joey Riches has delivered a new command “moss state diff” which allows users to check the differences between two states. This is very useful when you want to revert back to an older state.

Each state is identified as a number and there was no way to understand what a state had. With this new command, you will be able to inspect the state and see if it’s the right state that you are looking for.

The command requires you provide two state numbers and it will return back the differences in package versions and new / removed packages between the two states you have specified.

Moss search-file

We have also landed another new moss command “moss search-file”. This works similar to “moss search” however it works at the file level and enables users to ask moss to which package any given installed file under /usr belongs.

What we are working on

Packagekit and appstream generator work

Joey Riches has picked up and continued his previous packagekit integration for moss to integrate into our various DE software centres (GNOME Software, KDE Discover and Cosmic Store).

Until now, users could only install AerynOS .stone packages through the terminal. This integration is a significant usability upgrade though we still recommend our users have familiarity of how to interact with moss via command line.

Alongside packagekit, we now also have appstream meta data hosted on our dotdev site. Work is on-going with both packagekit and appstream but the groundwork is completed. We can build from this point towards fully developed software centre integration.

Once this lands in our repository, we will take another step towards making AerynOS a more user friendly distribution.

Documentation improvements

Outside of the code development, there is a renewed focus on our documentation site. This is a continuing and incremental exercise with improvements coming across the board.

Over the last few months, we have improved the FAQ page, added more information on how to update packages on an AerynOS system and added additional information around the Desktop Environments we offer. We have also added specific background detail about how AerynOS is different to other distributions on our Philosophy page.

We will continue fleshing out our documentation in the coming months, with a specific focus on how to contribute, both to the project itself and how to create packages and submit them for inclusion in our repository.

Some of the feedback we have received is that documentation is fragmented and/or not yet created. This is a frustration we can remove through our documentation efforts and we have new contributors helping out in this aspect too.

We are always looking for more support so if you have any interest in getting involved with our documentation efforts, please feel free to reach out on Matrix and specifically engage with NomadicCore.

Next steps

Our focus for the second half of the year remains similar to what we have detailed in our previous two blog posts.

We are working towards versioned repositories which will allow the team to deliver new features to our os-tooling (moss and boulder) in a seamless fashion. Versioned repositories are a prerequisite and gateway to future features that we will deliver in AerynOS hence its prioritisation.

For the os-tooling, we are adding structured logging for better insight and reporting, improving error handling and ensuring we deliver more helpful message output and looking towards adding JSON output for all of this for nicer parsing of “structured output” across process barriers. We continue to add low hanging fruit features

Download AerynOS

The link for our latest iso can be found at our download page.

Development update: os-tools

Jul 11, 2025

NomadicCore

Comms

Ermo

Co-founder

In our recent mid-year blog post, we mentioned that it would be the first in a short series of posts providing updates on the various work streams we have been actively progressing during the last few months. Whilst that post focused primarily on our infrastructure, in this one, we will shift our focus towards the work we have been doing around our os-tools.

Short overview

To recap, our os-tools consist of Moss and Boulder. Whilst also originally written in DLang, initial ports of these were built in Rust during the latter half of 2023. Though we made the odd improvement here and there during 2024, through Q2 2025 we set out to review the code, develop an improvement plan and then put that into action.

The TL;DR is:

Moss: Existing PRs reviewed, refined and merged (including a PR enabling faster package installation via parallel blitting). The code received various bug fixes and refactors for correctness and maintainability.
Boulder: Similarly, existing PRs reviewed, refined and merged including a few smaller features and packaging macros being added. Since Boulder uses the moss crate, it now builds packages slightly quicker due to faster buildroot creation. The odd bugfix was also made.
User Experience: Improved error reporting features were added to both Moss and Boulder to improve the troubleshooting experience for users and packagers. More to be done on this front.

We will be continuing our os-tools work over the coming months with a specific focus on tidying up the code, improving documentation, and ensuring better error handling and status reporting throughout the codebase. This will come in particularly handy when we do the feature work to make us able to produce JSON output as the final part of the alpha2 os-tools milestone.

Overall, this work will help users when they come across unexpected errors and also be beneficial when onboarding new developers.

The JSON output feature, in contrast, is largely targeted at convenient machine parsing of structured output for automation and integration purposes, which we are banking on will come in handy for future development work currently in the planning stages.

Introducing NomadicCore

Before going any further, you may have noticed my name as one of the authors of our mid-year update blog post. If you hang around our Matrix rooms, you will likely already know me but I thought it prudent to provide a formal introduction.

I first became aware of SerpentOS about three years ago but only joined the Matrix chat rooms in September 2023. I’m not actually a developer or have any coding experience, however, I am interested in open source projects and Linux distributions that can help me get the most out of my hardware. I liked what I saw with SerpentOS and over the course of 2024, started getting involved, trying to help out where I could.

Earlier this year, I ended up formally joining the team, around the time of the AerynOS rebrand, taking more of a support/communications role and providing feedback from an “average user” perspective of what I think might be important.

My focus will mainly be around working on our documentation, writing blog posts and engaging on our various social media platforms and Matrix rooms. I’m looking forward to getting stuck in and helping support a Linux distribution I want to use on my various devices.

A deeper dive into our os-tools work

Since their port to Rust, our os-tools have been working well enough. However, we are self-aware enough to know that our initial porting efforts left room for improvement, both in code quality and performance.

The following subsections outline some of the os-tools work we have been doing throughout Q2.

Refactor work

Both tarkah and new contributor, Jonas Platte, have been working on refactoring our existing codebase. To increase the available insight and diagnostic information, we have decided to align around the use of the tracing crate given that important parts of our code base are asynchronous, for which tracing is particularly suited.

For error handling, Jonas suggested that we move away from thiserror towards snafu. Whilst thiserror suited our requirements during our initial porting work, snafu offers some nice quality of life features and forces us to be more explicit about handling different types of errors, which we hope will yield better longer term maintainability. Moving over to snafu requires a little more upfront work to get high quality error output, but we believe that the reward will be worth it once the transition is completed across all of our code base.

Along with this refactor work, tarkah, Jonas and ermo are also improving the documentation within the codebase itself. With the infrastructure code having been ported to Rust, there is now greater scope to reuse and consolidate code between the various tooling crates.

Keeping our dependencies up to date

One aspect of managing our tooling is ensuring that our codebase remains up to date. Part of this effort is also to ensure that we are updating our code’s dependencies to their own respective latest versions to benefit from bug fixes and performance improvements. Whilst this is an on-going task, some of our dependencies had been allowed to get a little stale. Through multiple commits, Jonas has systematically been updating the dependencies in our os-tools repo.

Part of this upgrade work also involved being able to lock dependencies for Rust packages as a way to ensure robustness of the Moss and Boulder builds we use in production.

Moss: Parallel blitting

Long-time contributor Joey Riches identified a parallelization improvement in Moss’s blitting process which was merged after several months of local testing.

In our testing, the code showed significant speedups across all three of our supported file systems (XFS, ext4 and F2FS). The previous single-threaded blitting made using ext4 and F2FS particularly slow, to the point that we did not recommend users use either filesystem as the basis of an AerynOS install.

However, blitting speeds with the new parallel approach — particularly with a “cold” kernel VFS cache — have significantly improved. Whilst ext4 and F2FS are still not as performant as XFS for our use case, they are at least more serviceable as the basis of an AerynOS install than they used to be. By way of an example, I saw a ~2x blitting speed improvement on my Gen4 NVMe SSD using XFS with the new parallel blitting code.

It’s worth restating that, to our knowledge, the moss approach to atomic updates, is the only one of its kind (at least in the Linux space) where users do not have to rely on containerization or A/B system swaps to deliver package updates. Eliminating download speeds as a variable, Moss is capable of atomically installing/updating hundreds of packages on your system in a matter of seconds to tens of seconds on SSD drives, and the installed/upgraded applications are ready to use next time the application is opened. No reboots and no messing with container permissions necessary.

Given that boulder also needs to blit files when it creates buildroots, the code has also had a positive impact on reducing package build times. This will be more evident on larger package builds and will have a cumulative impact, the more package work you end up doing.

Moss: Sync available before installed packages

As we were testing the upgrade path from our old packages.aerynos.com/volatile repository to our new, CDN-backed cdn.aerynos.dev/unstable repository, we ran into some unexpected small niggles related to how packages are resolved.

While tarkah’s fix to Moss was relatively small in terms of code, it served to ensure that updates would install properly on the first go when syncing to the new repo.

Consequently, we synced this bug-fix to the Moss version in the old repository to ensure that users will be able to seamlessly upgrade to the new rolling unstable repository.

Moss: Add index output directory option

As we were preparing the process for syncing the packages in our volatile build-server repository to our new downstream rolling unstable repository on our public-facing server, we ran into an issue with the existing moss index code path.

Before this issue was fixed, the stone.index file would be unconditionally written next to the actual package .stone files. This was useful when indexing local repos, but not as useful when indexing actual stone pool/ directories and sub-directories.

In the end, this was another small feature with somewhat large consequences, in that this enabled us to do the actual manual indexing in a way that is identical to how our infrastructure organizes things when indexing.

This in turns made it possible to make sure that the new rolling unstable repo presents with the same URI “pattern” as our volatile build repo:

❯ moss lr
 - oldrepo = https://packages.aerynos.com/volatile/x86_64/stone.index [0]
 - unstable = https://cdn.aerynos.dev/unstable/x86_64/stone.index [5]
 - volatile = https://build.aerynos.dev/volatile/x86_64/stone.index [10]
 - local = file:///home/ermo/.cache/local_repo/x86_64/stone.index [100]

Boulder: Fix up phase timing in end-of-build report

When Boulder successfully completes a package build, it emits a report detailing how long each phase of the build process took.

ermo noticed that the output was wrong when the time exceeded an hour. For example 136m would be formatted as a rather silly-looking 1h76m instead of 2h16m. He fixed this in the following commit.

Boulder: Improve cache hit rates when updating packages

Boulder is designed to cache files and hash them as part of its build process. By hashing files, it uniquely identifies each file and stores this for later utilization. When a package is updated from one version to the next, where the package has files that have not changed, we have the opportunity to reuse the cache from a prior build (as long as the cache has not been purged for space saving).

Given the way boulder previously cached files, in named directories based on the package source names, there was a high likelihood that new caches would have to be built because the source file names contain version numbers, which by design will always change.

Reilly implemented a change to boulder so that our ccache entries will persist over version number updates improving the hit rate and therefore performance on boulder package builds.

Boulder: Tweak how we use sh-compatible shells

For user-facing recipes, our recipe snippets are now always interpreted by bash.

However, testing with hyperfine has previously shown that dash is ~20% faster to start up during ./configure runs when compared to bash.

To reap the benefits of faster dash process startup times, ermo and Reilly implemented a change to our GNU autotools macros to use dash as the default shell.

Having said that, there are certain packages that just expect and/or are hardcoded to require bash. So to cater to that use case, we have also added autotools macros that packagers can use to make Boulder execute GNU autotools with bash on a per-package basis.

This gives our tooling the “dash as /bin/sh” ./configure speed improvements by default, yet allows packagers to still successfully invoke ./configure et al. with bash, where doing so is necessary for the build to complete.

Boulder: Update build macros

On reviewing Boulder’s build macros, we found some low hanging fruit improvements to make to our cmake, ninja, and meson macros, which we landed back in April. Implementing and improving the various build macros available in AerynOS makes it easier and more convenient for packagers to package up applications with Boulder; either for their own personal use or for submission into the official repositories.

Boulder: Use bsdtar-static for unpacking

At Reilly’s initiative, we moved our decompression solution away from GNU tar to bsdtar-static. This change reduces the likelihood of compatibility issues and ensures Boulder package creation doesn’t rely on a dynamically linked system library, thus making it more of a reliable solution.

With this move, we have also added the ability to decompress tgz based source packages as part of the boulder build process.

Other notable work

Some of the work we have done has been aimed more at how we use our os-tools rather than the os-tools themselves.

Update build triple and fix up ARM AArch targets

With our recent transition from SerpentOS to AerynOS, we needed to update our build triple accordingly. This step has been completed in the background whilst allowing for seamless updates from older SerpentOS systems onto AerynOS based systems. This is part of a wider rebranding effort that is still on-going through our documentation site, repo READMEs and anywhere else we have an official presence.

In this same area, whilst AerynOS currently only supports x86_64 based devices, there is a desire to be able to target other system types longer term. One of our contributors has been experimenting with RISC-V so we have added preliminary support for this to aid their testing. Don’t expect to see AerynOS on RISC-V any time soon, but it’s great to see our distro becoming a sandbox for fun and experimenting on alternative systems.

Emul32 ELF Machine type migration

During the port of boulder from DLang over to Rust, there was a change in how we expressed the ISA for packages built for the x86 emul32 architecture target. The old DLang version of Boulder expressed it as x86 where the Rust elf crate expresses it as 386 (EM_386 for those of you familiar with ELF parsing internals).

Reilly took point in implementing a series of changes that retained full compatibility between packages originally built on the old DLang infrastructure, and newer packages built on the Rust infrastructure.

The end goal was to flush out the packages containing references to the x86 Emul32 ISA through the recent rebuild of our whole recipes repository. This was accomplished by first ensuring that all packages exposed both x86 and 386 provider patterns, and then subsequently dropping the code that wrote the x86 provider patterns during the second full repo rebuild, ensuring that packages only contained the 386 provider patterns.

In the end, this worked out nicely for us.

Current and near-future os-tools focus

We reviewed the open issues in our various GitHub repositories and the plethora of ideas we have for our tooling, and developed a high level set of milestones for our os-tools. For this milestone (os-tools alpha2), we want to focus on:

Adding structured logging for better insight and reporting
Improving error handling
Ensuring we deliver more helpful message output
Adding JSON output for the above, for nicer parsing of structured output across process barriers
Adding low hanging fruit features and fixing misfeatures as we review the code

As our readers may have surmised, we have slowly accumulated bits of technical debt here and there over the course of development. The os-tools alpha2 milestone is our chance to address that and make our code crisp, clean and ready for already-planned future development work, while we stabilize our new infra code in parallel to this effort.

A special thank you goes to Jonas for the work he has already done in terms of this sort of refactor work.

How to join in the fun

As already covered in this blog, we have been reviewing all open issues and PRs in our os-tools repository on GitHub for prioritization and to set internal milestones.

We are open to and actively looking for contributors who might be interested in looking through our code and providing feedback.

If you would like to try your hand at contributing, look out for issues marked “good first issue” and get in touch on Matrix.

We hope to see you there!

Mid Year Update

Jun 30, 2025

NomadicCore

Comms

Ermo

Co-founder

As we hit the middle of the year, it’s time for another update for those of you following along with AerynOS’s development.

Over the last few months, things may have seemed unusually quiet, however rest assured that there has been A LOT going on in the background. As such, we are preparing a short series of blog posts to go over the relevant topics in the coming weeks.

For this blog post, we are going to cover our infrastructure port, along with the process of rebuilding our entire package repository.

The TL;DR is that:

All core AerynOS tooling is now written in Rust
Every recipe in the repository has been rebuilt (twice!) with many packages then having been updated to newer versions after the rebuilds were completed
A CDN has been implemented for faster package installation and ISO downloads

New infrastructure tooling

When delivering a Linux distribution, its infrastructure and associated processes effectively act as the “spine” of the project. But spine surgery can be a delicate affair, particularly when it comes to rehabilitation after successful surgery.

For us, this cycle has been particularly demanding, as we have completed an MVP (Minimum Viable Product) port of our infrastructure tooling code to Rust, meaning that all core AerynOS tooling has now fully transitioned away from DLang.

We have covered the reasons for this transition previously, and it’s fair to say that we are already feeling the benefits of easy and native reuse of code in our tooling repositories and welcoming more Rust contributors into our community.

Why now?

Earlier this year, our existing DLang build infrastructure started showing signs of instability and required more and more manual intervention to successfully land packages.

Given our prior decision to transition our tooling over to Rust, we had already stopped further development of the DLang based infrastructure. Hence, we decided to accelerate our transition timeline for the infrastructure re-write to Rust with tarkah and ermo leading the development activity, which began at the end of March.

Towards the end of May, we put the first infrastructure prototype to the test, and then iteratively fixed bugs and built out missing functionality to the point of being able to put our MVP into production on our build infrastructure.

This MVP will serve as the development base of the code that will be used for all future package builds.

What do we mean by infra?

Our infra is comprised of the Summit, Avalanche and Vessel service components:

Summit: Package build-controller, build-orchestrator and build-dashboard, monitors recipes tree and automatically builds new, incoming recipes once they show up
Avalanche: Build agent middleware, takes build orders from Summit and builds them with Boulder on a remote system, sends build logs back in real time to Summit, and reports the build result to summit at the end of the build.
Vessel: Package repository manager. Summit tells Vessel which packages and other build artefacts to expect from a build task that Avalanche has completed, and then Avalanche pushes those packages and build artefacts to Vessel, which then saves them in the appropriate place and re-indexes the repository with the new packages, so users can install/update them.

We have some cool features planned in AerynOS that we envision will make package maintenance a lot easier to manage through smart use of automation.

Until these features are implemented, however, maintaining the AerynOS repository will remain somewhat human resource intensive. This is the main reason why the repository is consciously being kept “small” for now, with us deliberately focusing on having packages that will help developers and contributors improve AerynOS, while still delivering a nice Daily Driver experience.

Until the new features are implemented, this will necessarily be a balancing act between maintaining the package repository so it doesn’t go stale vs. having the development time to implement the new features.

How did you test it?

Aside from porting the infrastructure code to Rust, proper testing was required to yield confidence that packages were both successfully built on the new infrastructure and that they worked as expected.

The end goal was to prove that we were able to rebuild the full AerynOS recipes repository (currently at ~950 recipes) from start to finish without infra-related build errors on the new infra.

To enable the rebuild, ermo set up a distributed build cluster of four builders of varying hardware specifications. A separate branch of the ‘recipes’ repository was created, and was used to test both the Rust infrastructure and to land packages for internal testing without them being seeded to user installs.

In addition, compared to the old infra, we made it simpler to add new avalanche build agents to the build cluster, thus making it very simple to scale out our build cluster as required.

To summarise the infrastructure Rust re-write and testing effort, we have:

Completed more than 3k recipe builds
Deployed the new Rust infrastructure on the AerynOS builders and continue to use it on ermo’s build cluster
Validated that the new infrastructure code is more stable and performant at runtime than the previous DLang version

How did testing add value?

The full rebuild of the recipes repository has also served to ensure ABI sanity for dependencies. Additionally, we can now say that at this point in time, the whole AerynOS repository is known to be buildable and works with all the latest toolchains.

A special thanks goes to Reilly Brogan, who worked diligently with ermo to not only drive the rebuild process, but also to ensure that some longstanding repository issues were corrected as part of the rebuild process.

During this process, we have delivered updates to our os-tools (Boulder and Moss), toolchains and build systems. A selection of the updates and additions include (but is certainly not limited to):

Linux 6.14.11 (6.15.x on the way)
LLVM 20.1.7
GCC 15.1.1
Rust 1.88.0
Golang 1.24.4
Mesa 25.1.4
GNOME 48.2
COSMIC 1.0.0_alpha7
Sway 1.11
Firefox 140.0.1
Thunderbird v139.0.2
Uutils-coreutils 0.1.0
Nodejs 22.14.0
Wine 10.8
Distrobox added at v1.8.1.2
Exfatprogs added at v1.2.9
Fzf added at v0.62.0
Kitty added at v0.41.1
Waybar added at v0.12.0

A New Package Repository

As mentioned earlier, the testing work was conducted on a separate branch of the recipes repository. Consequently, those of you on the old packages.aerynos.com/volatile/ repository, have not received any updates over the last 10-12 weeks.

This was a conscious decision to ensure that the mostly untested packages built during the infrastructure testing process did not reach end users immediately. Even though AerynOS is in Alpha and under continuous development, we still do our best not to break user systems if we can avoid it!

Now that we have a level of testing in place, with this blog post, we are announcing a new rolling unstable package repository for users. The old volatile package repository has received one final update to Moss that fixes an important bug when transitioning to the new unstable repository.

To ease the transition to the new repository for existing users, we are working on a script that can automatically modify the active repository on the system.

Once this script has been sufficiently productized, the next time existing users update their systems, they will notice that every single package will show an update available.

The exact number will vary from system to system depending on how many other packages are installed from the repository but for context, on a base AerynOS GNOME install, this is around 500 packages.

In the meantime, we have created a manual guide on how to transition existing installs to the new repository in our GitHub Discussions forum here. The process is fairly simple, but if you do have any issues transitioning manually, do get in touch via a comment under the GitHub Discussions post or via Matrix.

Content Delivery Network for Packages and ISOs

A common bit of feedback we have been receiving relates to the download speed of our repository, namely that it is not fast or even acceptable, especially if you live outside of Europe. This became more evident for those using the rebuild repository on ermo’s rebuild testing server, which felt noticeably faster for people in Europe in particular.

To remedy this, we have implemented CDN caching for our new cdn.aerynos.dev hosted assets. This means there will be synced copies of our ISOs and package repository on CDN servers around the world, which should help improve download speeds.

In particular, the new rolling unstable package repository mentioned above will be served via this CDN for the benefit of our users.

Please let us know how you get on with AerynOS ISO and package downloads in the coming weeks, as we would love to validate the improvement outside of our own internal testing.

Future infrastructure development targets

So far, we have only outlined what we have already accomplished since late March.

The next part of this blog post is going to be a brief outline of where we are going from here in terms of infrastructure and repository development.

Versioned Repositories

With the transition to the new infrastructure and the new unstable repository, we have been freed up to begin planning out the necessary steps to be able to deliver versioned repositories and versioned Moss format upgrades.

These topics have been mentioned in a previous blog post.

How do versioned repositories add value?

Versioned Repositories will enable us to deploy new Boulder and Moss features in a seamless fashion. This will enable us to introduce breaking code and on-disk format changes, that would otherwise cause installed systems to require manual intervention for them to continue to receive updates.

Once versioned repositories are in place, the goal is that users will be able to simply update and sync their system as normal via the sudo moss sync -u command.

With this:

Users will be upgraded to the new versions of Moss that uses a new repository format, without having to pay special attention.
It will enable AerynOS to iteratively expand the capability of Moss and Boulder on existing systems without breaking user systems in the process.

Additional Opportunities

We consider versioned repositories a pre-requisite for what we call “try-builds” and eventually multi-arch support.

Automated try-builds denotes the process whereby the infrastructure discovers an update to the upstream source repository of a package, attempts to auto-update the recipe and then attempts to build the updated package recipe in question.
We think this will be a useful tool for contributors as it will automate some of the packaging tedium related to simple package version updates. It will also help enable automated regression testing and build flag optimisation in a future workstream.
Included under the multi-arch umbrella is our ability to target ARM, RISC-V, and different x86 architecture levels such as x86-64-v3 or v4.

Project Status

Infra

Within the previous 3 month period, we have rebuilt a brand new Rust version of the infrastructure tooling that is robust enough to run in production on AerynOS servers, delivering packages to our contributors and users. This new version has proven to be more stable and performant than the old DLang version we were previously using.

Packaging

From a day to day perspective, unlocking the infrastructure means that we can get back to reviewing and landing recipe PRs for our package maintainers or accepting new contributors into our AerynOS ecosystem. For those wishing to contribute to AerynOS, please make sure that you have manually switched over to our new repositories before making submissions to ensure you are using all the latest tooling.

Alternatively, you can wait until the automatic transition script is functional and have it make the change for you.

Where to get in touch with us

If you want to engage with the team, feel free to drop by our GitHub Discussions, raise issues across our various repositories or if you’re interested in contributing, feel free to raise PRs where you think our code can be improved or where you want to submit recipes for our repo.

We also have our matrix space that you can access via this link:

The Development room in particular is a great place for discussions around our code.
The General room is a great place to drop by and get to know the team.
The Packaging room is where you want to be if you’re interested in building packages for yourself and/or submitting them to the repository.

What’s next?

Concurrently to our work around the infrastructure re-write and repository rebuild, there has been several additional workstreams running in the background.

The team has been refactoring our existing Rust code, mainly focused on our os-tools (Moss and Boulder) and we are working on several additional improvements that we want to get over the finish line before our next ISO release.

We will be sharing details of this work in upcoming blog posts over the next few weeks.

End Of Year Summary

Dec 19, 2023

Ikey

Founder

Ermo

Co-founder

Burning question - how long before we can use Serpent OS on our development systems? It’s a fair question - and one that requires context to answer. Let’s start our new monthly update cycle with a recap of progress so far.

screenshot of moss

Introducing tarkah

We’d like to extend a huge official welcome, and thank you, to newest team member Cory Forsstrom (aka tarkah)!

Firstly, a quote from Cory:

I’ve been a long time Solus user and was very excited about what serpent os was doing. Really got invested once I started diving into the D code and seeing how powerful the tools and ideas were. The Rust rewrite was just a perfect storm for me with my experience there and my desire to make contributions. Getting to know you and ermo has just been icing on the cake, you’ve both been so welcoming and friendly. So lots of fun times.

On the personal side, I’m on the west coast in the States, have a lovely wife, just had a baby girl and am enjoying my time with fatherhood and coding

Chances are you know tarkah for his contributions to iced-rs, and to Solus. His contributions to the moss-rs project have been absolutely critical, and his patience essential as we got ourselves quickly up to speed with Rust. It is entirely fair to say that our Rust efforts would not have been possible without him!

Rust Progress

I think it is fair to say that people collectively facepalmed when we announced our plans to adopt Rust - assuming this would be a huge set back. We’re really happy to report this is not the case, and we’ve made tremendous progress in this area.

moss

Our Rust based moss system package tool is now leaps and bounds ahead of its predecessor, supporting the original features and more!

State management
Garbage collection of old transactions (via state prune)
Optimised write order of transactions (see more below)
File conflict detection
Parallel fetching and decompression of packages
Update support (as sync)
Local and remote repositories with priority-based layering
Support for building with musl for fully self-contained, static builds of moss with zero system dependencies.

We now have a version-agnostic “stone” crate that is more efficient at reading packages than our original D code. In addition, it benefits from the memory safety promises of Rust.

Virtual filesystem management

OK, lets look at the problem: Every transaction in moss requires us to generate a new staging tree containing all of the directories and files for the /usr tree, using hard links, from content addressable storage. As one might expect, creating tens of thousands of new nodes is really, really slow!

To alleviate this issue we created a vfs crate in moss to optimise how we construct each transaction tree:

Organise all incoming registered paths into a specific order
Inject all missing implicitly created directories for accounting
Re-parent nodes in tree which live under redirected symlinks
Compile into a recursive data-structure using relative names.

There is a multipart “build” for the tree that detects any filesystem conflicts before any files have been written to disk, preventing broken transactions. With the fully built data structure we can recurse a virtual filesystem, making use of the at family of functions like linkat, mkdirat, to “blit” a filesystem tree without requiring any path resolution, in the most efficient order possible.

The net result? New transaction roots are created in milliseconds, not seconds.

Upgrade support - kind of

moss now offers a sync command in place of the conventional upgrade one might expect. Rather than upgrading to the latest version of a package, we rely on moss and our infrastructure tooling work in conjunction to ensure we can simply synchronize the package selection with the the “tip” candidates in the configured repositories, as ordered by priority. From a distro-builder PoV, we can now revert and pull builds. For a user PoV, you can remove a test repository and moss sync to go back to the official versions of packages.

Generally speaking, when you moss sync you will be seeing new packages, however. :smile: This feature is being built to enable a future feature: exported states. Want to try a new edition? Sync to the lockfile. Need to quickly and reproducibly deploy containers from a locked down configuration? You get the idea.

moss sync

Fully `async`

The moss tool is now completely asynchronous, making efficient use of both coroutines and OS threads to perform as much work possible in the shortest space of time. This allows us to download, fetch, check and unpack many packages at the same time without being blocked on network or disk, greatly speeding up the fetch part of a transaction.

This is achieved by building on the famous tokio runtime and :material-github: reqwest crates, among others.

boulder

At the time of writing our port of boulder hasn’t quite yet caught up with the original implementation, given all of the ground we covered with moss. With that said, we decided to step back and evaluate where we could improve upon the first version of boulder.

boulder in action

User namespaces (rootless)

Arguably one of the most important changes: boulder no longer requires running as root. Even better, we make use of user namespaces and execute using clone - meaning we no longer need a separate binary (mason) within the container environment!

Superior error handling

Thanks to everything being a self-contained binary, we can tell you up front that you’re using unknown action or definition macros (i.e. %(datadir)) before attempting any builds, saving you valuable time.

Breakpoints

When this was first proposed, I did a double take. Breakpoints.. in recipes… ? No, seriously. Not only was it proposed, but between ermo and tarkah, they only went and implemented it. You can now use special macros within your recipe to add debugging breakpoints in your recipe to drop to a shell within the container and debug the more difficult builds!

Our documentation will be updated when the new boulder ships a stable build.

Unified codebase

We now build both moss and boulder from the moss-rs repository, allowing them to share the same code and mechanisms for dealing with dependencies, system roots, etc., allowing for far higher levels of integration than were previously possible.

A feature we’re currently working on allows you to use a single directory for the system “root”, where all the unpacking, fetching and databases happen, while almost instantly creating new build roots!

What We Already Have

I get it. “All this rewriting - how will you ever make progress” ? It’s a fair question. We didn’t throw anything away, quite the opposite. Our repos, tooling, are all still in use enabling us to build the distribution in parallel to the ongoing rewrites.

Build infrastructure

For a long time, we’ve had our :material-view-dashboard: dashboard up and running for our build infrastructure. Sure, we’re going to rewrite it beyond the “Proof of concept” stage when required - but for now it still serves us well. Admittedly there is a deep issue within the druntime causing thread leaks over time, but we have it restarting via systemd every 24 hours as a bandaid. Needless to say, we’re big fans of memory safety now.

Our current deployment watches git repos in our :material-github: snekpit collection, and automatically forms build queues from the pending builds, ordering them by dependency. Using two of ermo’s beefy builders, the packages are automatically built and deployed to our repository. Our workflow means that maintainers only have to merge a pull request for builds to appear in the volatile repository.

Legacy tooling

Despite having some warts, the build infrastructure is still able to use legacy moss and boulder to make our new builds available, and we’ve been minimally patching these old tools to support our transition to the Rust based tooling. As of this moment, moss-rs officially supersedes the D version, and our new boulder is quickly catching up.

Long story short, we’re still building on all fronts and aren’t blocked anywhere.

Live repository

Builds are published to our volatile repository, and we do have a fully functioning software repository despite being quite small. Once we’re happy with the new moss we’ll speed up in our packaging efforts. With that said, we do have two kernels (kvm and desktop) and even gtk-4 at this early stage!

The immediate future

OK let’s tldr this:

Rust ports are coming along fantastically
moss has been replaced
still making use of existing tools and infrastructure to build the OS
actually building the fully bootstrapped, self-contained OS, built on libc++, clang, glibc, etc.
actively pushing updates to binary repository with fully automated pipeline
new stuff is :rocket: blazing fast

System triggers

We’re experimenting with system triggers right now, execution units that run to fully bake the OS state after each transaction completes. In keeping with our stateless philosophy (and pending adoption of hermetic /usr), we need triggers that understand the union state of the operating system, not individual per-package triggers.

A YAML-based trigger recipe has been baked up, which deliberately avoids the use of shell helpers and execution security weaknesses by using an extended variant of globs:

    let pattern = "/usr/lib/modules/(version:*)/*".parse::<fnmatch::Pattern>()?;

Our new :material-github: fnmatch crate, heavily inspired by Python fnmatch, compiles specially format glob strings to Regex, extending with capture groups for named variables. In YAML, it looks a bit like this:

handlers:
    depmod:
        run: /sbin/depmod
        args: ["-a", "$(version)"]

## Link paths to handlers and filter on the type
paths:
    "/usr/lib/modules/(version:*)/kernel" :
        handlers:
            - depmod
        type: directory

Once we roll out the trigger support, we unblock the packaging of critical items like gtk-3 for gdm, as well as enable usable installations and ISOs. Note that they differ from classical triggers due to the architecture of moss: they need to run in an isolated namespace (container) so we can ensure the staged transaction won’t break. Additionally we cache and collect the trigger artefacts to speed up each filesystem operation, giving us a first: versioned state artefacts.

Boot management

Our plan is to build on my prior work in the Solus boot management design and :material-github: clr-boot-manager, addressing some long standing shortcomings. Most importantly, our new module will not need to inspect or manage the OS filesystem as moss will be able to provide all of the relevant information (full accounting for all used paths in all transactions).

Initially we will focus on UEFI and supporting the :material-github: Discoverable Partitions Specification by way of XBOOTLDR partitions, the ESP and the Boot Loader Interface. Currently we have no plans to support Unified Kernel Images as the approach taken by CBM (and soon, moss) alleviates the data concerns of dealing with vfat. However, as and when UKIs gain configurable, standardised behaviour for cmdline control we will investigate their use. Until that point please note we prebuild our initrd images and ship them directly in our packages, as Solus has done so for years already.

The net gain for taking control of boot management will be the deduplication and garbage collection of assets installed to either the ESP or XBOOTLDR partitions, along with generation of boot entries relevant to Serpent OS: Transaction specific entries allowing us to directly boot back to older installs in case upgrades go wrong.

Last, but certainly not least, this approach will make dual-booting with another OS less irritating by no longer being bound by a fixed ESP size.

Desktop

Our plan is to produce a GNOME Shell based live ISO containing the bare basics to get everything else validated, and open the path to installations. In short, it will include:

Desktop.
moss tooling
web browser (firefox)
terminal (potentially gnome-console)
flatpak
Eventually: GNOME Software (integrated with flatpak+moss)

It should be obvious we’re not building a general purpose home-use distribution. However, we also won’t stop people using Serpent OS for their needs, and we plan to beef up the repository, fully support flatpak and eventually custom moss source recipe repos. (ala AUR)

Safety is important

Our journey over the last few years through D, DIP1000, Rust and memory safety has been incredibly eye opening for us. To our own surprise, memory safety has become a huge interest and concern for the team. Not only have we embarked on a full transition of our tooling to Rust, we’ve started looking at the OS itself.

As an early indication of our intent, our curl package is now built with the rustls backend and not OpenSSL. Needless to say, we’re very keen to reduce the surface area for attacks by adopting alternative, safer implementations where possible. Other projects we’re keeping a very close eye on include:

Looking to next year

With most of us entering our holiday leave, and the new year practically around the corner, the Serpent OS team wishes you many happy returns and a wonderful new year. With one blocker being worked on (triggers), and the last on the horizon (boot management), your dream installation of Serpent OS is firmly within reach.

In the spirit of the season… if you feel like supporting our project, you can help with the rising cost of living and our expanding hosting requirements via GitHub Sponsors!

Sponsor us!

Ermo

How we view the project and our roles in creating it

NVIDIA driver issues for certain GPUs

Why have monthly ISOs anyway?!

We actually delivered quite a lot in the last couple of days!

oxidize Window Manager theming

ISO refresh

Next Steps

Supporting the project

Thank You!

What’s new in the distro

Infrastructure and Tooling Updates

boulder cache subcommands with clean and size options

boulder recipe automation

Faster moss state remove

Improved moss search

Continuation of our Versioned Repository feature set

Wider Project Updates

New Branding: A Fresh Look for AerynOS

New Wallpapers: Bringing Nature to Your Desktop

Python stack upgrade

Kernel updates

ISO refresh

Next Steps

Supporting the project

Thank You!

AerynOS: March 2026 project update

What’s new in the distro

Desktop Updates

GNOME

KDE Plasma

Wayland Compositor Environments

Infrastructure and Tooling Updates

Use CDN for the default volatile stream

moss: Search for binaries

moss: Enable removal of ranges of states

boulder: Add support for control files

Wider Project Updates

Recipe repository REUSE compliance

Framework hardware sponsorship

ISO refresh

Next Steps

Python upgrade and repository rebuild

Versioned Repositories, phase2

Supporting the project

Thank You!

AerynOS: February 2026 project update

What’s new in the distro

Desktop Updates

Cosmic

Gnome

KDE Plasma

Wayland Compositor Environments

Infrastructure and Tooling Updates

Boulder and recipe updates

Summit queue visualization

Boulder --verify flag for manifest checks

Moss blitting speeds

Trigger speeds

Wider Project Updates

Website redesign

Documentation

Donation methods

ISO refresh

Next Steps

Package addition soft-freeze

Invasive toolchain and full-repo rebuilds

General recipes repository housekeeping

Versioned Repos, phase2 work

Supporting the project

Thank You!

AerynOS: January 2026 project update

What’s new in the distro

Desktop Updates

Cosmic

Cosmic context

Gnome

KDE Plasma

New Wayland Compositor Environments

Why not use our system-model?

Faster `moss state remove`

Improved `moss search`

Boulder `--verify` flag for manifest checks

Parallelize the `moss state verify` command

moss `system-model` prototype feature