diff --git a/src/content/docs/blog/2026/08/31/A community that works together, builds together/discourse.webp b/src/content/docs/blog/2026/08/31/A community that works together, builds together/discourse.webp new file mode 100644 index 00000000..7c2cc0a4 Binary files /dev/null and b/src/content/docs/blog/2026/08/31/A community that works together, builds together/discourse.webp differ diff --git a/src/content/docs/blog/2026/08/31/A community that works together, builds together/index.mdx b/src/content/docs/blog/2026/08/31/A community that works together, builds together/index.mdx new file mode 100644 index 00000000..32975aad --- /dev/null +++ b/src/content/docs/blog/2026/08/31/A community that works together, builds together/index.mdx @@ -0,0 +1,233 @@ +--- +title: "A community that works together, builds together" +date: 2026-08-31T23:00:00Z +authors: [nomadiccore, ermo] +tags: [news] +license: "CC-BY-ND-4.0" +copyright: "Copyright © 2026 aerynOS Developers" +--- + +import { Aside } from "@astrojs/starlight/components"; + + + +Whilst August is a holiday month around Europe, it's safe to say it's been a very busy month around the project, with a lot of progress made across various core tooling repositories. + +Following on from our Versioned Repositories phase 2 work that we landed last month, we are developing `moss` on multiple fronts. [tarkah](https://github.com/tarkah) has supplemented our current hardlink driver approach with a reflink strategy for filesystems that support it, along with working on an in-progress development sprint to eventually deliver an EROFS metadata-image based approach that will be fully filesystem agnostic. [Fabio](https://github.com/livingsilver94) is working on moss' command tree, reorganising the commands we already have but also looking forward to the command functionality we will eventually want to have available. Lastly, [Jonathan](https://github.com/otherJL0) is also working towards improved search and shell completion functionality that will make `moss` easier to interact with for both users and packagers alike. + +[Joey](https://github.com/joebonrichie) has delivered a number of performance-related improvements to `boulder`, making packaging quicker and also offering additional optimisation techniques such as BOLT for key packages. + +On the distribution side, [Reilly](https://github.com/reillybrogan) has led our expanding packaging team through a repository-wide rebuild to ensure ABI sanity and protect against potential bit rot. Ultimately, this means less risk of broken packages or systems for our early adopters. + +In a separate work stream, staff member [Bryan](https://github.com/bhh32/) is working on a new TUI-based lichen installer that is substantially improved from the current lichen installer that we offer. We are developing it openly with updated versions being shared in our [Zulip server](https://aerynos.zulipchat.com/). Bryan is taking on board feedback and iterating on the design and functionality with the aim of it being included in a future ISO. Key improvements include automatic disk formatting, system-model-driven installs, btrfs as a root partition option and generally a much more refined TUI navigation experience. + +Staff members [Alice](https://github.com/CookieSource/) and [NomadicCore](https://github.com/NomadicCore) have worked on a new [Discourse forum](https://aerynos.discourse.group/) that will replace our GitHub Discussions forum. We are thankful to Discourse for sponsoring the project with this server, and to our community members who have been giving us feedback on the layout. It is now ready for wider use by our community. + +Finally, we're continuing to refine the project's branding with a slight tweak to the project name from AerynOS to aerynOS along with tweaks to logo colours and fonts. + +## What's new in the distro + +### Packaging and stack updates + +The wider aerynOS team has expanded with a "Trusted Maintainers" role that sits under staff. We have [Jaredy899](https://github.com/Jaredy899) and [K1ngfish3r](https://github.com/K1ngfish3r) currently operating in this role and primarily supporting reviews and approvals in our [recipes repository](https://github.com/aerynOS/recipes). + +Their addition to the wider team has made a substantial impact on day-to-day package maintenance and is helping ensure aerynOS stays current. In addition, we have implemented a new [Packaging Policy](https://github.com/aerynOS/recipes/blob/main/PACKAGING_POLICY.md) and new Issue and PR templates to support users, maintainers and staff to efficiently and effectively manage our recipes repository. + +Package highlights for this month include: + +- CMake 4.4.3 +- COSMIC DE 1.7.0 +- Ccache 4.14 +- Faugus Launcher 2.2.1 +- Firefox 154.0.1 +- GCC 16.2.0 +- Gamescope 3.16.26 +- Glibc 2.43 +- KDE Frameworks 6.29.0 +- KDE Gear 26.08.0 +- KDE Plasma 6.7.4 +- Linux LTS 6.18.47 +- Linux gaming 7.2.1 +- Linux stable 7.1.11 +- Mesa 26.2.1 +- Neovim 0.12.5 +- NetworkManager 1.58.1 +- Node.js 24.20.0 +- PHP 8.5.10 +- QEMU 11.1.1 +- Qt 6.11.2 +- Rust 1.98.0 +- Thunderbird 154.0 +- VS Code 1.135.0 +- Wine 11.16 +- Youki 0.7.0 +- ZFS 2.4.4 +- Zed 1.17.2 +... along with sundry additions and updates. + +## Infrastructure and Tooling Updates + +### `moss` and EROFS metadata images + +We mentioned EROFS metadata-only images that would operate in a read-only capacity. Work is still ongoing in this area, however in the meantime, we have delivered a more general filesystem tree abstraction within `moss`. This has then been supplemented with a [reflink](https://linuxjunkies.org/glossary/reflink) approach for the filesystems that support it. + + + + +The new `fstree` driver API separates the concept of a filesystem tree from the mechanism used to create and manage it. Our existing native implementation now works through this abstraction, while an overlay-image driver is also being developed and tested. + +This is important groundwork for the EROFS metadata-image approach, as it allows `moss` to work with different filesystem tree approaches without coupling the higher-level state-management code to one particular approach. + +The EROFS work is still very much under development and is **not yet delivered**. There is still testing and integration work to complete before we can consider making it available to users. + +### `moss` command tree + +The work to restructure the `moss` command line has continued throughout the month and is currently awaiting PR review before being merged. + +We're progressively moving the CLI over to `clap_derive`, allowing the command hierarchy to be represented directly through the command structures rather than being manually assembled. + +A number of commands will be converted, including `repo`, `pkg`, `search`, `state`, `sync`, `cache` and `boot`. + +We will also be able to simplify some of the existing command behaviour as part of this work. The separate `help` and `version` subcommands are being removed in favour of the conventional command-line handling provided by clap. + +The work is being tracked in [PR #687](https://github.com/aerynOS/os-tools/pull/687). + +While this is primarily an internal refactoring at present, it gives us a much cleaner foundation for extending moss' command line as more functionality is added in the future. + +### `moss` search functionality + +The work on moss' search functionality has also continued in [PR #788](https://github.com/aerynOS/os-tools/pull/788). + +The current focus is on making package and file searching easier to understand and use, with a more coherent `moss search` interface rather than requiring users to know which specific search command they need. + +This approach is exploring how package, provider and file searches should be exposed through the command line while retaining the ability to perform more specific searches where required. + +This is still being refined, and we're using the current development work to make sure the resulting interface is useful for both everyday users and packagers while ensuring it links back into the `moss` command tree work highlighted above. + +### `boulder` performance improvements + +We've continued making improvements to `boulder`, our package build tool. + +`boulder` can now emit multiple packages concurrently allowing recipes which produce several packages to make better use of modern multi-core systems while still limiting the amount of concurrent work so that CPU resources remain available for compression. + +We've also updated the BOLT optimisation configuration used during package builds. This includes moving from the deprecated `hfsort+` option to `cdsort` and removing obsolete optimisation options. + +Additional LLVM tuning flags have also been added as part of our continuing work to make better use of the available compiler and linker tooling. + +These changes aren't necessarily visible to users directly, but they help improve the efficiency of the infrastructure we use to build the distribution. + +## Wider Project Updates + +### The global recipes rebuild + +One of the largest pieces of work in the recipes repository over the last month has been our global package rebuild. We last conducted this exercise around May to June last year when we transitioned from our old Dlang-based infrastructure to our newer Rust-based infrastructure. + +We had planned to do repository-wide rebuilds on a slightly more frequent basis and had actually mentioned it in our [February project update](https://aerynos.com/blog/2026/02/28/february-2026-project-update/#invasive-toolchain-and-full-repo-rebuilds), however other development work took priority. We have now rebuilt all packages across the repository to establish a much more consistent ABI baseline as our current tooling does not automatically ensure ABI sanity as a feature; this is currently managed through ingrained knowledge in our core packagers. This is particularly important as we continue evolving aerynOS's underlying system libraries and toolchain. Rather than having a mixture of packages built against different generations of dependencies, we want to reach a point where the repository has a well-defined and coherent baseline. + +With over 1700 recipes each producing one or more packages, there has been a lot of churn in the repository, which also serves as another stress test for our infrastructure. We are happy to say that it has passed with flying colours. + +### Lichen TUI installer + +The new TUI-based version of lichen, our installer, has made substantial progress over the last month. The work is currently being developed on the `tui` branch of the lichen-installer repository and represents a significant rewrite of the installer interface and underlying installation flow. + +As part of the rewrite, we've added the installation and summary screens, installation plumbing, networking functionality, account configuration, storage and filesystem selection, remote KDL fetching and a number of other pieces required to make the installer usable end-to-end. One big feature we think early adopters will appreciate is the ability to install aerynOS to a btrfs partition! + +We've also spent considerable time hardening the installer. This includes improvements around Polkit, ESP and XBOOTLDR handling, password hashing and various installation-flow issues. + +The new installer is now being openly tested by members of our community, with development versions being made available through our [Zulip server](https://aerynos.zulipchat.com/). This testing is particularly valuable because we're now able to get feedback from people using the installer on real hardware rather than relying solely on internal testing. + +There is still feedback from this testing that needs to be worked through, and we continue to iterate on the codebase until it is ready to be included in a future aerynOS ISO. + +Until the new lichen-installer is ready, the current ISO (with the old installer) remains the officially supported way to install aerynOS. We do welcome early adopters to try out the new installer, but please be aware that it is being actively developed and should be treated as development code. + +