The developers of AerynOS, previously known as SerpentOS, have published a detailed article revealing the concept and technical implementation of the project, along with the justification for the architectural decisions made. Project lead Ikey Doherty emphasizes that AerynOS is not just "another Linux distribution," but a platform, foundation, and set of tools created with a clear vision in mind.
The main idea of the project is formulated as a question: "What if an operating system behaved like modern infrastructure?" AerynOS is presented as the answer to this question — a system built from scratch rather than following the traditional model of embedded mutations within a distribution. The project draws on the authors' experience in developing other distributions, including Solus and Clear Linux.
Among the key technical solutions of AerynOS are:
- The use of LLVM toolchain instead of GNU, utilizing libc++ and compiler-rt by default. The developers explain this choice as not just a preference for LLVM, but a strategic decision aimed at achieving better diagnostics, ensuring correctness, and maintaining package portability. Furthermore, the system uses glibc instead of musl, which is a conscious choice in favor of compatibility and performance.
As stated in the article: "The performance advantage of glibc over musl is well-documented, especially for compute-intensive workloads and applications requiring optimal multithreading performance." The creators emphasize that their goal is to build a functional, usable system for a variety of application scenarios.
- The concept of 'statelessness' — packages are prohibited from containing any files outside the /usr directory. As the developers explain, this approach forces the establishment of reasonable default values at all levels and eliminates 'terrible three-way merge conflicts when updating packages.' There are no conflicts because everything in /etc and /var belongs to the user, while /usr is reserved exclusively for the system. This concept was developed during the times of Clear Linux and Solus, and it has further evolved in AerynOS.
- Atomic updates — each moss transaction is atomic. The system quickly creates a new /usr tree using hard links from a deduplicated cache. After successful creation and preparation, the new tree is atomically swapped in. The prepared transaction is exchanged with the actual /usr directory using renameat2 with the RENAME_EXCHANGE flag. The update either completes fully or not at all, without intermediate states.
- Project-based boot management using blsforme and disks-rs. The feature of this approach is that the system dynamically generates parameters for the kernel command line by reading the superblocks of the root filesystem devices, which means there is no configuration file in AerynOS containing the 'root=' parameter. Moreover, the moss transaction ID is encoded in the kernel command line and processed during early boot in initramfs. 'In short, this means that each kernel is properly synchronized with the corresponding root filesystem, and rollback is cheap, simple, and available right from the boot menu,' the developers explain. Another advantage is the absence of /etc/default/grub, and if the ESP is erased, moss can restore it from scratch.
- The .stone package format is a proprietary binary package format with a version-agnostic header to ensure future changes. Each .stone package contains four specific types of data (payload), each of which can evolve independently due to versioning:
- Content payload — a contiguous block of deduplicated data, meaning the actual content of the package files.
- Index payload — contains offsets for the content payload, indexed by the XXH128 hash of the content (transition to Blake3 is planned). This allows for efficient data retrieval.
- Layout payload — describes the intended layout of the filesystem when applying the package, specifying where and what files should be installed.
- Metadata payload — a sequence of strictly typed, labeled metadata records such as package name, provided capabilities, and so on.
Compression of all loads is performed using Zstd, providing excellent decompression performance while maintaining a good compression ratio. The process of installing .stone is fundamentally different from other systems. Instead of directly installing files, the package is cached, and its contents are woven into a common storage using content-addressable storage (CAS). Metadata and layout information are stored separately and utilized during transaction creation. This approach ensures atomic updates and the possibility of rollback, as each transaction creates a new root partition instead of modifying an existing one.
Developers note that the current approach of emulating imperative package management is 'completely senseless' and 'actually introduces more errors than it solves.' Since a new root file system is created for each transaction, future plans include creating a new graph for each transaction and moving away from built-in modifications in favor of a declarative approach similar to Gentoo or Nix.
Another interesting explanation concerns immutability. The creators note that AerynOS is often described as an immutable OS, but 'this is not entirely accurate.' Although each transaction leads to a new tree for /usr and local changes are not saved, the system is not immutable in the sense of being read-only. Future plans include implementing true system immutability without the need for a reboot using erofs and overlayfs.
Currently, AerynOS is actively developing, already releasing ISO images with a GNOME environment, suitable for gaming (with support for NVIDIA drivers, Steam, Flatpak), and has real users who report the system's stability and innovativeness. According to the developers, the project is in the alpha stage and is not without its problems, but it already represents a cohesive system that 'just works.'
Source: opennet.ru
