{"id":125413,"date":"2025-05-22T15:05:15","date_gmt":"2025-05-22T13:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij"},"modified":"2025-05-22T15:05:15","modified_gmt":"2025-05-22T13:05:15","slug":"predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","title":{"rendered":"The concept of the AerynOS distribution has been presented along with the reasoning behind its architectural decisions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
The developers of AerynOS, formerly known as SerpentOS, have published a detailed article revealing the concepts and technical implementation of the project, along with justifications for the architectural decisions made. Project leader Ikey Doherty emphasizes that AerynOS is not just 'another Linux distribution', but rather a platform, foundation, and set of tools created with a clear vision in mind. <\/p>\n
The main idea of the project is formulated as a question: 'What if an operating system behaves like modern infrastructure?'. AerynOS is presented as the answer to this question \u2014 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. <\/p>\n
Among the key technical solutions of AerynOS are: <\/p>\n
\n
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.\n
As stated in the article: 'The performance advantage of glibc over musl is well documented, especially for compute-intensive workloads and applications requiring optimal multi-threading performance.' The creators emphasize that their goal is to build a functional and usable system for a variety of application scenarios. <\/p>\n
The concept of 'statelessness' \u2014 packages are prohibited from containing any files outside the \/usr directory. As the developers explain, this approach ensures reasonable defaults at all levels and eliminates 'terrible three-way merge conflicts during package updates'. There are no conflicts because everything in \/etc and \/var belongs to the user, while \/usr is solely for the system. This concept was developed during the times of Clear Linux and Solus, and has been further enhanced in AerynOS.\n
Atomic updates \u2014 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 then exchanged with the real \/usr directory using renameat2 with the RENAME_EXCHANGE flag. The update either fully executes or does not occur at all, with no intermediate states.\n
Project-based boot management for blsforme and disks-rs. The hallmark of this approach is that the system dynamically forms parameters for the kernel command line by reading the superblocks of the root filesystem devices, which is why AerynOS does not have a configuration file containing the 'root=' parameter. Moreover, the moss transaction identifier 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 its corresponding root filesystem, and rollback is cheap, simple, and available right from the boot menu,' explain the developers. Another advantage is the absence of \/etc\/default\/grub, and if the ESP is erased, moss can restore it from scratch.\n
.stone package format \u2014 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 thanks to versioning:\n
\n
Content payload \u2014 a sequential block of deduplicated data, namely the actual content of the package files.\n
Index payload \u2014 contains offsets for the content payload, indexed by the XXH128 hash of the content (a transition to Blake3 is planned). This allows for efficient data retrieval and extraction.\n
Layout payload \u2014 describes the intended layout of the filesystem when applying the package, that is, where and what files should be installed.\n
Metadata payload \u2014 a sequence of strictly typed, labeled metadata records, such as package name, provided capabilities, etc. <\/ul>\n<\/ul>\n
Compression of all workloads is performed using Zstd, which ensures excellent decompression performance while maintaining a good compression ratio. The process of 'installation' of .stone is fundamentally different from other systems. Instead of directly installing files, the package is cached, and its contents are woven into a shared repository with content-addressable storage (CAS). Metadata and layout information are stored separately and utilized when creating a transaction. This approach ensures atomic updates and rollback capability, as each transaction creates a new root partition rather than modifying the existing one. <\/p>\n
Developers note that the current approach of emulating imperative package management is 'utterly senseless' and 'actually introduces more errors than it resolves.' Since a new root filesystem is created for each transaction, there are plans to develop a new graph for each transaction in the future, abandoning built-in changes in favor of a declarative approach similar to Gentoo or Nix. <\/p>\n
Another interesting clarification concerns immutability. The creators point out that AerynOS is often described as an immutable OS, but 'that's not quite accurate.' While each transaction leads to a new \/usr tree and local changes are not preserved, the system is not immutable in the sense of being read-only. There are plans for true immutability of the system in the future without the need for a reboot, utilizing erofs and overlayfs. <\/p>\n
Currently, AerynOS is actively developing, already releasing ISO images with a GNOME environment, suitable for gaming (support for NVIDIA drivers, Steam, Flatpak), and has real users noting the stability and innovation of the system. According to the developers, the project is in alpha stage and is not without issues, but already represents a cohesive system that 'just works.' \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"