Mon OS est atomique

Écrit par Laurent Meunier

Avec les sorties récentes de Fedora Silverblue en version 42 et de NixOS en version 25.05, c’est l’occasion d’évoquer rapidement la notion d’atomicité pour une distribution Linux.

L’atomicité d’un OS est liée aux mises à jour de celui-ci. Un OS dit « atomique » réalise ses mises à jour de manière transactionnelle : soit la mise à jour est réalisée entièrement, soit rien n’a été modifié. Ce principe est proche d’une transaction SQL avec commit et rollback.

Le principal avantage des mises à jour atomiques est la garantie d’avoir toujours un système fonctionnel, même si un problème survient pendant une opération. Dans le pire des cas, la mise à jour n’est pas faite et le système n’a pas été modifié. Il est impossible de se retrouver dans un état intermédiaire qui pourrait engendrer une instabilité du système.

L’atomicité est souvent liée à l’immutabilité de l’OS.

Côté Fedora Silverblue, l’atomicité est mise en place via l’utilisation d’ostree et rpm-ostree. ostree permet d’installer et de réaliser les mises à jour de l’OS de manière atomique. Tandis que rpm-ostree permet de personnaliser son OS en installant des paquets RPM en tant que « layer » dans une image ostree. Les utilisateurs ont ensuite la possibilité d’installer eux-mêmes des applications via Flatpak.

On obtient ainsi une base robuste (ostree/rpm-ostree) et des applications utilisateurs dans leurs dernières versions (Flatpak).

Côté NixOS, le paradigme est différent. NixOS utilise Nix, un gestionnaire de paquet basé sur un langage fonctionnel. L’utilisation de Nix permet l’atomicité des mises à jour. Chaque mise à jour construit un nouveau système complet (appelé « génération ») dans le « store » Nix et ajoute une nouvelle entrée dans le gestionnaire de démarrage (généralement GRUB) qui pointe vers le nouveau système fraîchement construit. Au prochain démarrage, c’est cette nouvelle « génération » qui sera utilisée, les anciennes « générations » restent disponibles si besoin.

Résumer Nix et NixOS en quelques lignes est un exercice compliqué tellement les différences avec les distributions classiques (atomiques ou non) sont nombreuses.

• Nix, le gestionnaire de paquet, à lui-seul vous demandera l’apprentissage d’un langage fonctionnel
• la description entière du système dans des fichiers Nix (paquets installés, configuration, services, utilisateurs, etc.)
• la reproductibilité des builds, que ce soit pour les paquets ou pour les « générations »
• l’abandon du Linux Standard Base, au profit du « store » Nix
• etc.

Les projets ostree et Nix ne sont pas les seuls à proposer de l’atomicité. On peut également noter que le projet Atomic Desktops de Fedora, dont est issue Silverblue, a fait des émules et a donné naissance au projet Universal Blue. Les différentes variantes proposées par Universal Blue reposent sur Bootable Container pour assurer l’atomicité des mises à jour (et non sur ostree/rpm-ostree). La distribution Vanilla OS repose sur ABRoot. Côté openSUSE Aeon, ce sont des snapshots Btrfs qui sont utilisés.

Bref, je ne peux que vous encourager à tester, et à retrouver paix et sérénité lors de vos futures mises à jour 😊

Java 25 se prépare pour l’atterrissage

Écrit par Thomas Broyer

Ça fait longtemps qu’on n’a pas parlé des releases Java vous ne trouvez pas ? Java 24 est sorti le 18 mars dernier, et sera remplacé par Java 25 au mois de septembre, qui deviendra la prochaine version LTS, et dont la roadmap a été figée la semaine dernière.

Si on récapitule toutes les nouveautés qui sont devenues stables depuis Java 21, on peut donc dors et déjà utiliser :

• (depuis Java 22) les variables anonymes, notamment pour les paramètres des lambdas ou le pattern matching
• (depuis Java 22) une nouvelle API pour l’interfaçage avec le code natif, pour remplacer JNI (et JNA) ; les usages de JNI  et de cette nouvelle FFM API (Foreign Function & Memory) seront restreints par défaut et doivent être explicitement autorisés sur la ligne de commande pour éviter des warnings, et plus tard des erreurs (un peu comme l’accès aux classes internes du JDK, bloquées par défaut depuis Java 16)
• (depuis Java 23) la javadoc peut être écrite en Markdown plutôt qu’en HTML
• (depuis Java 24) les streams gagnent une notion de gatherers pour les opérations intermédiaires, comme on avait déjà les collectors pour les opérations terminales.
• (depuis Java 24) une API standard pour travailler avec le bytecode, destiné à remplacer ASM
• (depuis Java 24) un cache des classes peut être généré ahead of time pour accélérer le démarrage des programmes

Et pour Java 25, on pourra compter sur :

• les scoped values, destinées à remplacer de nombreux usages de ThreadLocal pour des valeurs contextuelles, mais avec une sorte d’héritage de ces valeurs par les threads enfants
• la possibilité d’importer des modules (import module …) plutôt que des packages : tous les packages exportés par le module et, plus important, par les modules dont il dépend transitivement, sont automatiquement importés. Les imports ambigus (des classes de même nom provenant de différents packages) génèrent des erreurs qui doivent être résolues avec des imports explicites des packages ou des classes. Si le prototypage ou l’usage dans JShell demandent beaucoup moins de cérémonies, je trouve personnellement (comme pour les imports wildcards) que ça nuit à la lisibilité du code.
• on pourra écrire des fonctions main() en dehors de toute classe ; même si là ça ne nuit pas à la lisibilité, on reste dans une suppression des cérémonies pour, c’est le but affiché en tous cas, faciliter l’apprentissage du langage.
• on pourra enfin avoir du code dans ses constructeurs avant l’invocation du constructeur super(…) ou this(…), qui pourra même utiliser des branchements conditionnels pour appeler différents overrides si besoin ! Comme en JavaScript, il n’est pas possible d’accéder à l’instance avant l’invocation de super(…) (ou this(…) ici), mais on pourra enfin valider les arguments avant de devoir les passer à un autre constructeur.
• une API standard pour fonctions de dérivations de clés (KDF) comme HKDF-SHA256 (supporté nativement) ou Argon2 (qui pourra être fourni par une bibliothèque externe grâce à la SPI)
• le cache ahead-of-time est plus facile à utiliser (une seule étape contre 2 avec Java 24) et inclut désormais des informations de profiling des méthodes, pour permettre une compilation juste-à-temps (JIT) immédiate

Bien évidemment, chaque version apporte également son lot d’améliorations de performances, notamment au niveau des garbage collectors (G1, ZGC et Shenandoa)

Du côté des previews, sans toutes les lister, on pourra s’attarder sur les stable values qui rappelleront les by lazy de Kotlin, et structured concurrency qui entre dans sa cinquième preview.

Rendez-vous dans 2 ans pour la prochaine LTS 😉