Skip to content
AerynOS
Blog

Blog

January 2026 project update

NomadicCore
Comms
Ermo
Co-founder

AerynOS: January 2026 project update

Fresh Start

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

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

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

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

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

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

What’s new in the distro

Package / stack updates for this iteration include:

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

… along with sundry additions and updates.

Desktop Updates

Cosmic

Cosmic Install

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

Gnome

Gnome Install

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

Some key updates include:

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

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

KDE Plasma

KDE Install

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

The latest KDE Plasma update brings:

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

New Wayland Compositor Environments

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

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

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

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.

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.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 [email protected].

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.

2025 in retrospect

NomadicCore
Comms
Ermo
Co-founder

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

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

Camp Fire

The TL;DR summary:

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

What’s in a name

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

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

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

The project founder steps away

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

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

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

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

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

Team regroup and reset

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

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

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

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

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

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

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

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

Infrastructure & Tooling development

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

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

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

Versioned Repositories

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

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

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

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

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

system-model

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

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

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

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

Team organisation

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

  • Community management
  • Documentation
  • Translation
  • Web development

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

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

Website development

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

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

Distro updates

DE and WM updates

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

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

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

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

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

Installer

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

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

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

Sponsorship

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

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

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

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

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

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

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

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

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

If you wish to discuss sponsorship details, please reach out to us at [email protected].

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

NomadicCore
Comms
Ermo
Co-founder

AerynOS: November + early December 2025 project update

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

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

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

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

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

What’s new in the distro

Package / stack updates for this iteration include:

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

… along with sundry additions and updates.

Desktop Updates

Cosmic

Cosmic Install

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

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

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

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

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

Gnome

Gnome Install

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

KDE Plasma

KDE Install

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

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

Infrastructure Updates

Auto-pruning in vessel

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

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

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

Wider Project Updates

Transition to netcup for our server requirements

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

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

Transition from Matrix to Zulip

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

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

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

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

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

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

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

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

Transition to Migadu for emails

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

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

This will undoubtedly prove helpful for the project going forward.

Logo / Branding / Website progress

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

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

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

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

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

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

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

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

Documentation website progress

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

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

Download choices and BitTorrent

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

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

ISO refresh

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

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

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

Next Steps

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

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

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

Joey Riches
Tooling & Packaging

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

NomadicCore
Comms
Ermo
Co-founder

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

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

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

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

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

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

Whats new in the distro

Package / stack updates for this month include:

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

… along with sundry additions and updates.

Desktop Updates

Cosmic

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

Known issues

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

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

Gnome

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

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

KDE Plasma

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

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

Distribution Updates

Switching back to GNU libstdc++ from LLVM libcxx

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

Packaging License Matching

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

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

Parallelize the moss state verify command

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

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

Infrastructure Stabilization

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

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

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

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

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

moss system-model prototype feature

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

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

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

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

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

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

Wider Project updates

Donations

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

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

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

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

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

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

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

Presenting the 2025.10 ISO refresh

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

Installer preview

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

Next steps

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

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

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