Die Konzeption des Distributionssystems AerynOS wurde mit Begründungen für die architektonischen Entscheidungen vorgestellt.

Die Entwickler von AerynOS, früher bekannt als SerpentOS, haben einen ausführlichen Artikel veröffentlicht, der Details zur Konzeptualisierung und technischen Umsetzung des Projekts sowie die Gründe für die architektonischen Entscheidungen beschreibt. Der Projektleiter Ikey Doherty betont, dass AerynOS nicht nur „ein weiterer Linux-Distrikt“ ist, sondern eine Plattform, ein Fundament und ein Set von Werkzeugen, die auf einer klaren Vision basieren.

Die Grundidee des Projekts wird in Form einer Frage formuliert: „Was wäre, wenn das Betriebssystem sich wie moderne Infrastruktur verhält?“. AerynOS wird als Antwort auf diese Frage präsentiert – ein System, das von Grund auf neu entwickelt wurde und nicht das traditionelle Modell von eingebetteten Mutationen innerhalb eines Distrikts verfolgt. Das Projekt stützt sich auf die Erfahrungen der Autoren bei der Entwicklung anderer Distrikte, einschließlich Solus und Clear Linux.

Zu den wichtigsten technischen Entscheidungen von AerynOS gehören:

• Die Verwendung des LLVM-Toolsets anstelle von GNU, mit der standardmäßigen Anwendung von libc++ und compiler-rt. Die Entwickler erklären diese Entscheidung nicht nur als Vorliebe für LLVM, sondern als strategische Wahl zur Verwendung qualitativ hochwertigerer Diagnosen, zur Gewährleistung der Korrektheit und Portabilität der Pakete. Dabei verwendet das System glibc anstelle von musl, eine bewusste Entscheidung zugunsten von Kompatibilität und Leistung.

  Wie im Artikel angegeben: „Der Vorteil von glibc gegenüber musl in Bezug auf die Leistung ist gut dokumentiert, insbesondere für rechenintensive Arbeitslasten und Anwendungen, die auf optimale Multithreading-Leistung angewiesen sind“. Die Entwickler betonen, dass ihr Ziel darin besteht, ein funktionsfähiges, benutzbares System für eine Vielzahl von Anwendungsszenarien zu schaffen.

• Das Konzept der „Statelessness“ (Zustandslosigkeit) verbietet es Paketen, irgendwelche Dateien außerhalb des Verzeichnisses /usr zu enthalten. Wie die Entwickler erläutern, zwingt dieser Ansatz dazu, an allen Ebenen vernünftige Standardwerte zu gewährleisten und „schreckliche Konflikte beim dreiseitigen Mergen bei der Aktualisierung von Paketen“ zu vermeiden. Konflikte gibt es nicht, weil alles in /etc und /var dem Benutzer gehört, während /usr ausschließlich dem System gehört. Das Konzept wurde in der Zeit von Clear Linux und Solus entwickelt und fand in AerynOS eine weitere Ausgestaltung.
• Atomare Updates – jede moss-Transaktion ist atomar. Das System erstellt schnell einen neuen Baum /usr mit Hilfe von Hardlinks aus dem deduplizierten Cache. Nach erfolgreicher Erstellung und Vorbereitung wird der neue Baum atomar ersetzt. Die tatsächlich vorbereitete Transaktion wird mit dem realen Verzeichnis /usr unter Verwendung von renameat2 mit dem Flag RENAME_EXCHANGE getauscht. Das Update wird entweder vollständig durchgeführt oder gar nicht, ohne Zwischenzustände.
• Das management der belastung basiert auf blsforme und disks-rs. Besonderheit des Ansatzes ist, dass das System dynamisch Parameter für die Kernel-Befehlszeile erstellt, indem es die Superblöcke der Geräte des Wurzel-Dateisystems ausliest, weshalb es in AerynOS keine Konfigurationsdatei gibt, die den Parameter „root=” enthält. Darüber hinaus wird die moss-Transaktions-ID in der Kernel-Befehlszeile kodiert und während des frühen Ladevorgangs in initramfs verarbeitet. „Kurz gesagt, das bedeutet, dass jeder Kernel korrekt mit dem entsprechenden Wurzel-Dateisystem synchronisiert ist und ein Rollback kostengünstig, einfach und direkt aus dem Boot-Menü möglich ist“, erklären die Entwickler. Ein weiterer Vorteil ist das Fehlen von /etc/default/grub, und wenn die ESP gelöscht wird, kann moss sie von Grund auf neu herstellen.
• .stone-Paketformat – ein proprietäres binäres Paketformat mit einem versionsunabhängigen Header zur Gewährleistung zukünftiger Änderungen. Jedes .stone-Paket enthält vier spezifische Datentypen (Payload), von denen jeder unabhängig durch Versionierung erweitert werden kann:
  • Content Payload – ein zusammenhängender Block deduplizierter Daten, also der eigentliche Inhalt der Paketdateien.
  • Index Payload – enthält Offsets für die Content Payload, indexiert nach dem XXH128-Hash des Inhalts (ein Übergang zu Blake3 ist geplant). Dies ermöglicht das effiziente Finden und Abrufen von Daten.
  • Layout Payload – beschreibt das geplante Layout des Dateisystems bei der Anwendung des Pakets, also wo und welche Dateien installiert werden sollen.
  • Metadata Payload – eine Abfolge von streng typisierten, gekennzeichneten Metadaten-Einträgen wie Paketname, bereitgestellte Funktionen usw.

Die Kompression aller Lasten erfolgt über Zstd, was hervorragende Entpackungsleistung bei gleichzeitig gutem Kompressionsverhältnis gewährleistet. Der Prozess der "Installation" .stone unterscheidet sich grundlegend von anderen Systemen. Anstatt Dateien direkt zu installieren, wird das Paket zwischengespeichert, und sein Inhalt wird in einen gemeinsamen Speicher mit adressierungsbasierter Inhaltsadressierung (CAS) integriert. Metadaten und Layoutinformationen werden separat gespeichert und bei der Erstellung von Transaktionen verwendet. Dieser Ansatz gewährleistet die Atomarität von Updates und die Möglichkeit der Rücksetzung, da jede Transaktion einen neuen Wurzelbereich erstellt, anstatt den bestehenden zu modifizieren.

Entwickler weisen darauf hin, 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 eine neue Root-Dateisystemstruktur erstellt wird, ist in Zukunft geplant, einen neuen Graphen für jede Transaktion zu erstellen, auf eingebaute Änderungen zu verzichten und einen deklarativen Ansatz ähnlich wie Gentoo oder Nix zu verfolgen.

Eine weitere interessante Erläuterung betrifft die Unveränderlichkeit (Immutability). Die Entwickler stellen fest, dass AerynOS oft als unveränderliches OS beschrieben wird, aber "das ist nicht ganz richtig". Obwohl jede Transaktion zu einem neuen Baum von /usr führt und lokale Änderungen nicht gespeichert werden, ist das System nicht unveränderlich im Sinne des Nur-Lese-Zugriffs. In Zukunft wird die Implementierung einer echten Unveränderlichkeit des Systems ohne Neustart unter Verwendung von erofs und overlayfs angestrebt.

Derzeit wird AerynOS aktiv entwickelt, bietet bereits ISO-Abbilder mit der GNOME-Umgebung, ist spielgeeignet (unterstützt NVIDIA-Treiber, Steam, Flatpak) und hat echte Nutzer, die die Stabilität und Innovationskraft des Systems hervorheben. Laut den Entwicklern befindet sich das Projekt in der Alpha-Phase und hat einige Probleme, ist jedoch bereits ein zusammenhängendes System, das "einfach funktioniert".

Quelle: opennet.ru