Das Konzept des AerynOS-Distributions wurde mit einer Begründung der architektonischen Entscheidungen vorgestellt.

Die Entwickler von AerynOS, früher bekannt als SerpentOS, haben einen ausführlichen Artikel veröffentlicht, in dem die Details des Konzepts und der technischen Umsetzung des Projekts mit Begründung der getroffenen architektonischen Entscheidungen erläutert werden. Projektleiter Ikey Doherty betont, dass AerynOS nicht einfach "noch eine Linux-Distribution" ist, sondern eine Plattform, ein Fundament und ein Werkzeugset, das nach einer klaren Vision entwickelt wurde.

Die Hauptidee des Projekts wird in Form einer Frage formuliert: "Was wäre, wenn das Betriebssystem sich wie moderne Infrastruktur verhalten würde?" AerynOS wird als Antwort auf diese Frage präsentiert – ein System, das von Grund auf neu entwickelt wurde und sich nicht an das traditionelle Modell von eingebetteten Mutationen innerhalb einer Distribution hält. Das Projekt stützt sich auf die Erfahrungen der Autoren in der Entwicklung anderer Distributionen, einschließlich Solus und Clear Linux.

Zu den wichtigsten technischen Entscheidungen von AerynOS gehören:

• Die Verwendung des LLVM-Tools anstelle von GNU, mit libc++ und compiler-rt als Standard. Die Entwickler begründen diese Entscheidung nicht nur mit einer Präferenz für LLVM, sondern als strategische Wahl, um eine bessere Diagnose, Korrektheit und Portabilität der Pakete zu gewährleisten. Dabei kommt glibc anstelle von musl zum Einsatz, was eine bewusste Entscheidung zugunsten von Kompatibilität und Leistung ist.

  Wie im Artikel angegeben: "Der Leistungsunterschied zwischen glibc und musl ist gut dokumentiert, insbesondere für rechenintensive Arbeitslasten und Anwendungen, die optimale Multithreading-Leistung erfordern." Die Entwickler betonen, dass es ihr Ziel ist, ein funktionierendes, gebrauchsfähiges System für eine Vielzahl von Anwendungsszenarien zu schaffen.

• Das Konzept der „Statelessness“ (Zustandslosigkeit) verbietet es, dass Pakete irgendwelche Dateien außerhalb des Verzeichnisses /usr enthalten. Wie die Entwickler erklären, sorgt dieser Ansatz dafür, dass auf allen Ebenen angemessene Standardeinstellungen gesetzt werden und „schreckliche Merge-Konflikte beim Aktualisieren von Paketen“ vermieden werden. Es gibt keine Konflikte, weil alles in /etc und /var dem Benutzer gehört, während /usr ausschließlich dem System gehört. Dieses Konzept wurde in der Zeit von Clear Linux und Solus entwickelt und fand in AerynOS weiterführende Anwendung.
• Atomare Updates – jede Transaktion von moss ist atomar. Das System erstellt schnell einen neuen Baum für /usr unter Verwendung harter Links aus einem deduplizierten Cache. Nach erfolgreicher Erstellung und Vorbereitung wird der neue Baum atomar ersetzt. Die tatsächlich vorbereitete Transaktion wird mit dem realen Verzeichnis /usr mittels renameat2 mit dem Flag RENAME_EXCHANGE ausgetauscht. Entweder wird das Update vollständig durchgeführt oder gar nicht, ohne Zwischenzustände.
• Die projektbasierte Lastverwaltung von blsforme und disks-rs zeichnet sich durch einen dynamischen Ansatz aus, bei dem das System die Parameter für die Kernel-Befehlszeile basierend auf den Superblöcken der Root-Dateisysteme erstellt. Daher gibt es in AerynOS keine Konfigurationsdatei, die den Parameter „root=“ enthält. Darüber hinaus wird die Transaktions-ID von moss in der Kernel-Befehlszeile kodiert und während des frühen Bootvorgangs im initramfs verarbeitet. "Kurz gesagt bedeutet das, dass jeder Kernel korrekt mit dem entsprechenden Root-Dateisystem synchronisiert ist, und ein Rollback einfach, kostengünstig und direkt über das Bootmenü verfügbar ist", erklären die Entwickler. Ein weiterer Vorteil ist das Fehlen von /etc/default/grub; falls die ESP gelöscht wird, kann moss sie von Grund auf wiederherstellen.
• Das Paketformat .stone ist ein proprietäres binäres Paketformat mit einem versionsunabhängigen Header, um zukünftige Änderungen zu ermöglichen. Jedes .stone-Paket enthält vier spezifische Datentypen (Payload), von denen jeder unabhängig weiterentwickelt werden kann, dank der Versionierung:
  • Content-Payload — ein zusammenhängender Block deduplizierter Daten, das heißt, der eigentliche Inhalt der Paketdateien.
  • Index-Payload — enthältOffsets für den Content-Payload, die basierend auf dem Hash XXH128 des Inhalts indexiert sind (ein Umstieg auf Blake3 ist geplant). Dies ermöglicht eine effiziente Auffindung und Extraktion von Daten.
  • Layout-Payload — beschreibt das angegebene Layout des Dateisystems bei der Anwendung des Pakets, das heißt, wo und welche Dateien installiert werden sollen.
  • Metadaten-Payload — eine Reihe streng typisierter, gekennzeichneter Metadatensätze, wie z. B. der Paketname, die bereitgestellten Funktionen usw.

Die Kompression aller Lasten erfolgt durch Zstd, was eine hervorragende Dekompressionsleistung bei gutem Kompressionsverhältnis gewährleistet. Der "Installations"-Prozess von .stone unterscheidet sich grundlegend von anderen Systemen. Anstatt die Dateien direkt zu installieren, wird das Paket zwischengespeichert, und dessen Inhalt wird in einem gemeinsamen Speicher mit inhaltsadressierter Struktur (CAS) eingewebt. Metadaten und Layoutinformationen werden separat gespeichert und bei der Transaktionsstellung verwendet. Dieser Ansatz gewährleistet die Atomarität der Updates und die Möglichkeit des Rollbacks, da jede Transaktion einen neuen Root-Bereich erstellt, anstatt einen bestehenden zu modifizieren.

Entwickler bemerken, dass der aktuelle Ansatz zur Emulation der imperativen Paketverwaltung "völlig sinnlos" ist und "tatsächlich mehr Fehler einführt, als er löst". Da für jede Transaktion ein neues Root-Dateisystem erstellt wird, wird in Zukunft die Schaffung eines neuen Graphen für jede Transaktion angestrebt, um von eingebauten Änderungen zu einem deklarativen Ansatz überzugehen, ähnlich dem von Gentoo oder Nix.

Eine weitere interessante Anmerkung betrifft die Unveränderlichkeit (Immutability). Die Entwickler weisen darauf hin, dass AerynOS oft als unveränderliches Betriebssystem beschrieben wird, was jedoch "nicht ganz korrekt ist". Obwohl jede Transaktion zu einem neuen Baum /usr führt und lokale Änderungen nicht gespeichert werden, ist das System nicht im Sinne von nur schreibgeschützt unveränderlich. Zukünftig wird eine echte Unveränderlichkeit des Systems ohne die Notwendigkeit eines Neustarts mithilfe von erofs und overlayfs realisiert.

Derzeit entwickelt sich AerynOS aktiv weiter, veröffentlicht bereits ISO-Images mit der GNOME-Oberfläche, ist für Spiele geeignet (unterstützt NVIDIA-Treiber, Steam, Flatpak) und hat echte Nutzer, die die Stabilität und Innovationskraft des Systems loben. Laut den Entwicklern befindet sich das Projekt in der Alpha-Phase und ist nicht ohne Probleme, stellt jedoch bereits ein vollständiges System dar, das "einfach funktioniert".

Quelle: opennet.ru