AerynOS publie sa première note de développement et de nouvelles images d'installation depuis trois mois, et le point marquant relève de la tuyauterie de paquets plutôt que du bureau. Les dépôts versionnés phase 2 sont déployés, ce qui permet au gestionnaire de paquets moss d'emmener un système à travers un changement cassant de son propre format sur disque au cours d'une mise à jour ordinaire. Pas de réinstallation, pas de bascule manuelle de dépôt, pas de billet demandant aux utilisateurs de lancer trois commandes dans le bon ordre. Le projet résume cela par installer une fois, mettre à jour toujours. Autour, l'image 2026.08 ajoute OpenZFS expérimental pour les disques de données, passe systemd de 257.13 à 261.2 et livre Linux 7.1.5.
The short answer
AerynOS a publié le 2 août sa première note de développement depuis mai, avec une nouvelle image d'installation 2026.08. Les dépôts versionnés phase 2 sont déployés : le gestionnaire de paquets moss franchit un changement cassant de format sur disque lors d'une mise à jour normale, sans migration à réaliser par l'utilisateur. moss gagne aussi le reflink natif sur XFS, avec une approche optionnelle d'image de métadonnées EROFS en développement pour ext4 et f2fs. OpenZFS expérimental arrive pour les disques de données, à côté de btrfs et bcachefs. systemd passe à 261.2 et se découpe en sous paquets, ce qui change les noms d'interfaces réseau après redémarrage.
Demandez à qui a maintenu une distribution ce qu'il redoute, et les migrations de format viendront vite. Le gestionnaire de paquets doit changer sa façon de stocker les choses, toutes les installations existantes sont sur l'ancienne disposition, et les seules issues ont historiquement été un outil de migration que les gens oublient de lancer ou un billet qui commence par le mot "avant". AerynOS a passé trois mois discrets à faire disparaître ce problème, et a publié le résultat le 2 août.
Les dépôts versionnés, et pourquoi la version ennuyeuse compte
La fonction s'appelle dépôts versionnés phase 2, et ce qu'elle apporte, c'est la capacité de modifier le format sur disque de façon cassante tout en faisant arriver les systèmes existants de l'autre côté sans que leurs propriétaires aient à agir.
Le mécanisme est dans le nom. Les dépôts déclarent une version de format, moss connaît les versions qu'il sait lire, et le chemin de mise à niveau au delà d'une frontière fait partie de la synchronisation plutôt que d'une cérémonie séparée. Le projet décrit le résultat comme des utilisateurs qui continuent simplement de mettre à jour leur système et reçoivent les nouveautés dans le flux normal, et parle d'installer une fois, mettre à jour toujours.
Pour une distribution encore en alpha, c'est plus lourd de conséquences qu'il n'y paraît. Un projet incapable de changer son propre format sans échouer des installations soit cesse de le changer, soit accepte que chaque changement lui coûte des utilisateurs. Lever cette contrainte est ce qui laisse le reste de la feuille de route ouvert.
Stockage : reflink sur XFS, EROFS pour les autres
moss compose une racine système à partir de ressources adressées par contenu, ce qui pose une question évidente : ces octets sont ils sur le disque une fois ou deux.
Sur XFS, la réponse est désormais une fois. moss gagne la prise en charge native du reflink, donc le système de fichiers partage des extents entre le magasin et la racine composée au lieu de copier. C'est le même tour dont bénéficient les utilisateurs de btrfs, étendu à un système de fichiers que beaucoup exploitent déjà.
Pour ext4 et f2fs, où le reflink n'existe pas, le projet développe une approche optionnelle d'image de métadonnées EROFS. Mécanisme différent, même objectif : cesser de payer deux fois des données identiques. À noter, c'est décrit comme en développement et non livré, donc les utilisateurs d'ext4 ne l'ont pas dans 2026.08.
Le reste de l'image
La prise en charge expérimentale d'OpenZFS arrive pour les disques de données, aux côtés de btrfs et bcachefs. La limitation est délibérée et mérite d'être respectée : c'est pour des pools que vous rattachez, pas pour la racine d'un système qui se compose lui même de façon atomique.
systemd passe de 257.13 à 261.2 et se retrouve empaqueté en sous paquets distincts, ce qui permet à une installation minimale d'en laisser des morceaux.
Côté noyaux, les branches stable et gaming portent Linux 7.1.5 et la branche LTS porte 6.18.40. Le pilote NVIDIA est en 610.43.03 avec une meilleure prise en charge du DLSS. Ailleurs dans le jeu de paquets : COSMIC 1.5.0, KDE Plasma 6.7.3, Mesa 26.1.6, Firefox 153.0.1, PHP 8.5.9, QEMU 11.0.3 et Wine 11.14.
L'infrastructure progresse aussi. CDN77 parraine désormais la diffusion de contenu dans 130 pays, ce que le projet rattache à son intérêt pour la souveraineté numérique européenne.
Le point à vérifier avant de redémarrer
Un changement caché dans le saut de version de systemd va piéger quelqu'un : les noms d'interfaces réseau.
Le passage à systemd 261.2 apporte un changement de schéma de nommage, et une interface qui s'appelait eth0 peut revenir en enp0 après le redémarrage. Tout ce qui est épinglé à l'ancien nom part avec. Les règles de pare feu qui nomment une interface, la configuration réseau statique, les sondes de supervision, un script qui analyse la sortie de ip à la recherche d'un périphérique précis.
Le mode de défaillance est désagréable justement parce qu'il reste invisible tant que la machine n'est pas déjà remontée avec une interface que rien dans votre configuration ne mentionne. Regardez ce que vous avez épinglé avant de redémarrer, pas après.
Où le projet dit aller
La note est franche : ces derniers mois sont allés aux fondations plutôt qu'aux fonctions, outillage de construction et d'empaquetage, infrastructure, travail incrémental sur Wayland et le matériel. La phrase intéressante concerne la suite. Le projet indique qu'AerynOS a été tenu délibérément en laisse courte, et que maintenant que la capacité à livrer des mises à jour transparentes est acquise, il passe à un espace plus ouvert et collaboratif.
Cet ordre se défend. Ouvrir un projet aux contributeurs avant de savoir livrer un changement de format sans casser leurs machines génère surtout du travail pour tout le monde. Le faire après, c'est ainsi qu'une distribution grandit.
Cela reste une alpha, et rien ici ne change ce point. Mais une alpha qui a résolu son propre problème de mise à niveau est nettement mieux placée qu'une alpha qui ne l'a pas fait.
Sources et pour aller plus loin
- AerynOS : solid foundations are leading to expanding horizons
- Phoronix : AerynOS publie sa première note de développement et de nouvelles images en trois mois
- Blog du projet AerynOS
- Notre guide pour choisir une distribution Linux en 2026
Questions fréquentes
Quel problème les dépôts versionnés résolvent ils vraiment ?
Tout gestionnaire de paquets finit par devoir changer le format des données qu'il stocke sur disque, et ce changement est normalement le moment où une distribution doit demander quelque chose à ses utilisateurs. Réinstaller, lancer un outil de migration, éditer un fichier de dépôt à la main, ou attendre une mise à jour spéciale à appliquer avant toutes les autres. Les dépôts versionnés phase 2 permettent à moss de reconnaître la version de format que parle un dépôt et de se mettre à niveau au delà d'une frontière cassante dans le cadre d'une synchronisation normale. Côté utilisateur, l'opération consiste à ce qu'il ne se passe rien : vous mettez à jour, et vous êtes sur le nouveau format. Pour une distribution encore en alpha, pouvoir casser son propre format sans casser chaque installation fait la différence entre itérer et se figer.
Qu'est ce que moss et en quoi diffère t il d'un gestionnaire classique ?
moss est le gestionnaire de paquets qu'AerynOS construit depuis 2020, et il est adressé par contenu plutôt que fondé sur la copie de fichiers. Les paquets sont stockés comme des ressources hachées et une racine système est composée à partir d'elles, ce qui rend une transaction atomique et un retour arrière peu coûteux. Dans cette mise à jour, moss gagne la prise en charge native du reflink sur XFS, ce qui laisse le système de fichiers partager des extents entre le magasin et la racine composée au lieu de dupliquer les données, et une approche optionnelle d'image de métadonnées EROFS est en développement pour les utilisateurs d'ext4 et f2fs qui n'ont pas de reflink. C'est le même problème résolu deux fois pour des systèmes de fichiers différents : ne pas payer deux fois les mêmes octets sur disque.
La prise en charge d'OpenZFS est elle utilisable, et pour quoi ?
Elle est étiquetée expérimentale et limitée aux disques de données, aux côtés des options btrfs et bcachefs déjà prises en charge. Cette limitation est le détail important. Utiliser OpenZFS pour un pool de données rattaché à une machine AerynOS relève d'un profil de risque très différent de son usage comme système de fichiers racine d'une distribution qui compose ses racines de façon atomique, et le projet propose le premier, pas le second. Voyez le comme un moyen d'amener un pool existant, pas comme une invitation à reconstruire votre racine.
Qu'est ce qui casse lors de la mise à jour vers 2026.08 ?
Une chose à connaître avant de redémarrer : les noms d'interfaces réseau changent. Le passage de systemd de 257.13 à 261.2 apporte un changement de schéma de nommage, donc une interface qui s'appelait eth0 peut revenir en enp0 après le redémarrage. Si vous avez quoi que ce soit épinglé à un nom d'interface, règles de pare feu, configuration statique, script qui analyse la sortie de ip, c'est là que cela mordra. Vérifiez avant de redémarrer plutôt qu'après, parce que la machine remontera avec une interface que votre configuration ne mentionne pas. systemd est par ailleurs désormais découpé en sous paquets, donc une installation minimale peut en laisser des morceaux de côté.
AerynOS est il prêt pour la production ?
Non, et le projet ne le prétend pas. AerynOS est une distribution alpha, et cette mise à jour dit explicitement que l'effort des derniers mois est allé dans l'outillage de construction, l'empaquetage et l'infrastructure plutôt que dans des fonctions visibles. Ce qu'elle signale, c'est que les fondations sont jugées assez stables pour s'ouvrir : le billet indique que le projet a été tenu en laisse courte et se dirige délibérément vers un espace plus ouvert et collaboratif. C'est un bon moment pour l'essayer sur une machine de rechange, contribuer à l'empaquetage, ou l'observer. Ce n'est pas une raison de mettre quoi que ce soit d'important dessus lundi.