{"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\/fr\/blog\/news\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","title":{"rendered":"La conception de la distribution AerynOS a \u00e9t\u00e9 pr\u00e9sent\u00e9e avec des justifications architecturales","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Les d\u00e9veloppeurs d'AerynOS, anciennement connu sous le nom de SerpentOS, ont publi\u00e9 un article d\u00e9taill\u00e9 exposant les concepts et la mise en \u0153uvre technique du projet, justifiant les choix architecturaux faits. Le chef de projet Ikey Doherty souligne qu'AerynOS n'est pas simplement un \u00ab autre syst\u00e8me d'exploitation Linux \u00bb, mais une plateforme, une fondation et un ensemble d'outils cr\u00e9\u00e9s selon une vision claire. <\/p>\n
L'id\u00e9e principale du projet est formul\u00e9e sous la forme d'une question : \u00ab Que se passerait-il si un syst\u00e8me d'exploitation se comportait comme une infrastructure moderne ? \u00bb. AerynOS se pr\u00e9sente comme la r\u00e9ponse \u00e0 cette question : un syst\u00e8me construit de z\u00e9ro, et non une it\u00e9ration traditionnelle de mutations int\u00e9gr\u00e9es dans un autre syst\u00e8me d'exploitation. Le projet s'appuie sur l'exp\u00e9rience des auteurs dans le d\u00e9veloppement d'autres distributions, y compris Solus et Clear Linux. <\/p>\n
Parmi les principales d\u00e9cisions techniques d'AerynOS, on peut citer : <\/p>\n
\n
L'utilisation d'outils LLVM au lieu de GNU, avec libc++ et compiler-rt par d\u00e9faut. Les d\u00e9veloppeurs expliquent cette d\u00e9cision non seulement par une pr\u00e9f\u00e9rence pour LLVM, mais par un choix strat\u00e9gique visant \u00e0 garantir un meilleur diagnostic, la validit\u00e9 et la portabilit\u00e9 des paquets. Par ailleurs, le syst\u00e8me utilise glibc plut\u00f4t que musl, ce qui est un choix d\u00e9lib\u00e9r\u00e9 en faveur de la compatibilit\u00e9 et des performances.\n
Comme indiqu\u00e9 dans l'article : \u00ab L'avantage de glibc par rapport \u00e0 musl en termes de performance est bien document\u00e9, notamment pour les charges de travail intensives en calcul et les applications n\u00e9cessitant une performance optimale du multithreading \u00bb. Les cr\u00e9ateurs soulignent que leur objectif est de construire un syst\u00e8me fonctionnel et utilisable pour de nombreux sc\u00e9narios d'application. <\/p>\n
Le concept de \u00ab statelessness \u00bb (sans \u00e9tat) interdit aux paquets de contenir des fichiers en dehors du r\u00e9pertoire \/usr. Comme l'expliquent les d\u00e9veloppeurs, cette approche oblige \u00e0 garantir des valeurs par d\u00e9faut raisonnables \u00e0 tous les niveaux et \u00e9limine les \u00ab horribles conflits de fusion \u00e0 trois lors des mises \u00e0 jour de paquets \u00bb. Il n'y a pas de conflits, car tout dans \/etc et \/var appartient \u00e0 l'utilisateur, tandis que \/usr appartient uniquement au syst\u00e8me. Ce concept a \u00e9t\u00e9 d\u00e9velopp\u00e9 \u00e0 l'\u00e9poque de Clear Linux et Solus, et il a \u00e9t\u00e9 pouss\u00e9 plus loin dans AerynOS.\n
Les mises \u00e0 jour atomiques : chaque transaction moss est atomique. Le syst\u00e8me cr\u00e9e rapidement un nouvel arbre \/usr \u00e0 l'aide de liens durs depuis un cache d\u00e9dupliqu\u00e9. Apr\u00e8s une cr\u00e9ation et une pr\u00e9paration r\u00e9ussies, le nouvel arbre est \u00e9chang\u00e9 de mani\u00e8re atomique. La transaction pr\u00e9par\u00e9e est \u00e9chang\u00e9e avec le v\u00e9ritable r\u00e9pertoire \/usr en utilisant renameat2 avec le flag RENAME_EXCHANGE. La mise \u00e0 jour est soit enti\u00e8rement effectu\u00e9e, soit pas du tout, sans \u00e9tat interm\u00e9diaire.\n
La gestion des charges bas\u00e9e sur les projets blsforme et disks-rs. La particularit\u00e9 de l'approche est que le syst\u00e8me cr\u00e9e dynamiquement les param\u00e8tres pour la ligne de commande du noyau, en lisant les superblocs des p\u00e9riph\u00e9riques du syst\u00e8me de fichiers racine, c'est pourquoi dans AerynOS, il n'y a pas de fichier de configuration contenant le param\u00e8tre \u00ab root= \u00bb. De plus, l'identifiant de transaction moss est encod\u00e9 dans la ligne de commande du noyau et est trait\u00e9 pendant le d\u00e9marrage pr\u00e9coce dans initramfs. \u00ab En bref, cela signifie que chaque noyau est correctement synchronis\u00e9 avec le syst\u00e8me de fichiers racine correspondant, et le retour en arri\u00e8re est peu co\u00fbteux, simple et accessible directement depuis le menu de d\u00e9marrage \u00bb, expliquent les d\u00e9veloppeurs. Un autre avantage est l'absence de \/etc\/default\/grub, et si l'ESP est effac\u00e9, moss peut le restaurer depuis z\u00e9ro.\n
Le format de paquet .stone est un format binaire propri\u00e9taire avec un en-t\u00eate agnostique par rapport aux versions pour permettre des modifications futures. Chaque paquet .stone contient quatre types de donn\u00e9es sp\u00e9cifiques (payload), chacun pouvant \u00e9voluer ind\u00e9pendamment gr\u00e2ce \u00e0 la version :\n
\n
Charge utile de contenu (Content payload) \u2014 un bloc s\u00e9quentiel de donn\u00e9es d\u00e9dupliqu\u00e9es, c'est-\u00e0-dire le contenu m\u00eame des fichiers du paquet.\n
Charge utile d'index (Index payload) \u2014 contient des d\u00e9calages pour la charge utile de contenu, index\u00e9s par le hachage XXH128 du contenu (la transition vers Blake3 est pr\u00e9vue). Cela permet de trouver et d'extraire les donn\u00e9es efficacement.\n
Charge utile de mise en page (Layout payload) \u2014 d\u00e9crit la mise en page pr\u00e9vue du syst\u00e8me de fichiers lors de l'application du paquet, c'est-\u00e0-dire o\u00f9 et quels fichiers doivent \u00eatre install\u00e9s.\n
M\u00e9tadonn\u00e9es (Metadata payload) \u2014 une s\u00e9quence d'enregistrements de m\u00e9tadonn\u00e9es fortement typ\u00e9s et marqu\u00e9s, tels que le nom du paquet, les capacit\u00e9s fournies, etc. <\/ul>\n<\/ul>\n
La compression de toutes les charges s'effectue gr\u00e2ce \u00e0 Zstd, ce qui assure d'excellentes performances de d\u00e9compression tout en maintenant un bon taux de compression. Le processus d'\u00ab installation \u00bb de .stone diff\u00e8re radicalement des autres syst\u00e8mes. Au lieu d'installer directement les fichiers, le paquet est mis en cache et son contenu est tiss\u00e9 dans un espace de stockage commun avec une adressage bas\u00e9 sur le contenu (CAS). Les m\u00e9tadonn\u00e9es et les informations sur la mise en page sont stock\u00e9es s\u00e9par\u00e9ment et utilis\u00e9es lors de la cr\u00e9ation de la transaction. Cette approche garantit l'atomicit\u00e9 des mises \u00e0 jour et la possibilit\u00e9 de revenir en arri\u00e8re, car chaque transaction cr\u00e9e une nouvelle partition racine au lieu de modifier l'existante. <\/p>\n
Les d\u00e9veloppeurs soulignent que l'approche actuelle d'\u00e9mulation de la gestion imp\u00e9rative des paquets est \u00ab compl\u00e8tement absurde \u00bb et \u00ab entra\u00eene en fait plus d'erreurs qu'elle n'en r\u00e9sout \u00bb. Puisqu'une nouvelle racine de syst\u00e8me de fichiers est cr\u00e9\u00e9e pour chaque transaction, il est pr\u00e9vu \u00e0 l'avenir de cr\u00e9er un nouveau graphe pour chaque transaction, en renon\u00e7ant aux modifications int\u00e9gr\u00e9es au profit d'une approche d\u00e9clarative, similaire \u00e0 Gentoo ou Nix. <\/p>\n
Une autre explication int\u00e9ressante concerne l'immuabilit\u00e9. Les cr\u00e9ateurs notent qu'AerynOS est souvent d\u00e9crit comme un OS immuable, mais \u00ab ce n'est pas tout \u00e0 fait juste \u00bb. Bien que chaque transaction entra\u00eene un nouvel arbre \/usr et que les modifications locales ne sont pas conserv\u00e9es, le syst\u00e8me n'est pas immuable dans le sens d'un acc\u00e8s en lecture seule. \u00c0 l'avenir, il est pr\u00e9vu de mettre en \u0153uvre une v\u00e9ritable immuabilit\u00e9 du syst\u00e8me sans avoir besoin de red\u00e9marrer, en utilisant erofs et overlayfs. <\/p>\n
Actuellement, AerynOS est en plein d\u00e9veloppement, avec des images ISO d\u00e9j\u00e0 disponibles avec l'environnement GNOME, adapt\u00e9 aux jeux (support des pilotes NVIDIA, Steam, Flatpak), et dispose de v\u00e9ritables utilisateurs signalant la stabilit\u00e9 et l'innovation du syst\u00e8me. Selon les d\u00e9veloppeurs, le projet est en phase alpha et n'est pas exempt de probl\u00e8mes, mais il repr\u00e9sente d\u00e9j\u00e0 un syst\u00e8me coh\u00e9rent qui \u00ab fonctionne tout simplement \u00bb. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"