Blog

Solid foundations are leading to expanding horizons

Aug 2, 2026

NomadicCore

Comms

Ermo

Co-founder

It’s been several months since our last update in May, and a lot has happened around the AerynOS project in the meantime!

First and foremost, we have tested, landed and productised our Versioned Repositories phase 2 feature, which will serve to firm up AerynOS’ foundations and help us further develop our vision of how to build a Linux distribution.

On the distribution side, Reilly has landed experimental OpenZFS support for data drives alongside significant systemd packaging efforts bringing it from 257.13 to 261.2.

Community member Christian Bendiksen is continuing his work around his Gnist and Malm cli tools for conveniently declaring, applying, and sharing Wayland Window Manager themes, and community member lumi has worked on their aerbox tool, which natively makes use of moss’ system-model concept to quickly create containers gated by access control to network, sound, drives and other hardware.

On the kernel front, we have moved to 7.1.5 for our stable and gaming branches and 6.18.40 for LTS, following a period of elevated vulnerability disclosures in the Linux kernel that required rapid response from the team.

We have also landed NVIDIA driver 610.43.03 in our repositories and have been running a testing programme with community members over the last month that is already yielding positive results.

In our wider project activities, we continue to explore Codeberg as an alternative to GitHub, with our new website built with Hugo using the Hextra theme under active development over there. We are also releasing a new ISO, AerynOS 2026.08.

In terms of our code bases, we have contributors experimenting with improving the moss package search UX, and refactoring some of our shared low-level git and sqlite3 db functionality.

From a development story arc perspective, AerynOS has been deliberately kept under a very tight leash over the last year, as we have focused on strengthening our core tooling and infrastructure code bases. Whilst we are nowhere near “done” with our vision for our tooling, now that our ability to seamlessly deliver updates to our on-disk repository and file formats has been secured, you will see AerynOS deliberately transitioning into a more open and collaborative space for those of you who want to get involved with the project and work on areas that you find fun, interesting and engaging.

This shift in approach has already been evident over the last couple of months, as engagement around the project continues to grow through all of our social media platforms and particularly in our Zulip server.

What’s new in the distro

Experimental inclusion of OpenZFS

Reilly has worked on adding OpenZFS data drive support in AerynOS. This means that we now support btrfs, bcachefs and OpenZFS drives for user-managed data drives.

Reilly has tested OpenZFS on one of his drives; however we need help from you all, our community of early adopters, to test OpenZFS on your drives and provide feedback that we can then use to iterate.

Package- and stack-updates

As ever, our intrepid contributors and staff have landed a bunch of updates. Please check the recipes repository for the latest version numbers as these change frequently. Highlights include:

• COSMIC DE 1.5.0
• KDE Plasma 6.7.3
• KDE Oxygen icon/sound/wm theme
• WayVR 26.7.1
  • envision 3.2.0+git.aa84e48e
  • monado 25.1.0+git.983a8a51
• bazaar 0.9.1
• bitwarden 2026.7.0
• bottom 0.14.7
• buildah 1.45.0
• carapace 1.7.3
• cardwire 0.11.1
• croc 11.0.0
• cython 3.2.9
• dankcalendar 0.3.0
• dankmaterialshell 1.5.3
• discord 1.0.151
• dua-cli 2.39.0
• faugus-launcher 2.0.4
• firefox 153.0.1
• fresh 0.4.6
• gnist 0.3.6
• gram 3.2.0
• imagemagick 7.1.2-29
• intel-media-driver & vpl-gpu-rt 26.2.4
• kitty 0.48.2
• linux-gaming/-stable 7.1.5
• linux-lts 6.18.40
• malm 0.4.0
• mangowm 0.15.5
• mesa 26.1.6
• networkmanager 1.58.0
• noctalia 5.0.0-beta7
• nodejs-22 22.23.2
• nodejs-24 24.18.1
• opengamepadui 0.46.0
• otter-launcher 0.7.6
• php 8.5.9
• plezy 2.11.0
• pnpm 11.19.0
• qemu 11.0.3
• ryzenadj 0.19.0
• signal-desktop 8.21.0
• sqlite 3.53.4
• strawberry 1.2.26
• systemd 261.2
• tailscale 1.98.10
• thunderbird 153.0.1
• typescript 6.0.3
• vapoursynth R78
• vscode-bin 1.131.0
• vulkan 1.4.357.0
• walker 2.17.0
• wine 11.14
• youki 0.7.0
• yubico-authenticator 7.4.1
• zed 1.13.1

… along with sundry additions and updates.

Infrastructure and Tooling Updates

Versioned Repositories phase 2

The team, spearheaded by efforts from tarkah and ermo, have landed our Versioned Repositories phase 2 development sprint. This feature was included in the Unstable Stream update released on 5 July with users having reported a positive transition experience ever since.

This work involves an upgrade to a new on-disk repository format layout, and a new moss KDL configuration file format. This has been designed to prepare the path for future on-disk format upgrades and package manager capabilities.

Most importantly, this enables moss to upgrade itself seamlessly across what would otherwise be breaking on-disk format changes, with no user interaction required, other than running sudo moss sync -u until no new updates are available.

Users simply keep updating their systems and will get new features as part of their normal update workflow. 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 have long considered this feature a foundational must-have for what we are trying to achieve with AerynOS on behalf of current testers and future users, as it enables us to deliver incremental tooling innovations and updates as they become ready for wider consumption, in a completely seamless fashion from a user perspective.

Moss download and CAS reliability fixes

The team received a few reports of issues when trying to verify system states. Upon closer examination, this revealed a small issue in how we look up cached assets in our Content Addressable Store when verifying said store with sudo moss state verify.

However, while digging into that issue, tarkah took the opportunity to add a few extra verification checks that, for now, will slightly reduce blitting speeds, and which will give moss more robust guarantees that assets have been downloaded and cached correctly going forward.

We recommend that people who have previously seen spurious errors when running sudo moss state verify re-run said command with the now updated moss.

Moss native reflink format

While working through the CAS fixes, it turned out that we could trivially add support for reflinks in our native hardlink driver with only a few lines of code. Hence, users using XFS will automatically begin using our native reflink driver that is now shipped with moss. Reflinks enables “thin” files with different names, owners and permissions to all point to the same underlying file content.

Filesystems which do not support reflinks (such as ext4 and f2fs) will instead fall back on the existing hardlink support. However, we have some good news in the pipeline for ext4 and f2fs users as well.

In addition to the new native reflink format support, we are working towards landing a new, optional, read-only EROFS metadata image approach. Apart from being a read-only format, this format will come with the same benefits as the new native reflink format, without the underlying filesystem needing to be reflink capable. Hence, this new format will keep all the benefits our early testers have come to expect from AerynOS.

We will talk more about this in a future blog post when the currently in-development code has been landed and thoroughly vetted.

Systemd packaging and user-facing changes

Reilly reworked our systemd package to ensure that manually enabling or disabling systemd units will no longer be overridden on moss package transactions.

As part of this rework, systemd has been updated incrementally from 257.13, to 258.9, 259.7, 260.4, and finally to 261.2. This represents a significant version jump that brings with it a number of upstream improvements and fixes. Alongside the upstream update, we have restructured how systemd is packaged in AerynOS.

Please note the following important changes:

• Network interface names will change after the next reboot. Please ensure that your configurations are using the new names (e.g., eth0 to enp12s0)

• Systemd sub-packages: systemd-boot, systemd-coredump, systemd-homed, systemd-container, systemd-oomd, systemd-resolved, systemd-timesyncd, systemd-udev, and systemd-userdbd are now separate packages.

• systemd-boot, systemd-coredump, systemd-resolved, and systemd-udev will all be installed automatically if you are using pkgsets (if you don’t know what these are you are most likely using them). They will also be installed if a package you are using directly depends on them.

Wider Project Updates

Experimenting with Codeberg

The AerynOS team hasn’t been impressed with the direction of GitHub for some time now. We talked about this in our January 2026 blog post and we have been exploring Codeberg as an alternative git forge in the background.

Over the course of the last few months, the team has moved our new “in development” website branch over to Codeberg in its own repository. You can follow along with the new website development there including raising new issues and/or submitting your own PRs.

As the new website development continues, we will explore whether Codeberg is a viable alternative to GitHub for our needs. This will allow for better understanding of Codeberg’s CI tooling and function as our first public repository shipping “a release-quality product”.

After this, the team will be in a better position to investigate the possibility of bringing additional repositories over to Codeberg. If Codeberg is found to be a viable alternative, it still remains to be seen how a transition from Github to Codeberg would occur.

One outstanding challenge with a full transition away from GitHub is the GitHub Discussions forum. There is no equivalent on Codeberg so the team would need to see whether another forum platform would be required (or whether a forum platform even makes sense for AerynOS on top of our Zulip chat platform).

Website development updates

Website development is now progressing nicely, with design and implementation work happening across Codeberg and in our Zulip Web Development channel.

The new website is being built with Hugo, a fast and flexible static site generator, and uses the Hextra theme as its foundation. We have been building upon Hextra to tailor it to AerynOS’ needs, and we are pleased with how the site is taking shape.

Rather than over-promising on what AerynOS will deliver (something we feel the current site does today), with the new site, we want to be straightforward with potential users whilst improving our web presence both visually and structurally. The new site unifies our main website and documentation into a single cohesive web presence, which addresses a real issue we have observed: a number of new users joining our Zulip server have been aware of our main site but not the documentation site, and we want to eliminate that gap.

We are taking a deliberate approach of focusing on what we have delivered rather than overhyping what we promise to deliver… No more comments of “blazing fast” anything on the site (even though we know AerynOS is already pretty quick)! The site is coming together piece by piece, and we will share more as concrete milestones are reached rather than offering grand projections.

If you have experience developing websites with Hugo and want to contribute, we welcome PRs on the Codeberg repository.

Please note that this is just a placeholder as the current focus is on the design rather than the content.

Call for NVIDIA testers

We have landed the NVIDIA driver 610.43.03 version in the repos. This driver version has improved DLSS support and several fixes for system sleep and wake-from-suspend issues.

Over the last month, we put out a call for NVIDIA GPU owners to help us test new driver updates, since no-one on the team owns NVIDIA GPUs. The response has been encouraging: several community members have already stepped up and their contributions are positively impacting our testing and validation process on NVIDIA GPU-based systems. Issues that would have gone unnoticed by the team are now being caught and addressed during testing in our volatile stream thanks to this community effort.

That said, more testers are always welcome. The broader the range of NVIDIA hardware we can test against, the more confident we can be in our driver packaging and integration. If you have an NVIDIA GPU, feel free to join us in the NVIDIA Testing Feedback thread on Zulip.

Kernel updates

AerynOS now ships with Linux 7.1.5 on our stable and gaming branches and Linux 6.18.40 for our LTS branch.

Over the last few months, there were a number of Linux vulnerabilities reported that required quick fixes. The team followed along with the discourse and built each new version of the Linux Kernel and landed them into our Volatile repository.

The vulnerability disclosures have somewhat slowed down but in any case, we will continue to deliver the latest point releases as they land into our volatile stream, from where they will be added to our unstable stream once they have been appropriately tested.

ISO refresh

In our last blog post we highlighted that we will be moving away from monthly ISO releases as these had mostly served their purpose.

Given the updates to our os-tooling as part of our Versioned Repositories phase 2 work, it is now an appropriate time to release a new ISO, AerynOS 2026.08, incorporating the latest updates without users having to manually update their way through the repository update process.

The new ISO incorporates all the latest updates to date including the latest 7.1 series kernel, updates to GNOME for the live installer and access to Plasma 6.7.3 and Cosmic 1.5.0 as install options thanks to our net installer approach which will always install the latest packages in our unstable repository at the time of installation.

CDN77 sponsorship

The latest project sponsor for AerynOS is CDN77, who is providing the project with content delivery and storage hosting services.

We’re especially pleased to be working with CDN77 because they’re an independent infrastructure provider with a global network spanning 130 countries. Their extensive Points of Presence ensure fast, reliable service for our users worldwide while aligning with AerynOS’s increasing commitment to European digital sovereignty. CDN77 has a strong focus on performance and reliability, making them an excellent partner for the project. Working with them also helps us diversify our infrastructure and reduce overreliance on large US providers.

We’re currently determining how best to integrate CDN77 into our existing infrastructure setup. We’re considering a tiered approach that allows us to leverage their strengths during this evaluation period. We’ll share more details as our integration progresses.

Next Steps

Upcoming changes to our recipes

The AerynOS team has already adopted KDL for our declarative system-model approach, reflecting our view that it is a much better fit for our use case than YAML. Building on this work, and via our collaboration with Kat Marchán, the author of KDL, we are defining a new KDL-based recipe schema to replace our current YAML-based format.

Transitioning our recipe format from YAML to KDL is one of our next major workstreams. Establishing the initial KDL schema will provide the foundation for future enhancements to our core tooling, with new capabilities being introduced through subsequent revisions of the schema.

To support this transition, we have intentionally deferred adding new features to the existing YAML-based recipe format. As the long-term direction has always been to replace it with KDL, continuing to invest in the YAML schema would have meant developing a format we already considered transitional.

The discussions for this are taking place on our Zulip server and on a GitHub issue.

Call for Contributors

We’re actively seeking contributors across several areas where fresh perspectives would be valuable:

Technical Areas:

• OpenZFS testing — Help us validate experimental OpenZFS support on real hardware
• NVIDIA driver testing — If you own an NVIDIA GPU, help us test our NVIDIA open kernel modules and userspace driver 610.43.03 configuration
• Adaptable concurrent downloads — Help us explore how to optimise moss download performance in wildly different scenarios
• Declarative container configurations — Help us test and shape KDL-declared container setups
• Package search UX improvements — Help us make searching for packages and providers easier for everyone
• Website development — Help us build the new AerynOS website; we’re looking for contributors with experience using the Hugo static site generator

How to Get Involved:

• Join us on Zulip, particularly the Research & Development channel
• Browse open issues on our GitHub repositories
• Submit PRs to the recipes repository
• Contribute to the new website on Codeberg
• Test new ISOs and report feedback

Whether you’re interested in package maintenance, UI/UX, documentation, or testing, there’s room for you. We’ve been deliberately opening up the project to collaborative contributions, and we’d love to welcome you aboard.

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.

Since the last blog post, we are now in a net positive position having borne the project costs since April 2025 whilst receiving sponsorship income since October 2025. 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:

1. Support our staff who currently work on a voluntary basis
2. Scale and/or upgrade infrastructure over time
3. Consider purchasing hardware for compatibility testing
4. 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 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!

Tags:

• news

A post we never want to have to make!

May 3, 2026

NomadicCore

Comms

Ermo

Co-founder

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:

1. Lichen: Fix first boot
2. 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:

1. Major Linux kernel versions for new hardware support
2. 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!

Tags:

• news

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

Apr 30, 2026

NomadicCore

Comms

Ermo

Co-founder

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:

1. linux-lts (6.18): Latest LTS release for our most stable offering.
2. linux-stable (7.0): Follows the latest stable release with very few optimisations for a current stable offering.
3. 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.

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

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:

1. Support our staff who currently work without compensation (apart from occasional hardware donation)
2. Scale and/or upgrade infrastructure over time
3. Consider purchasing hardware for compatibility testing
4. 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 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!

Tags:

• news

March 2026 project update

Mar 31, 2026

NomadicCore

Comms

Ermo

Co-founder

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.

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.

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

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.

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

Sponsor AerynOS

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.

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.

Tags:

• news

February 2026 project update

Feb 28, 2026

NomadicCore

Comms

Ermo

Co-founder

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.

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.

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

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.

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

Sponsor AerynOS

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.

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.

Tags:

• news

Older posts