AerynOS | Blog

A post we never want to have to make!

Sun, 03 May 2026 23:00:00 GMT

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!

Thu, 30 Apr 2026 12:00:00 GMT

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

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

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`

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

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.

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

Tue, 31 Mar 2026 12:00:00 GMT

AerynOS: March 2026 project update

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

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 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

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

Sat, 28 Feb 2026 12:00:00 GMT

AerynOS: February 2026 project update

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

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

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 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

Fri, 30 Jan 2026 12:00:00 GMT

AerynOS: January 2026 project update

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

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

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

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 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?

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

Fri, 02 Jan 2026 23:00:00 GMT

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.

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

Tue, 09 Dec 2025 12:00:00 GMT

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

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

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

Musings on Inode Watchers and Atomic Live Upgrades

Tue, 04 Nov 2025 09:00:00 GMT

This blog post will focus on inode watcher applications as well as the difficulties they present for live atomic updates for our moss package manager.

What is Moss?

For those not in the know moss is an atomic package manager that allows for live updates i.e. not needing to reboot to apply updates.

Although moss presents itself as a traditional package manager, under the hood, it works quite fundamentally differently.

When you install a package with moss, it actually downloads and extracts the package to a Content Addressable Store (CAS) in /.moss/assets. It then constructs a new virtual filesystem in memory comparing the current installed state to the new desired installed state containing the additional package. From the CAS it then constructs a /usr tree in /.moss/root/staging containing the additional package using hardlinks into the CAS. Then, using the renameat2 Linux kernel syscall with the RENAME_EXCHANGE flag set, moss atomically promotes the current /.moss/root/staging tree to be the new /usr tree, and simultaneously demotes the current /usr tree back to being an inactive, numbered filesystem transaction (fstx) tree in /.moss/root/<fstx id>. Finally, moss then updates the bootloader configuration to reference the five newest numbered filesystem transactions for rollback purposes.

Compared to other atomic distributions on the market, the ability to live-update without needing to reboot is an important usability requirement for us, such that the user experience remains friendly to downstream users.

Enter Inode Watchers

Although quite a novel approach, allowing atomic updates of a live system leaves us with an interesting problem: After any moss transaction activating a new /usr tree, any running applications holding an underlying inode to a filesystem path will continue to watch the file in the now archived state.

For example:

$ inotifywait -m /usr/bin/le-foo &
# moss remove 'binary(le-foo)'

In this case, if you hold an inode to a path that is deleted after the the /usr tree is atomically swapped as part of a moss transaction, you will continue to hold the inode to the file in the archived state e.g. /.moss/root/<fstx id>/bin/le-foo. This is due to the fact that the underlying file in the CAS that was referenced from the previous /usr tree was not removed from the system; it still exists in the now archived previous /usr tree.

For any running applications whose functionality depends on these inode watchers, it can leave the system in a weird state as the application has no real way to know that the “real path” has now changed from /usr/<something> to /.moss/root/<fstx id>/<something>.

The most obvious example in which this presents to users is in our GNOME Edition. GNOME Shell uses a inode watcher on /usr/share/applications/ to watch for any changed .desktop files as applications get installed or removed. This design works pretty well for a traditional installation, and reduces the number of expensive stat calls required to see what applications are available to launch. However, notably this design does not work with the design of moss, in that when applications are freshly installed in GNOME they simply do not show up in the application launcher as GNOME Shell instead continues to hold the inode to the archived path. e.g. /.moss/root/<fstx id>/usr/share/applications/, once a mutating moss operation is performed.

Whilst we could patch GNOME Shell instead to stat for new changes in /usr/share/applications/, patching every application that has issues with picking up file-system changes is not feasible across the ecosystem.

Alternative Approaches?

One suggested alternative has been to explore so called “mount-tucking” and EROFS images.

Mount-tucking is a fairly new addition to the Linux kernel where you can mount a new image beneath a currently mounted image for a path.

For example

# mount my-image.img /mnt
# mount --beneath my-new-image.img /mnt
# umount /mnt

In this example, once /mnt is unmounted it will unmount my-image.img and leave my-new-image.img mounted in its place. If any files from my-image.img are currently open, then a lazy unmount of the /mnt path is required.

When combined with EROFS (extended read-only filesystem), we can construct a lightweight, metadata-only EROFS /usr tree image which then links into the underlying CAS to form the new /usr tree instead, then mount it beneath the currently running /usr tree lightweight EROFS image. Lastly, we can then lazy unmount the current running /usr image so the new image will apply in its place. As an additional benefit, this approach ensures that the /usr tree is also immutable whilst still remaining atomic.

However, this approach has now been explored, and the fundamental problem remains that any running applications holding an inode to a changed file will simply not see any change.

Are We Stuck with Needing To Reboot?

Possibly.

The Linux kernel does not offer any mechanism to forcibly “revoke” inodes. If it did we would potentially build up a list of changed files, find their inodes, and then “hint” that they have changed after the /usr trees are swapped. Any running applications that were then watching the inodes could pick up the changes.

For this particular problem, ideas are starting to run thin. Whilst it is important to us that live atomic updates remain possible instead of requiring the user to reboot, solving this problem currently has us scratching our heads.

TL;DR: More research needed.

October 2025 project update

Fri, 31 Oct 2025 09:00:00 GMT

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.

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

Wed, 01 Oct 2025 18:25:00 GMT

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

Sun, 31 Aug 2025 20:45:00 GMT

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

Fri, 11 Jul 2025 12:18:00 GMT

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

Mon, 30 Jun 2025 21:37:00 GMT

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.

🏗️ AerynOS: The OS As Infrastructure

Sun, 30 Mar 2025 02:35:00 GMT

Taking a break from our usual release-oriented updates, I thought it was high time to dive into what AerynOS actually is and what sets it apart from other distros. Fair warning, this is a meaty, in depth post, and still only scratches the surface. If you’re interested in the future of Linux distributions, read on. It may also help to visit our work-in-progress documentation site for more information.

🧱 The OS As Infrastructure

Firstly, AerynOS isn’t Yet Another Linux Distribution. It’s a platform, a foundation, and a set of tools engineered in accordance with a vision and design that just so happens to produce a Linux distribution. Were we to go back in time and build a design brief for AerynOS, the initial question might be:

What if the operating system itself behaved like modern infrastructure?

AerynOS is the answer to that question. What if, instead of doing things the way they’ve always been done, we started from the ground up and produced a well designed system, rather than the traditional model of in-place mutation internal to a distribution?

🏗️ The AerynOS Foundation

Leveraging years of experience across the industry, including some notable pioneering projects such as Solus, Clear Linux, and others, we set out to build things the hard way, in order to make them easy.. eventually.

🔧 Toolchain

At the very core, is the decision to not be another GNU/Linux distribution. We default to the LLVM toolchain, using libc++ and compiler-rt by default. This isn’t just a case of “we like LLVM”, but rather a strategic decision to leverage the superior diagnostics, and ensure correctness / portability of packages. Whilst in our very early stages a few years ago we did trial musl, we do default to glibc for compatibility reasons and its superior performance characteristics. The performance advantage of glibc over musl is well-documented, particularly for compute-intensive workloads and applications requiring optimal threading performance. We’re here to build a working, usable system, for a multitude of use cases and verticals, and glibc provides the best balance of compatibility and performance.

Note, we do still package gcc and it’s trivial to enforce its use in a package recipe by setting the toolchain field in stone.yaml to gnu.

Lastly, it’s worth noting we build all packages for x86_64-v2 as our minimum baseline, and perform targeted optimisation in our package recipes using the extensive tuning options configurable in boulder.

📄 Statelessness

Our packages are forbidden from containing any files outside of /usr. In order to enable this, packages and/or configurations are altered in AerynOS to ensure they can operate in the absence of a user provided configuration. This forces us to ensure sane-defaults are baked in at all levels, and eliminates dreaded 3-way merge conflicts on package updates. There are no conflicts, because everything in /etc and /var is yours. Likewise, /usr belongs exclusively to the system.

This approach was coined and developed during Clear Linux and Solus days, and we’re refining it further in AerynOS. Other projects have adopted similar approaches, termed “hermetic /usr”.

You might be wondering how files end up in /etc automatically. To this end, we support two forms of package triggers:

🔄 Transaction Triggers

These triggers are run at the end of a transaction in an ephemeral container (linux namespace) and may affect the contents of the transaction-specific /usr tree. This is useful for interdependent packages that need to dynamically produce plugin registries, for example.

🖥️ System Triggers

These triggers do not run in an isolated container, but instead are run in the context of the host system after the transaction has been successfully built and applied. It is these (minimally used) triggers that invoke systemd-tmpfiles, systemd-sysusers, etc. Even for these cases we take special care to ensure that our default configs are sane and that a rebuild is always possible.

👤 System Accounts

Another important aspect is the handling of local system accounts. Traditionally these are snippets/shell scripts that invoke useradd, groupadd, etc. In AerynOS we default to systemd userdb for any users/groups that do not explicitly need groups that users would join. Thus, using drop-ins in /usr/lib/userdb, most accounts are defined and made available via NSS. We use this already in gdm, polkit, colord, and many others.

For the other cases, we utilise systemd-sysusers using snippets in /usr/lib/sysusers.d to create the necessary system accounts. In time, when GNOME and other desktops (as well as shadow et al.) are more adapted to userdb and systemd-homed, we won’t need to rely so much on sysusers. The goal of course is elimination of /etc/passwd and /etc/group entirely, facilitating quicker recovery, provisioning, etc. For now some packages will ship sysusers-based groups, ie docker group, etc.

⚛️ Atomic Updates

Every moss transaction is atomic. Very high level: we produce a new usr tree (rootfs essentially due to mandated usr-merge) very quickly using hardlinks from a deduplicated cache. Once successfully built and primed, we atomically swap the new tree into place. Effectively, the staged transaction is swapped with the real /usr using renameat2 with RENAME_EXCHANGE. It either works or it doesn’t. Nothing in between.

🥾 Boot Management

Leaning heavily on our blsforme and disks-rs projects, we’ve taken a very different approach to boot management. As part of applying a transaction, we produce a Boot Loader Specification (BLS) entry for the new transaction. The tooling will discover the EFI System Partition (ESP), and mount it if necessary. It then synchronises the bootloader itself (systemd-boot), the relevant BLS entries, and the kernel/initramfs. Additionally it will automatically garbage collect older entries, currently retaining 5 of the last transactions.

It’s not just a case of copy/paste and hope for the best. We dynamically produce the root parameters for the kernel command line by directly reading the superblocks (natively, in Rust) of the devices all the way up the chain for the root filesystem. It means there’s no configuration file anywhere in AerynOS containing your root= parameter, and we’re even able to read LUKS2 encrypted devices to add the rd.luks.uuid parameter.

If that wasn’t cool enough, we also encode the moss transaction ID into the kernel command line. This is picked up during early boot in our initramfs, before /sysroot is pivoted to. Long story short it means that every kernel is correctly synchronised with the right rootfs, and that rollback is cheap, easy, and accessible directly from the boot menu.

In addition, we also automatically support XBOOTLDR partitions. In the absence of LoaderDevicePartUUID EFI variable, we’ll scan the GPT table itself relative to the rootfs to find the ESP, and we’ll always scan GPT relative to ESP to find the XBOOTLDR partition.

Long story short? No /etc/default/grub. In fact, if you wipe your ESP, moss can rebuild it from scratch.

📦 The Stone Format

At the heart of moss lies our .stone format. At a basic level, it’s our binary package format. Using a version-agnostic header, we’ve ensured that we design for the future. We also version every payload within the stone, allowing us to refine and evolve the format over time. Currently we support 4 payloads in a single stone:

📄 Content payload: A sequential blob of deduplicated data
🔍 Index payload: Contains offsets for the content payload, keyed by the XXH128 hash of the content
🗂️ Layout payload: Describes the intended filesystem layout when the stone is applied
📋 Metadata payload: Sequence of strongly typed, tagged metadata entries such as name, providers, etc.

Right now we default to XXH128 for hashing, but Blake3 is on the horizon (and used in blsforme). We compress all payloads using Zstd, offering great decompression performance whilst still providing a decent compression ratio.

The process for “installing” a .stone is quite different to other systems.

📥 The stone is fetched according to the repository data
🧠 Index payload is unpacked in memory
🗜️ Content payload is decompressed in a single run to a temporary location
🔗 Using the index payload, the content payload is spliced into the content addressable storage (CAS)
📂 The layout payload is loaded and merged into the LayoutDB, keyed by the unique package ID (SHA256 for the entire .stone, per the repo)
📊 Using the same key, the metadata payload is loaded into the “InstallDB”.

Notice that at no point are we actually “installing” anything. We cache into the CAS, and store metadata and layout details. This is used when producing a transaction. Also note there are various safe guards, integrity checks and such in place. For example every payload contains a “CRC” in the payload header, verified on read. We actually use XXH64 for this.

🔁 What is a transaction?

In AerynOS, a transaction is an entirely self-contained rootfs produced by moss. Right now we have to emulate imperative package management, by producing a new dependency graph seeded from the previous system state as recorded in the StateDB. Alterations are made and validated, and then the new DAG selects the packages to be included in the transaction.

At a high level, the transaction is produced by:

📊 Producing a valid dependency graph, seeded from the previous system state
🧮 Determine cache availability for each package
📥 Fetch and cache every missing .stone to produce the transaction
📂 Load all layouts for the stones by ID
🌐 Using our multi-layered vfs approach, we build an arena graph of the target filesystem, detecting conflicts ahead of time, whilst also precomputing reparented nodes (i.e symlink redirection) and produce an optimal iteration order for transaction application
🚶 Walking the vfs iterator to produce the new rootfs in a staging location, using linkat, mkdirat, etc, to optimally produce the new filesystem, linked from the deduplicated cache
📦 Binding an ephemeral container to the new rootfs, and running transaction triggers
💾 Recording the transaction in the StateDB.

As mentioned above, once a successful transaction is produced, it is atomically swapped into place. If the transaction fails, no ill effects are observed on the system, and your work day continues as normal. In the event of a successful transaction, the system is updated and ready to go, along with system trigger execution and boot management updates.

🔮 The Future

All of this is just the start. It’s taken a few years, and perhaps now it’s clear why. We’ve not even covered our package build tool, boulder, or indeed our build infrastructure! With that said, lets skip forward a short while and see what’s coming down the pipe.

🌍 Beyond the distro model

To reiterate, we emulate imperative package management. And to be honest, it’s totally pointless. It actually introduces more bugs than it solves. Given that we produce a new rootfs for every transaction, we could just as easily produce an entirely new graph each time too.

That’s exactly what we’re planning to do. In a similar vein to Gentoo or Nix, the intent is a global file to explicitly state the desired state of the system, whilst the tooling will simply fulfil it based on the moss plugin cascade. Whilst we have no intention of conflating state and configuration, we will in time extend this system model to support variants of packages in order to provide a kind of “slots” system, and to implement a richer, saner alternative to the infamous update-alternatives.

Obvious candidates include mutually exclusive packages like coreutils and uutils-coreutils (a gnu variant weight, perhaps?) or coinstallables such as clang, ensuring a default vendor version whilst allowing overrides at the local install or indeed package recipe level.

🔒 Immutability

Often AerynOS is described as an immutable OS, and that’s not strictly true. Granted, every transaction results in a new /usr tree, so local changes won’t persist and recovery is immediately available. However, we’re not immutable in the sense of read-only.

Having produced a composition-first, developer&user friendly atomic update implementation, we want to take this further in order to also support immutability without compromise: no unnecessary reboots. To do so we’ll implement something similar to composefs, without the drawbacks. Using the same transaction driven approach we have now, we’ll simply produce an erofs metadata image dynamically instead of the exploded filesystem tree. Utilising trusted.overlay.redirect xattr, and an overlayfs mount, we’ll expose our own CAS through the layouts in erofs, and also support fsverity hashes. Icing on the cake? We’ll leverage mount stacks to retain our composition-first, no unnecessary reboot ethos.

📚 Versioned repositories

We’ve touched on this a few times in our blog posts. Essentially the binary repository will be produced as a result of available build artefacts correlating to the state of our git repo manifest files (boulder proofs of build). The main repository index will link releases to moss/stone format versions, such that moss would only update to the latest release that it supports. This allows us to stagger breaking changes in a way that nothing breaks at all.

📊 Current Status

🚀 Actively shipping GNOME ISOs
🎮 Quite usable for gaming with NVIDIA drivers, Steam, Flatpak, etc
👥 Real users are already praising stability and innovation
🛠️ Focused heavily on disks-rs and lichen-installer to leverage disk strategy files (automatic provisioning described in KDL)

🎉 Conclusion

This isn’t just another distro. It’s us redefining distributing Linux. We’ve achieved a tremendous amount, having successfully integrated all of the above into a cohesive, singular whole. The amusing part of course being that the resulting system is “boring” - it just works.

Now, we are alpha. We’re not done, we’re not without issues. That said, we’re building the future and with your support, we’ll get there even faster. This post has only scratched the surface of AerynOS, but if you like what we’re doing, please do get involved or support us.

Or see other ways in which you can support the project financially.

🚀 Hello AerynOS

Tue, 25 Mar 2025 15:35:21 GMT

Hello from AerynOS! ✨ As you recall from February, we set about rebranding Serpent OS into what you now see, AerynOS. It’s not been without challenges, and where possible we’ve ensured continuity. Additionally we silently dropped a few ISOs, and can now take our first formal steps under our new identity. TLDR: the transition has been entirely fluid and you only need to keep updating, no manual intervention is necessary! 🎉

Progress has been steady but quiet lately, as due to unfortunate circumstances I’ve been working in bursts from my wifes hospital bedside.

💿 But first, an ISO drop!

OK, lets get right to it. We’ve released AerynOS 2025.03, with the following shinies:

🖥️ GNOME 48.0
🐧 Linux 6.13.8
🦊 Firefox 136.0.2
🎮 Mesa 25.0.2
🚀 Vulkan SDK 1.4.309.0
🛠️ LLVM 19.1.7

We’ve also decoupled the internal tooling version from the ISO versions to make them a little bit more.. well.. readable, for humans.

Grab it now from the download page.

💰 Funding

I want to thank everyone for their support of the project since we got more transparent around goals. It’s been a huge help and has facilitated massive progress on the project! 🙏 AerynOS no longer feels like a hacked together PoC, but a very solid daily runner. Yes, it’s certainly alpha, and the installer leaves a lot to be desired. For daily use and updates? It’s really quite something.

Please note that I never realised the Ko-fi goals don’t automatically reset, so the currently listed goal has been running for way more than a month.. xD However, over a period of time, we did manage to achieve it! 🎉 I’ll be resetting it shortly on a fixed date for each month ahead.

🔄 Rebranding, the sane way.

Rebranding can be more challenging than one expects. The easy stuff is out of the way, HTTP redirects and DNS trickery to ensure old URLs continue to work without manual intervention. In the case of the repos, we’ve updated the scheme:

🧪 Unstable presync repos

packages.serpentos.com -> packages.aerynos.dev

🌟 Post-sync user-facing repos

dev.serpentos.com -> packages.aerynos.com

📚 Documentation site

docs.serpentos.com -> aerynos.dev

Note the former scheme made no sense at all whereas now we take advantage of the dotdev for unstable work. A future release of moss will automatically handle the transition on installs for the sake of consistency.

📊 Introducing `os-info`

Previously we had moss generate the /usr/lib/os-release file on demand using compiled in defaults, which was somewhat inflexible. Now, we ship a JSON file (/usr/lib/os-info.json) containing a description of the OS, the composition of technologies, and the capabilities. While os-release and lsb_release exist, they provide very primitive identification and metadata. os-info is designed to provide compatibility with those formats while being far more expressive. Importantly, it also contains a mechanism for identifying the former identities of an operating system:

...
"former_identities": [
  {
    "id": "serpentos",
    "name": "Serpent OS",
    "start_date": "2020-06-15T00:00:00Z",
    "end_date": "2025-03-17T00:00:00Z",
    "end_version": "0.24.6",
    "announcement": "https://aerynos.com/blog/2025/02/14/evolve-this-os/"
  }
]
...

moss now utilises os-info to generate the os-release file, as well as to provide identification and history for our blsforme crate to manage each entry on the boot partition. This has allowed us to sync the branding on a per transaction basis, while still “owning” the legacy branded transactions on the ESP too (i.e /EFI/serpentos) and ensure they are correctly garbage collected. Interestingly this means that for a short period of time the boot menu will still show some of the older Serpent OS entries, allowing you to roll back to it.

Please visit the os-info repository for more details, the schema, etc. We’re very keen to open collaboration and adoption of this project, envisaging use cases in installers, welcome apps, and indeed even container introspection tooling.

🔧 Installer progress

We’ve officially begun the revamp of lichen-installer using a proper split between the privileged backend and frontend. In order to permit a number of frontends and use cases in future, we’re using tonic gRPC messages to communicate, currently just on a UNIX domain socket. In future, we’ll have use cases for TCP using WASM frontend.

More importantly than that, we’ve now implemented the foundational aspects for disks-rs. Long story short - we’re using provisioning strategies defined in custom .kdl files that are dynamically tested/validated against an input storage pool to produce a working set of changes. Such as, create a new partition table and add some partitions to it, using some constraints logic.

It is early days, but its quite awesome that we’re able to automatically partition disks based on these strategy files! ✨ These will form the backbone of lichen, allowing us to offer rich automatic storage strategies as well as manual partitioning options. Notable is the ability to set the volid or uuid of a specific filesystem, and partuuid, etc. This in essence allows shallow reproduction of an installation/disk topology using a configuration file.

🙏 Acknowledgments

This transition wouldn’t have been possible without our amazing community. Both long-time contributors and newcomers have stepped up to the plate to make AerynOS a reality, pushing us across the finish line during this critical transition.

Special thanks to Cameron for his instrumental work in porting our websites to a more maintainable, Astro-based infrastructure. This migration has not only improved our development workflow but also enhanced the user experience across all our web properties.

Whether you’ve contributed code, reported bugs, tested releases, spread the word, or supported us financially - thank you. AerynOS is truly a community effort, and we’re excited to continue this journey together.

As always, you can join our community on Matrix or contribute on GitHub.

🔄 Migration Guide

For existing Serpent OS users, migrating to AerynOS is straightforward:

Simply run the following command in your terminal:
```
sudo moss sync -u
```
Some branding changes may require a second moss operation to fully “take” effect (as they’ll be using the new moss binary). After the initial sync, run one of these commands to complete the transition:
```
sudo moss sync
# or
sudo moss install some-package
```

That’s it! Your system will seamlessly transition to AerynOS while maintaining all your existing configurations and installed packages.

🔮 Next up

We’ll continue on the path we set at the start of the year. By and large we’ll improve the core tooling to continue delivering a better experience for users, developers, gamers, etc.

By the way, we do have nvidia-open-gpu-kernel-modules / nvidia-graphics-driver for the linux-desktop users wanting to game on their shiny AerynOS installs. Our Steam package works great, and any feedback is appreciated on improving it (ie udev/controller stuff, 6.14 kernel is planned).

Shifting more towards the installer images, using Slint for the installer frontend, and dropping unnecessary packages from the installer image. Live ISOs will of course be available, but our primary target is installer images.
Integration of upstreams-rs and ABI tracking into the tooling in order to vastly lighten the load for maintainers.
Accelerated delivery of milestone ISOs.

Evolve This OS

Fri, 14 Feb 2025 23:25:37 GMT

A long overdue, and highly requested update today. We’re finally rebranding the project!

🤔 Why the change?

The “Serpent OS” name was a quickly chosen name that stuck. Unfortunately “serpents” are often associated with negative connotations, and we’ve had a lot of feedback over the years that the name was off-putting. Let’s be completely honest, it’s not the most inviting name for a project. Who wants to trust a serpent? Generally speaking they’re considered dangerous at best.

It’s fair to say we’ve spent a long time in prototype and alpha phases. In order to move forward, our identity needs to be more befitting of the project we’re building. A move into the real world. This isn’t a hobby project, it’s a full blown Linux distribution with serious technical underpinnings, achievements and goals. Getting the tone right from day dot is critical.

Do note, there is no change to the internal core team, so we’re aiming for full continuity and a seamless transition. Had enough of these snakes on this plane? We have too.

✨ What’s the new name?

Hah, it’s not “Evolve OS”, despite the clickbait title. Our new name is… drum roll please…

🌟 AerynOS

Pronounced like “Erin”, it’s a name that we feel is more befitting of the project. Pulling from multiple etymologies, it’s a name that better describes the project now versus the project that started as Serpent OS.

“Aer” is rather obvious, Latin in origin. The phonetic “Erin” is a nod to the Irish roots of the project, and of course a home. There are a number of reasons for the name, which will form part of the initial documentation on the new website.

Our intent is to have a name that is more inviting, and more descriptive of the project’s goals and aspirations. We’re not anti-establishment or anti-corporation - if anything, we’re a statement that without the fiscal handcuffs, we can produce a technically sound and user-friendly operating system.

⏰ Timeline

Having already secured AerynOS.com, AerynOS.dev, plus the associated social media accounts, we’re now in the process of rebranding the project. For sheer irony, we’ll make the final transition day the 17th of March, 2025. Yes, St. Patrick’s Day. The Matrix space has already been updated, and any areas where a new name isn’t feasible will see almost immediate renames.

A new GitHub organisation has been created, with our first priority there to create a proper organisation structure for once. Over the coming weeks everything will be migrated over, and we’ll mark the old organisation read-only/deprecated. Can’t have folks thinking Serpent OS was abandoned, after all.

Stick with us, we’ve got plenty of exciting news to come over the next days and weeks, as we embrace new transparency and shed our old skin. Plus, we’ll be starting to onboard for web properties, translations, artwork, and more. Cherry on the cake? Admitting that we’re actually building a full distribution will allow us to put relevant priorities in place to expose Serpent OS.. I mean AerynOS .. functionality to the wider world. Get ready for a reboot of the grassroots, independent Linux scene. We’re here to stay.

Hello 2025

Thu, 06 Feb 2025 22:05:55 GMT

TL;DR: Serpent OS is facing funding challenges but development continues. Alpha2 is coming soon with an improved installer. We’re seeking community support through donations and volunteers for key roles. Our technical roadmap includes versioned repositories, immutable OS features, and improved package management workflows.

We had a flurry of activity around the Christmas period, including our first alpha release as well as enabling offline rollbacks early in January. We’re actively working on alpha2, but we also need to talk about the elephant in the room.

🐘 The elephant in the room

Recently I posted a tweet that has been covered by a few news outlets. The long and short is quite simple: distinct lack of funds. A very long story short: a change in my contract led to a loss of income protection, combined with a herniated disc (C6-C7), culiminated in having to resign. Naturally I’ve been working exclusively on Serpent OS since then, but I’ve also got to keep the lights on at home.

This doesn’t mean the project is closing or anything like that, but it does mean that I actively need to keep costs down whilst using daytime hours for financing. This is what’s led to the significant slowdown in the last few weeks, and I’m just trying to be as transparent as possible and manage expectations.

💼 But couldn’t you just get a job?

Sure. The reality is that with a job, and kids, there’s very little time left for Serpent OS. I personally believe very strongly in Serpent OS, and I want to see it succeed. As a truly independent project, we’re in a unique position to do things that other projects can’t. We haven’t got to answer to shareholders, or concern ourselves with market share. We can focus on making the best possible OS for our users.

But it’s not just that. We’re building the tools so that others can build their vision of the best OS. Or provide applicances. Or <insert your idea here>. We’re building a set of tools and principles to facilitate innovation and disruption, for projects of any size. We’re not just building an OS, we’re building a platform. Bring your own distro, if you will.

My sincere hope is that others also believe in this vision, and can help us get there. It’s make or break time, and you have the power to help us make it.

💰 Funding

OK, so how can folks help? The most obvious one is funding, so we’ll get that out of the way first. Right now it’s possible to support us via Ko-fi or GitHub Sponsors. For the sake of transparency, as noted on the Sponsor page, we haven’t got an established company or business bank account. In time, we’re looking towards something more cooperative. For now, the reality is the daily running and development largely falls on me.

🏗️ Infrastructure

One way that we could certainly cut some costs, and improve scaling, is through additional infrastructure. We’re currently hosted on a single Hetzner server, and we’re looking to expand that to a more distributed setup. Rune Morling currently hosts 2 of the builders in his home at his own expense, and the main server is also the primary builder, which is less than ideal.

We need to split the repository hosting as its grown enormously, and could do with a few more builders to facilitate “try builds” of pull requests.

Lastly we’re looking at CDN solutions to improve the speed of package downloads (efforts currently ongoing).

👥 Roles and responsibilities

We’re growing quickly and that comes with some pain points. We’re looking for immediate help in the following key areas:

Community management: Someone to manage social media, forums, and other community platforms.
Documentation: Once we pivot to Astro + Starship, we’ll need to focus on adding high quality documentation.
Translation: We’re enabling gettext + fluent where appropriate, and will need extensive translation work.
Web development: We need to improve our web presence, management of web properties, transition to Astro, etc.

While of course we’d also love more developers and packagers, most of the time is spent in these areas already, and the other roles desperately need attention.

🚀 Latest developments

Before we get into the future, let’s talk about what we’ve been working on lately.

💾 Disk Management (disks-rs)

A couple of weeks back we broke the news that we were working on a new disk management library, disks-rs. The scope wasn’t made quite clear at the time, but it’s another building block to facilitate smarter applications. Eventually we want to support the manipulation of various filesystems and disk structures, for use in CI pipelines, etc.

Another requirement for disk-rs is to not only expose sane partitioning logic, but also to provide a way to declaratively define disk layouts. This will be used in the installer, but also for reproducing entire installations. It forms the basis for our future provisioning system.

Right now we’re working on a very cool .kdl based format for defining disk layouts. It takes advantage of kdl-rs streaming parser to implement a procedural syntax complete with miette error handling for a very nice developer experience:

// Create a partition table. Defaults to GPT
create-partition-table type="gpt" disk="root_disk"

// Create the ESP
create-partition disk="root_disk" id="esp" {
    constraints {
        min (GB)1
        max (GB)2
    }
    type ...
}

🛠️ Installer

Our installer has quite a nice backend, but honestly the frontend experience leaves a lot to be desired. Given that our current focus is being able to not only onboard developers but build tooling against an installed system, we need to make the core of this effectively scriptable. To do so will build upon ongoing IPC work for moss and disks-rs, and the introduction of a new GUI frontend based on Slint. While early days we’re trying to think 10 miles down the road, where we can utilise the LinuxKMS backend for minimal installer ISOs.

Early preview:

🔮 The road to stability

So we have some exploratory works in progress, and it’s time to discuss how they all relate to the future of Serpent OS. You’ll immediately notice that these are highly circular in nature, meaning we need to switch between different areas routinely. In order to design an effective architecture, whilst minimising disruption, we need to have a clear vision of the future that we’re referring to as “10 miles down the road”.

📚 Versioned repositories

As previously explained, one of the built-in mechanisms to support a rolling release with breaking changes to the format is to introduce explicitly versioned repositories. Long story short, a local moss client will only “see” the latest version of the repository that it can actually use. Breaking changes will mean format bumps, and newer repository versions will be unavailable until the client has updated to a client/Serpent OS version that actually supports it.

This work requires changes to the repository format, infrastructure, and a migration path from the current repository to a new archive. However, it is also dependent on having a new format version being available for the versioned-indices.

🔒 Immutable OS

Frequently Serpent OS is described as an immutable OS, but in actuality it is an atomic OS. That means we’ve focused entirely on providing a reliable update mechanism, rollbacks, etc. We have not yet enforced immutability, aka a read-only root filesystem.

Our plan is heavily inspired by composefs. Currently moss produces new filesystem trees using a hardlink farm approach, and relies on renameat2() to atomically switch the root filesystem. This is a very fast operation, but does not provide immutability.

Leveraging the ability of moss to dynamically construct filesystems from packages, it will be abstracted into a driver mechanism. This will allow the classic hardlink approach for buildroots, but employ a new erofs strategy for immutable installs. The newly generated erofs image will essentially rely on extended attributes to “point” to the underlying content addressable storage, and utilise overlayfs to present a read-only view of the filesystem. Further building on this we’ll use so-called “mount tucking” to provide the mechanism for atomic updates without the need for a reboot.

🤔 Why not use composefs?

We’re actually going to make moss support exports to composefs format, making it an ideal match for podman use cases, deduplicating the image content. Whereas composefs produces content from an existing tree, we’ve already got content addressable storage, independent transactions and databases to facilitate this. This means we’ll be able to retain our composition features and very quickly produce the new erofs images. Using composefs directly would significantly slow down the time to produce each transactions, whereas we can instead build a similar internal functionality and integrate at higher levels.

We also plan to integrate the file digests in a new revision of the moss stone format, which will open the door to supporting SELinux xattrs, as well as fsverity for the immutable images.

Note that this goal will inform the requirements for the next stone format, which will in turn require versioned repositories. Of course, this also impacts the build pipeline infrastructure.

👷 Maintainer burden

Truly the most time consuming task in most distributions is the cost of maintaining packages. This is being approached, as with all of the planned goals, in an incremental fashion. However, it often pays to have a view 10 miles down the road to determine exactly how to get there.

🧬 ABI Tracking

In order to provide sanity for developers, and make guarantees about the stability of the system, we need to track the binary ABI for all packages. Furthering on this, we can of course immediately detect any breakage and schedule rebuilds as appropriate. This will also add a higher degree of confidence for pull requests as we’ll know if its consistent or introducing problems.

🔄 Pull Request workflows

The workflow for packaging right now is for someone to open a pull request, which contains their recipes, the automatic “build records” (manifest) and our assumption that they built it using a local repo based on top of the latest repository. What is actually needed here is for the infrastructure to perform automatic (low priority) builds of each pull request in a transient repository, making those builds available for verification purposes.

⚛️ Atomic repo merges

Another limitation with the current infrastructure is the reliance on a global build queue. Simply put, once a PR is merged, all of those builds are scheduled and individually published to the target repository upon completion. This is very naive, and leads to a lot of “nannying” in the event of a failed merge.

In future, those builds will be scheduled in a transient repository, and upon successful completion the resulting artefacts would be published to the target repository in a single atomic operation. This will also allow for the introduction of “try builds” for pull requests.

🩸 The bleed-through problem

Another issue which partially relates to bootstraps, is the bleed through problem. This is an artefact of using layered repositories, such as a local repository, to build updates that would change the providers available in the underlying repository upon merge. Take for example, LLVM.

main repo:
    ├── rust [runtime-depends: libLLVM-18.so]
    └── build-dep: binary(rust) [runtime-depends: libLLVM-18.so]

local repo:
    ├── rust [runtime-depends: libLLVM-19.so]
    └── build-dep: binary(rust) [runtime-depends: libLLVM-18.so]

After completion of libLLVM-19.so, the local repository would contain the new version, but the main repository would still contain the old version. Locally this would allow the circular build dependencies to work as rust builddep for rust could still resolve libLLVM-18.so. However, upon, merging to the repository, we have a new problem. The main repository would now contain libLLVM-19.so, but the rust package would still be built against libLLVM-18.so. This then breaks the dependency chain for rust, requiring manual intervention.

To solve this, we’ll ensure that filtered repository views are introduced both for local builds and our build infrastructure. This will mean that the index of the local repository will occlude the main repository, and eliminate bleed-through.

⭕ The bootstrap problem

Whilst ABI tracking is very important, it doesn’t actually solve the bootstrap problem of circular dependencies. This is a consequence of using an incremental development model for a binary-first distribution. In reality the only real way to solve this is by eventually altering the tooling to support a “world view”, with intermediate recipes that are not published to the final repository. In effect, combined with ABI tracking for dependency chain invalidation, we can determine which recipes need to run again as part of an invaldation-solver loop that relies on “cached artifacts”, i.e. the final packages.

This isn’t an immediate issue to solve, but it will inform our next steps to ensure we get to that point without requiring extensive overhauls or “stop the world” rewrites. Our eventual vision is that building any new package will feel much like it does now, but changing a reverse dependency will evaluate the dependent chain for rebuilds. To make this streamlined, the infrastructure will by this time have grown to a point where we can share the compute power by way of so-called “try builds”, and a shared cache of artifacts.

📦 Keeping the packages up to date

A large portion of the burden is in reality chasing updates. Currently we have a very simplistic utility that cross-references release-monitoring.org to spit out a list of recipes that have available updates. Truthfully we could easily generate diffs for these updates, and even automate the process of updating the recipes. This is dependent however on having confidence in the pull request, which in turn is dependent on ABI tracking being in place.

🗂️ Organising it all

We have a complex series of interdependent goals, which require research and frequently shifting between focus areas. Not all of them will be immediately realised, and some are simply informing the direction for our future. Additionally, we need to keep moving without any “rewrite the world” pauses.

It’s important to highlight that none of this is a reinvention of the project, but a series of steps to “1.0” and beyond to ensure that the project is sustainable and reliable. This means that delivery continues, and the delivery itself becomes simpler and more trustworthy.

Despite the interdependencies, once we’ve finished scoping the end requirements we can work towards the immediate concerns:

Pull request workflow
Repository consistency (initially ABI story)
Update automation
Immutability

Note: These timelines are estimates and may adjust based on available resources and community support.

Scale-up considerations

We’re at the point where we need a functional OS for contributors to be able to work on the project. It also presents a paradox because we wish to keep the project lean whilst we work on extending the scale-out capabilities. In reality this means that we’re going to permit a limited amount of repository growth:

Addition of the Plasma desktop for daily use
Container-management tooling (podman, docker, etc)
Development tools (IDEs, etc)
Onboarding requirements (such as Matrix clients, documentation, etc)

This in turn also requires a more reliable installation experience, which is why we’ve been spending cycles on the installer project. Internally we want the installer to support a variety of scriptable configurations in order to provide better test coverage for our updates and boot management, whilst we also intend to incrementally improve the user experience.

📅 Conclusion

Alpha2 is coming, and will feature a preliminary version of the updated installer. The plan initially is for a simple “use whole disk” strategy and will be followed up with supported for encrypted installations (post alpha2). Quite simply, some employers require their developers have encrypted installs, and not supporting this configuration will restrict our ability to onboard developers.

We’re doing the Alpha2 as a baseline, from which all update testing, infrastructure adjustments, etc, will be measured against. This is the point at which the project will formally “open the doors” for more developers and testers, with the explicit view that growth is sustainable and manageable. Per the requirements set above, we’re not going to “explode”, but enable specific workflows that in turn will permit us to scale out the project and inform direction.

It’s important to me that we’re explicit in how we take our next steps. As stated earlier, pausing the world is not an option. Continued delivery whilst enabling an incremental path to the future is the only way to ensure that we can deliver on our promises. Contrary to a reboot, this is a solidification of our vision and a commitment to the future. Sure, new features will also appear in time, such as easier packaging recipe formats, but no decision is being made that will require a rewrite of the project. However, these goals require stating and explaining up front so that the high level vision is clear and provides the context for any short-term deliverables. The last thing we need is to be in a position where we’re “stuck” and unable to deliver, due to a lack of foresight.

🙏 Thank you

On behalf of the project, I’d like to thank everyone who has supported us so far. Whether that’s through donations, code contributions, or even having the time of day to try out the ISO, it’s deeply appreciated. Being the underdog comes with its own set of challenges, and of course the “indie cost”, but it’s also an opportunity to challenge the status quo and find new, more optimal ways, to do things.

We’re not just building “Serpent OS”, we’re building a set of tools to solve the problem of distributing an OS. Way down the line this will be powerful enough to support a number of use cases, from appliances to desktops, and even servers. In short, we want to bring high quality tooling to the masses, and we’re doing it in a way that’s sustainable and reliable.

Offline Rollbacks Enabled

Sat, 04 Jan 2025 22:19:37 GMT

If a picture tells a thousand words… well then this video .. Yknow what, sod it. Here’s a video of the offline rollback support in action, as tested in a newly installed VM using xfs for the root filesystem. We jokingly refer to this as the “LTT” test due to LinusTechTips’ “interesting encounters” with package management systems in the past.

This has already landed in our volatile repository, so simply sudo moss sync -u and grab the latest updates. Any subsequent transactions will automatically generate the boot entries for you, no intervention required. Or mounting. Or anything. Just update and go. Srsly.

We actually saw this as a golden standard for the feature, as it’s a real-world scenario where you’d want to roll back to a known good state. The video shows the system booting and recovering in multiple ways, from complete system nuke (via glibc) and simpler scenarios like removal of the GNOME desktop environment.

The intent is to ensure a user can quickly revert to the last transaction that worked in the instance an update goes awry, without needing to boot into a rescue environment or live CD.

Like what we’re doing?

Developing a project with the scope of Serpent OS is no small feat. In order to maintain our current cadence, and to land huge features like the offline rollback, or impending system model work, we need your support. I’m as happy as the next person to return to the job market once my medical conditions ease up, but the simple matter is this will greatly slow down our recent progress.

Our aim is to entirely redefine the distribution of Linux, and the years of prior effort are finally coming together rapidly to make this a reality. If you like what we’re doing, consider supporting us!

Visit our sponsor page for more information on how you can help us grow and deliver the future of Linux distributions.

Technical Details

This is all achieved using moss’s internal content addressable storage for deduplication, where each old transaction is swapped with the live /usr at the time into the archive.

The behaviour is implemented in the initramfs (dracut) by invoking moss state activate $transaction_id -D /sysroot, ensuring that the activation is performed before the new root is mounted and the system is booted. We actually shrunk our moss and uutils-coreutils builds to half their usual size so that we can fit them comfortably into the initramfs.

For now, we’ll automatically generate entries on the ESP (or XBOOTLDR) for the last 5 transactions, and you can select them during early boot to perform the rollback. It’s not slow, as it’s just doing yet another renameat2() to atomically exchange the live /usr with the archived transaction.

TLDR: Boot time rollback, no network required, no live CD required, no rescue environment required. Just a working system.

What’s next?

The system model is coming next, which will expose the non-imperative core of the architecture to users. The usual commands will continue to emulate an imperative OS, by mutating the system model and applying the internal sync operation. This ensures dependencies are resolved only according to the layered repository configuration, without special exceptions for “installed” (which.. we spent a lot of effort faking this behaviour).

It’s good to remember that moss is effectively a huge cache, and that each state has no relation to the other. We simulate upgrades by building a new state with the same selections as the old one, then begin to upgrade those candidates.

The new model (somewhat Gentoo inspired ❤️) will allow moss to build the dependency graph for the finished system state. As a sneak preview of what we’re enabling, imagine the newly landed transactional reboot code linked with multiple system models… such that you might decide to moss sync from your existing model to an entirely different one, rebooting from your GNOME desktop to a KDE desktop, for example. Cleanly, atomically, and without any manual intervention.

Investing in the Future

Tue, 31 Dec 2024 14:00:11 GMT

Here we are, at the end of 2024, and what a year it’s been! We’ve made significant progress on Serpent OS, and we’re excited to share some of the highlights with you.

Attained Alpha

Virtually 5 years in the making, we recently attained alpha status. Our tooling and concepts have aligned, allowing us to now rapidly iterate on the core deliverable itself: Serpent OS. We’ve seen an explosion in cadence, with our tooling enabling us to quickly and easily deliver updates, new packages and enabling new features.

Since the Alpha 1 ISO (0.24.5), we’ve fixed a number of issues in relation to hardware and booting. We’ve also added new features to moss (refined boot management) and boulder (our build system). Even now we have multiple PRs open to tidy up moss, add automatic generation of monitoring.yaml files, and more.

Keeping the cadence

We’ve been working hard to keep the cadence up, and we’re now at a point where we can deliver new ISOs on a regular basis. Our main focus now is the tooling, in enabling a far more automatic delivery pipeline. The vision is having automated pull requests generated for package updates, automatically handling changes in dependencies and ABI, and ordered by build tier. This will significantly reduce the maintainer burden, in conjunction with planned security monitoring.

Short term deliverables

In the short term we’re going to land the following features:

Offline Rollbacks - We’re going to land offline rollbacks in the boot menu, allowing you to easily revert to a previous system state.
Versioned Repositories - We’re going to introduce versioned repositories, allowing us to gracefully handle format changes in moss and boulder, permitting an “update forever” epoch-staggering approach. Additionally, this will allow users to stay on an older repo version if they’re awaiting a fix to a regression in a newer version.
Improved Documentation - We’re going to improve our documentation, making it easier for new users to get started with Serpent OS.
Tools as a service - We’re adding IPC layers to our tooling, allowing them to be launched as helper services for integration in other applications. This will allow us to integrate moss with GNOME Software and COSMIC Store, for example. Additionally it will ensure the latest version of the moss binary is always used by the system, gracefully handling version repo changes. Chiefly, this will allow moss to cheaply integrate anywhere we need it, including for lichen.
Lichen Improvements - Lichen will also be converted to an IPC based backend, allowing it to be executed via pkexec for integration into a GUI (or even CLI) frontend. This is a necessary step to allow the frontend to operate without privileges, facilitating live updates to the NetworkManager configuration, or indeed keyboard layouts. Long term we’re planning a cage based kiosk with a full screen installer mode, on a far smaller ISO.

Long term vision

Our long term vision is to deliver a system that is easy to use, reliable, and secure. We’re building Serpent OS to be a system that updates forever, confidently. We’re also shaking things up by being first-adopter of new technologies as default solutions, with a view to enhancing the robustness, origin-diversity and security of the system through Rust based replacements and alternatives to key components. You can already see this with our adoption of sudo-rs, coreutils (uutils), ntpd-rs, and not to forget rustls by default for our curl build.

Outside of that, moss, boulder and the supporting crates are also written in Rust, giving us a strong foundation for the future.

Serpent OS is a project that is built to last, and challenge the status quo. Deliver a Linux distribution for use on multiple verticals, with the feeling of a conventional Linux distribution, but with key management facilities and architecture designed to make a rolling release distribution that can be trusted for long term use, extensive updates, and the ability to entirely re-engineer the entire OS, delivering in a safe atomic update without breaking client installations.

How you can help

In order to give Serpent OS the development time it needs, we’re looking for sponsors to help fund development. If you’re interested in becoming a sponsor or investor, please do not hesitate to get in touch. We want to secure funding for development and infrastructure for the next 2 years.

While of course we need to iterate on our own tooling, we also need to be able to work more upstream and with kindred projects to drive the ecosystem forward. In time, we wish to become the incubator for new technologies and solutions, and we need your help to do that.

With your support, we can expand our builder network and enable more hosting, bandwidth, and compute resources. This will in turn enable our automated rebootstraps, which will of course allow downstreams to extend upon Serpent OS as a kit-distro. Indeed, it’ll allow us to expand beyond x86_64 when the time is right.

While Serpent OS currently delivers a desktop ISO, this is not the limit of our potential. As indicated, our priorities in the short term are designed to massively aimplify project maintainer bandwidth and free up more time for feature iteration and development. Once we’re quite happy with the base (and we’re not far from that point) - we’ll quite happily extend to other desktops, and even server/cloud offerings.

Nothing is bullet proof, but with the architecture and tooling of Serpent OS we can get pretty close. Gotta admit, having a transactional, atomic OS with rollbacks, and the full granularity of a conventional package manager, is pretty cool. 😎 Especially when things “Just work” out of the box thanks to the stateless (“hermetic usr”) requirements of the system.

Know what’s even cooler? When we land our system-model implementation, you’ll be able to completely duplicate the setup between local development and production. When we also land our export/compose functionality in moss, you’ll be able to reap these benefits in containers too. 🐍

Here’s to a great 2025, and we hope you’ll join us on this journey. 🚀

Alpha Refresh Available

Sun, 29 Dec 2024 16:45:48 GMT

In response to feedback from the community, we’re issuing a refresh of the Alpha 1 release, 0.24.6. This refresh includes a number of key updates and improvements, including:

Now works with etcher
Fractional scaling enabled by default
Prebuild icon theme caches to speed up trigger execution (except for hicolor)
Add new moss boot status command for introspection into blsforme functionality
Fix amdgpu initialisation for older devices, previously leading to black screen on boot

Clarification on moss boot management

Frequently in Team Serpent we joke that moss is the “systemd of package managers”. It actually does a whole lot more than is easily visible.. for example:

Content addressable storage for the entire OS
Atomic updates of /usr by renameat2() w/ RENAME_EXCHANGE
Executes transactional triggers in a namespace (container) with RW /usr and RO binds of /etc and /var …
Executes system triggers postblit, with dependency ordering..
Via blsforme, manages the ESP, XBOOTLDR, boot entries, sync and promotion of bootloader, kernel and assets, initrds..
Entirely zero configuration. No /etc/default/grub, no remembering your root={}, it’s determined automatically.
Basically does all the work of OS provisioning, barring disk mounting and partitioning. Our installer, lichen, is basically a thin wrapper of moss.

We’ve had no debugging capabilities around the boot management, so we’ve landed moss boot status command. It’s super primitive but does offer an insight into the introspection capabilities of blsforme. In this simple screenshot, moss/blsforme are supporting the Boot Loader Protocol, querying the systemd-boot entries in efivars. When found, LoaderDevicePartUUID is used to determine the boot ESP, but moss/blsforme will quite happily read the GPT directly (relative to / mount) and find the ESP and XBOOTLDR…

Remember - we happily use systemd-boot. We do not use bootctl or kernel-install. Entries are automatically managed and we’re extending this to support offline rollbacks via boot menu (feel free to extend with /etc/kernel/cmdline.d/*.cmdline drop-in snippets!) Also note we do not allow systemd to automount the ESP or XBOOTLDR via the GPT autogenerator, instead moss/blsforme will automatically discover and if necessary, mount these partitions, when dealing with bootloader or kernel updates.

With this explicit control over the boot management, we’ll happily be landing secure boot and fwupd support in the near future, without the downsides of trying to provide EFI assets to /boot in a package itself. 😬

A note on virtual machine usage

It must be clearly stated that Serpent OS does not support anything other than UEFI booting on x86_64-v2+ capable hardware. Please note that GNOME Boxes will default to BIOS, not UEFI, and will need hand-mangling of the XML file. Also note in other solutions such as VirtualBox you will need to specifically select EFI in the VM settings.

In order to maximise compatibility with other tooling and firmware, we’ve modified the generation of our ISO to include the isolinux MBR/GPT hybrid components, however we deliberately did not include a functioning bootloader for BIOS boot. Instead, you will see a boot failure indicating that ldlinux.c32 could not be found, which is a sure-fire way to know your VM or hardware is incorrectly configured.

Installer notes

Lichen is due to receive some love in the next few cycles, so please be aware of the following limitations:

A pre-configured GPT disk is required before lichen is launched
A working internet connection is also required, this is a network installer
A FAT32 formatted EFI System Partition is required (marked as esp in gparted)
For optimal usage, or when your ESP is tiny, please create an XBOOTLDR partition:
- Create an FAT32 partition in gparted of 2GB in size
- Mark it as bls_boot in gparted
Further filesystem support for XBOOTLDR will be added to blsforme when we’ve finished packaging efifs.
XFS or F2FS are strongly recommended for the rootfs, due to the limitations of ext4 with hardlink counts.

COSMIC Desktop

We’ve made the decision to pause our offering of COSMIC Desktop ISOs. We’re huge fans of the project, and we strive to keep it up to date and functional. However, it is very early in alpha, and so are we. It doesn’t make a lot of sense for us to extend our workload to two alpha codebases!

We still offer COSMIC as an option in the installer for those who wish to try it out, and do encourage testing and engaging upstream with the developers. For now, we will offer just the GNOME ISO.

Next up

In the new year we’ll be focusing heavily on our tooling to facilitate a scale up of our packaging efforts. We’re quite proud of our tooling, but we’re not oblivious to the warts and issues. The next couple of weeks will be spent improving our documentation (or making it exist!) and making sure that we have the ideal workflow in place to permit large stack updates along with the ABI consistency verification we need. This will also pool work for ent, moss, boulder, by streamlining packaging, and making it trivial to update an entire stack of packages in one go. Eventually this will be an automatic thing, with successful PRs being verified and then merged into the volatile repository.

Don’t forget, versioned repositories are also coming your way, and very soon we’re landing offline rollbacks in the boot menu! blsforme has been significantly restructured for cmdline handling, and understands entries in the context of a distinct system root (ie moss filesystem transaction) - which is the bulk of the work needed to facilitate offline rollbacks. The last piece will be running moss at an early stage in the initrd to swap the /usr pointer to the older transaction, which is instanteous and atomic.

Final thoughts

5 years and no release, and now two alpha ISOs before the end of the year. We’re pretty happy with that, and we’re going to keep surprising you next year with more releases, more features, and more stability. Happy new year from all of us at Team Serpent! 🐍

If you like what we’re doing, please consider sponsoring us - this will allow us to grow our infrastructure and deliver builds quicker. Due to health issues in the last few months, I was forced into a position whereby I had to resign from my job. Any and all contributions to the project are greatly appreciated, and will help us to continue delivering what folks are frequently now calling “the cleanest Linux implementation they’ve ever seen”.

Try it. You might like it. 🚀

AerynOS | Blog

A post we never want to have to make!

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!

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

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!

March 2026 project update

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!

February 2026 project update

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!

January 2026 project update

AerynOS: January 2026 project update

What’s new in the distro

Desktop Updates

Cosmic

Faster `moss state remove`

Improved `moss search`

Boulder `--verify` flag for manifest checks

Parallelize the `moss state verify` command

moss `system-model` prototype feature