Les développeurs d'AerynOS, anciennement connu sous le nom de SerpentOS, ont publié un article détaillé présentant les concepts et la mise en œuvre technique du projet, en justifiant les choix architecturaux qui ont été faits. Le chef de projet, Ikey Doherty, souligne qu'AerynOS n'est pas simplement « un autre distribution Linux », mais une plateforme, une fondation et un ensemble d'outils conçus selon une vision claire.
L'idée principale du projet est formulée sous forme de question : « Que se passerait-il si un système d'exploitation agissait comme une infrastructure moderne ? ». AerynOS est présenté comme la réponse à cette question — un système construit de zéro, et non une suite de mutations intégrées à l'intérieur d'une distribution traditionnelle. Le projet s'appuie sur l'expérience des auteurs dans le développement d'autres distributions, y compris Solus et Clear Linux.
Parmi les principales décisions techniques d'AerynOS, on peut citer :
- L'utilisation d'outils LLVM au lieu de GNU, avec libc++ et compiler-rt par défaut. Les développeurs expliquent cette décision non seulement par une préférence pour LLVM, mais par un choix stratégique visant à garantir un meilleur diagnostic, la validité et la portabilité des paquets. Par ailleurs, le système utilise glibc plutôt que musl, ce qui est un choix délibéré en faveur de la compatibilité et des performances.
Comme indiqué dans l'article : « L'avantage de glibc par rapport à musl en termes de performances est bien documenté, surtout pour les charges de travail computationnelles intensives et les applications nécessitant des performances optimales en multithreading ». Les créateurs soulignent que leur objectif est de construire un système fonctionnel et utilisable pour divers scénarios d'application.
- Le concept de « statelessness » (sans état) — il est interdit aux paquets de contenir des fichiers en dehors du répertoire /usr. Comme l'expliquent les développeurs, cette approche incite à établir des valeurs par défaut raisonnables à tous les niveaux et élimine les « horribles conflits de fusion tripartite lors des mises à jour de paquets ». Il n'y a pas de conflits, car tout dans /etc et /var appartient à l'utilisateur, tandis que /usr appartient uniquement au système. Ce concept a été développé à l'époque de Clear Linux et Solus, et a été enrichi dans AerynOS.
- Les mises à jour atomiques - chaque transaction moss est atomique. Le système crée rapidement un nouvel arbre /usr en utilisant des liens durs à partir d'un cache dédupliqué. Après la création et la préparation réussies, le nouvel arbre est échangé atomiquement. En fait, la transaction prête est échangée avec le répertoire réel /usr en utilisant renameat2 avec le drapeau RENAME_EXCHANGE. La mise à jour est soit entièrement effectuée, soit pas du tout, sans états intermédiaires.
- Gestion de démarrage basée sur les projets blsforme et disks-rs. La particularité de l'approche est que le système génère dynamiquement les paramètres pour la ligne de commande du noyau, en lisant les superblocs des dispositifs du système de fichiers racine, c'est pourquoi dans AerynOS il n'y a pas de fichier de configuration contenant le paramètre « root= ». De plus, l'identifiant de transaction moss est encodé dans la ligne de commande du noyau et traité lors du démarrage précoce dans l'initramfs. « En résumé, cela signifie que chaque noyau est correctement synchronisé avec le système de fichiers racine correspondant, et le retour en arrière est peu coûteux, simple et accessible directement depuis le menu de démarrage », expliquent les développeurs. Un autre avantage est l'absence de /etc/default/grub, et si l'ESP est effacé, moss peut le restaurer à partir de zéro.
- Le format de paquet .stone est un format binaire propriétaire avec un en-tête indépendant de la version pour permettre de futures modifications. Chaque paquet .stone contient quatre types spécifiques de données (payload), chacun pouvant évoluer indépendamment grâce à la gestion des versions :
- Charge utile de contenu (Content payload) - un bloc consécutif de données dédupliquées, c'est-à-dire le contenu même des fichiers du paquet.
- Charge utile d'index (Index payload) - contient des décalages pour la charge utile de contenu, indexés par le hachage XXH128 du contenu (il est prévu de passer à Blake3). Cela permet de trouver et d'extraire des données efficacement.
- Charge utile de mise en page (Layout payload) - décrit la mise en page supposée du système de fichiers lors de l'application du paquet, c'est-à-dire où et quels fichiers doivent être installés.
- Charge utile de métadonnées (Metadata payload) - une séquence stricte d'enregistrements de métadonnées typés, tels que le nom du paquet, les fonctionnalités fournies, etc.
La compression de toutes les charges est réalisée à l'aide de Zstd, ce qui assure d'excellentes performances de décompression tout en maintenant un bon taux de compression. Le processus d'installation de .stone diffère radicalement des autres systèmes. Au lieu d'installer directement les fichiers, le package est mis en cache et son contenu est tissé dans un stockage commun avec une adressage basé sur le contenu (CAS). Les métadonnées et les informations sur la mise en page sont conservées séparément et utilisées lors de la création de la transaction. Cette approche garantit l'atomicité des mises à jour et la possibilité de retour en arrière, puisque chaque transaction crée une nouvelle racine de partition au lieu de modifier l'existant.
Les développeurs notent que l'approche actuelle d'émulation de la gestion impérative des packages est « totalement insensée » et « génère en fait plus d'erreurs qu'elle n'en résout ». Puisqu'une nouvelle racine de système de fichiers est créée pour chaque transaction, il est prévu de créer à l'avenir un nouveau graphe pour chaque transaction, abandonner les modifications intégrées au profit d'une approche déclarative, similaire à Gentoo ou Nix.
Une autre explication intéressante concerne l'immutabilité. Les créateurs soulignent que l'on décrit souvent AerynOS comme un OS immuable, mais « ce n'est pas tout à fait vrai ». Bien qu'une transaction mène à un nouvel arbre /usr et que les modifications locales ne sont pas conservées, le système n'est pas immuable au sens d'un accès en lecture seule. À l'avenir, une véritable immutabilité du système sera mise en œuvre sans nécessité de redémarrage en utilisant erofs et overlayfs.
Actuellement, AerynOS est en pleine évolution, publie déjà des images ISO avec l'environnement GNOME, est adapté aux jeux (support des pilotes NVIDIA, Steam, Flatpak), et dispose de véritables utilisateurs qui notent la stabilité et l'innovation du système. Selon les développeurs, le projet est en phase alpha et n'est pas exempt de problèmes, mais il représente déjà un système cohérent qui « fonctionne simplement bien ».
Source : opennet.ru
