User:Renault/Promotion/Présentation de Fedora Silverblue

Fedora Silverblue est un projet élaboré par le projet Fedora qui tente d'établir un système fonctionnel conciliant Fedora Workstation, la version bureautique de Fedora, et le projet Atomic. Cette déclinaison de Fedora commence à monter en puissance en terme de développements depuis quelques temps et nous réalisons que pour beaucoup de personnes extérieures ce projet reste très flou tant dans ses objectifs mais aussi sur les implications techniques.

L'objet de cet article est de retracer l'histoire rapidement de Atomic et Fedora Silverblue avant d'évoquer les détails de fonctionnement de celui-ci.

Avant Fedora Silverblue, émergea Fedora.next

Les fondements de Fedora Silverblue prennent racine dans la réflexion menée dans le cadre de Fedora.next, projet censé inscrire Fedora dans la durée après avoir fêté ses dix années. En effet, en 2013-2014, le projet Fedora s'est mis en pause technique pour réfléchir quant à son avenir, dans ce qu'elle souhaitait délivrer à ses utilisateurs tout en tirant un bilan de la situation actuelle. C'est pourquoi il y a eu près d'un an entre Fedora 20 et Fedora 21, au lieu des six mois habituels, pour dégager du temps et prendre du recul au sein du projet tout entier.

Le bilan

Le bilan dressé du développement d'une distribution est particulièrement critique. Il est particulièrement mis en exergue le manque d'attrait des utilisateurs pour leur distribution, même en dehors de Fedora, et aussi certains défauts structurels quant à l'approche traditionnel d'aborder la réalisation d'une distribution Linux.

Une distribution Linux classique génère et propose des paquets pour ses utilisateurs, afin qu'ils puissent installer les applications concernées en résolvant les dépendances nécessaires et à priori avec une intégration entre elles pour fournir une expérience utilisateur acceptable. Ensuite il y a deux modèles qui s'ajoutent à ce tableau. Le premier, plus répandu et employé par Fedora, Debian, Ubuntu, Mageia et autres OpenSuse est de proposer à une fréquence fixe une nouvelle version de leur système. Et très souvent, pour une version donnée de ces systèmes, les logiciels fournis sont comme figés. Les mises à jour concernent surtout les problèmes de sécurité ou la correction de bogues, plus rarement des versions qui apportent de nouvelles fonctionnalités. Pour obtenir des logiciels plus récents, il faut donc changer de version du système via une mise à niveau. Le second modèle, porté par ArchLinux et Gentoo par exemple, ne proposent pas réellement de versions de leur système. Les logiciels sont continuellement mis à jour vers la dernière version.

Ce modèle a rarement été remis en cause. Il apporte en effet des avantages certains. Installer un paquet depuis les dépôts officiels est très simple et efficient pour l'utilisateur. La mise à jour est centralisée ce qui limite le temps de maintenance nécessaire à cette activité. Et au niveau de la sécurité et de l'économie de ressources cela est également le bienvenu car les logiciels peuvent partager des ressources en commun sans difficulté et il est inutile de maintenir plusieurs fois la même bibliothèque commune par exemple.

Mais ce modèle a également un revers pour l'utilisateur et la mise au point des distributions. Tout d'abord l'utilisateur est comme piégé par sa distribution. Il est très difficile d'installer en parallèle deux applications identiques de versions différentes. Et si on souhaite une version différente d'un logiciel que celle proposée par sa distribution, comme la dernière version de GNOME, ou la version précédente de Python, la distribution ne fournit rien pour répondre à ce besoin. L'utilisateur doit se débrouiller pour cette tâche ce qui est particulièrement peu flexible. Et au niveau de la fiabilité ou de la maintenance, cela est également plutôt complexe si on cherche à atteindre une certaine qualité. Les applications dans ce modèle ont accès à tout dans le système, et les opérations d'installation ou de mise à jour peuvent corrompre le système si une coupure de courant intervient au mauvais moment par exemple. Enfin, mettre à jour ou installer un paquet n'est pas anodin, il y a souvent exécution de scripts pour convertir des fichiers de configuration pour être compatible avec la nouvelle version, ou pour rendre ce dernier exploitable comme créer un utilisateur qui va exécuter le service nouvellement installé. Sauf que, chaque installation de Fedora est différente, les utilisateurs n'installent pas les mêmes logiciels et ne les utilisent pas de la même manière. Il faut donc que le mainteneur anticipe de nombreux problèmes potentiels liés à ces contextes très différents pour s'assurer que son paquet sera exploitable pour tous sans accrocs.

Or ces défauts sont très problématiques. En particulier à un moment où les logiciels disponibles pour Linux se multiplient et se développent un peu partout en étant pas fournies via la distribution mais par Github par exemple. D'autant plus que l'utilisateur est habitué des systèmes d'exploitation macOS et Windows où installer une nouvelle application est assez indépendante de la version du système qui l'exécute. En plus d'être capable d'installer plusieurs versions en simultanées s'il le souhaite. Et force est de constater que aucun système Linux populaire, en dehors d'Android, n'a réellement mis les moyens de changer ce modèle en profondeur.

Enfin, récemment il y a eu l'émergence d'autres systèmes de gestionnaires de paquets qui forment des écosystèmes indépendants des distributions. On peut évoquer en premier lieu les langages de programmation qui proposent des modules facilement téléchargeables pour les développeurs comme Python avec pip, Ruby avec gem, Go, Rust ou PHP. De plus, certaines applications ont leur propre écosystème d'extensions comme Firefox ou GNOME Shell et les paquets peuvent être redondants avec cette infrastructure.

L'architecture envisagée

Pour résoudre ce problème, en découplant la base du système des applications, Fedora.next a exploré l'idée de transformer Fedora en un système avec trois couches de logiciels.

La première couche est une base qui se veut très minimale et comporte à peine ce qui est nécessaire pour avoir un système fonctionnel. Cela concerne la gestion du matériel via le chargeur de démarrage et du noyau, les bibliothèques essentielles comme la bibliothèque C, de quoi gérer des paquets et de démarrer des services comme systemd. Guère plus.

La seconde couche concerne plutôt les piles technologiques qui sont également assez essentielles au fonctionnement du système et de la plupart des applications. C'est là qu'on retrouvera la plupart des bibliothèques très importantes, mais surtout les langages de programmation et leur écosystème comme Python, Ruby, PHP, Perl, etc.

Enfin, la dernière contient les applications elles-mêmes avec éventuellement une séparation entre les environnements de bureaux comme GNOME, KDE / Plasma ou Xfce des autres applications.

La mise en œuvre

Le projet Fedora développa plusieurs solutions dans ce cadre. La première est la création immédiate des produits, à savoir Fedora Workstation, Server et Cloud à l'époque. Le but était de fournir une expérience par défaut qui corresponde au mieux ces différents cas d'usage, que ce soit par les paquets fournis par défaut, les options ou configurations natives. Mais aussi, cela permettait à Cloud d'expérimenter une architecture plus agressive et différente des deux autres : le projet Atomic que l'on abordera un peu plus loin.

Ensuite, le projet Fedora travailla sur le concept des modules. L'objectif est qu'une version de Fedora puisse installer plus facilement la version d'un composant de la seconde couche (les fameuses piles mentionnées plus haut) fournies par une autre version de Fedora. Cela permet donc d'utiliser par exemple la dernière version de Python même si on ne bénéficie pas de la dernière version de Fedora si on le souhaite. Le tout en passant par les dépôts de manière assez classique.

Malheureusement l'architecture envisagée permet difficilement l'installation simultanée de deux piles complètes en parallèle. À part le cas Python 2 et Python 3 qui a demandé un investissement important sur la durée pour l'autoriser, les dépôts traditionnels et les modules n'offrent que la possibilité d'installer une version de référence différente de celle proposée par défaut.