URL: https://linuxfr.org/news/presentation-de-fedora-silverblue
Title: Présentation de Fedora Silverblue
Authors: Renault
 bubar🦥, Davy Defaud, Laurent Pointecouteau et ZeroHeure
Date: 2020年04月17日T16:05:29+02:00
License: CC By-SA
Tags: xfce, mageia, ubuntu, firefox, flatpak, nixos et fedora
Score: 59
Fedora Silverblue tente d’établir un système fonctionnel conciliant Fedora _Workstation_, la version bureautique de la distribution éponyme, et le projet Atomic. Cette déclinaison de Fedora commence à monter en puissance en termes de développement depuis quelque temps, et nous réalisons que pour beaucoup de personnes extérieures ce projet reste très flou, tant dans ses objectifs que sur les implications techniques.
L’objet de cet article est de retracer rapidement l’histoire d’Atomic et de Fedora Silverblue avant d’évoquer les détails de fonctionnement de celui‐ci.
![Logo de Silverblue](https://blog.fedora-fr.org/public/renault/Illustrations/silverblue-logo.png)
----
[Site de Fedora Silverblue](https://silverblue.fedoraproject.org/)
[Site officiel du projet Fedora](https://getfedora.org/)
[Site officiel de la communauté francophone de Fedora](https://www.fedora-fr.org/)
----
# 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](https://fedoraproject.org/wiki/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’il 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 par le manque d’attrait des utilisateurs pour leur distribution, même en dehors de Fedora, et aussi certains défauts structurels quant à l’approche traditionnelle 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, _a 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 ou Mageia 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 propose pas réellement de versions du 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 l’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 l’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 n’étant pas fournis 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ù 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é s’il le souhaite. Et force est de constater qu’aucun système Linux populaire, en dehors d’Android, n’a réellement mis les moyens pour changer ce modèle en profondeur.
Enfin, récemment, il y a eu l’émergence d’autres systèmes de gestion 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 bureau, comme GNOME, KDE Plasma ou Xfce, des autres applications.
 
[![Architecture de Fedora.next](https://blog.fedora-fr.org/public/renault/Silverblue/.Fedora.next_architecture_m.jpg)](https://blog.fedora-fr.org/public/renault/Silverblue/Fedora.next_architecture.jpg)
## 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, et 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) fournie par une autre version de Fedora. Cela permet donc d’utiliser par exemple la dernière version de Python même si l’on ne bénéficie pas de la dernière version de Fedora. 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 de 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.
 
![Logo de Fedora Workstation](https://blog.fedora-fr.org/public/renault/Silverblue/Flavor-workstation-background.png)
# Le projet Atomic 
## Genèse ##
En 2014, le [projet Atomic](https://www.projectatomic.io) est lancé. Son but est d’essayer de simplifier l’usage des systèmes RHEL, CentOS ou Fedora au sein des conteneurs tels que Docker. Donc, nous sommes plutôt dans un contexte _cloud_ où les images sont minimales et gèrent peu de services à la fois. Pour monter en charge, il suffirait d’en instancier plus ce qui est intéressant si le système est fiable et minimal.
 
Cela passe par une refonte de la manière de concevoir ces systèmes. Jusqu’ici toute distribution Linux peut être résumée par l’architecture « tout est paquets ». Chaque logiciel ou composant est fourni à travers un paquet. La cohérence et le fonctionnement de l’ensemble repose donc sur le gestionnaire de paquets et les liens de dépendances définis au sein de chacun des paquets.
 
Atomic repousse ce modèle traditionnel, du point de vue utilisateur du moins, avec le composant _rpm-ostree_ et le système qui est considéré comme un tout unifié avec la possibilité de réaliser des mises à jour atomiques. Il faut voir _rpm-ostree_ comme un gestionnaire de versions (un outil similaire à _git_ par exemple) pour des binaires. Ce système de fichiers de base du système sera versionné comme un code sous Git. Chaque mise à jour de ce dernier sera vu comme un _commit_.
 
En cela, il s’inspire du projet NixOS pour refaire les fondations d’une distribution. Mais NixOS a une approche différente, tandis qu’Atomic privilégie l’approche _commit_ / déploiement, NixOS repose sur des sommes de contrôles et des chemins dans la définition des paquets. L’inconvénient est qu’une modification dans une dépendance majeure du système, comme _glibc_, implique de régénérer l’ensemble des paquets qui en dépendent, alors que la compatibilité n’a pas été changée au niveau de l’ABI. L’approche d’Atomic permet d’éviter cet écueil. Atomic peut également être utilisé par n’importe quel outil capable de générer un système de fichiers, alors que NixOS requiert des outils et un langage spécifique.
## Différences avec une distribution traditionnelle ##
La conséquence évidente c’est que la notion de paquets disparaît pour l’utilisateur, le système de base est un tout indivisible et chaque composant est lié aux autres. Une mise à jour d’un élément dans ce système de base entraîne une mise à jour de l’ensemble. Heureusement, grâce aux _deltas_ entre chaque version, seulement ce qui a différé est réellement téléchargé et appliqué en cas de mise à jour. Sur une distribution plus classique, chaque paquet est mis à jour de manière indépendante des autres. Cela est fait à travers la commande _rpm-ostree upgrade_, qui regarde dans le dépôt où est versionné l’image pour récupérer la dernière version publiée.
Un avantage immédiat est que l’ensemble est standardisé. Chaque poste qui disposera de la version _X_ de l’image Atomic considérée sera identique aux autres du point de vue du système de base. Avec la méthode plus traditionnelle de faire, pour différentes raisons, cela n’est pas forcément le cas. Certains ne mettent pas tous les paquets à jour ou à la même fréquence. Les mises à jour n’ont pas lieu forcément dans le même ordre ou certains peuvent sauter des transitions intermédiaires dans le processus. Ce nouveau procédé améliore la reproductibilité et aussi la fiabilité car les tests d’assurance qualité reproduisent de fait le comportement de toutes les images en production.
L’autre intérêt est également le versionnage même du système. Si la mise à jour pose problème, revenir en arrière est simple et immédiat car il _suffit_ de sélectionner la révision antérieure dans l’outil de gestion (comme la commande _rpm-ostree rollback_ voire le chargeur de démarrage lui‐même). Avec un système de paquets, c’est souvent une étape bien plus complexe à réaliser et coûteuse à base de clichés du système. Et en cas de coupure de courant au mauvais moment, le système Atomic sera toujours opérationnel comme avant, alors que l’état d’un système plus traditionnel sera plus aléatoire, voire non fonctionnel.
 
Changer par ailleurs de version est relativement immédiat et complet. Le démarrage sélectionne la version désirée, la déploie et l’ensemble des paquets est à jour en même temps. Cela évite les possibilités d’incohérence que l’on peut avoir habituellement, si l’on redémarre une application en cours de mise à jour, par exemple, alors que potentiellement d’autres composants ne le sont pas encore.
Enfin, cela permet d’envisager d’aller plus loin. Comme le système de base est réalisé en bloc, il est possible de mettre à disposition ce système de base en lecture seule. Cela signifie isoler les dossiers qui ne peuvent être changés que par _rpm-ostree_ lors d’une mise à jour. Ces dossiers‐là seront en lecture seule pour ne limiter la possibilité d’écriture qu’à certains dossiers précis pour la configuration, les données ou ajouter des logiciels supplémentaires. Ainsi, cette partie du système est plus robuste car moins sensible aux accidents ou aux actes malveillants.
De manière plus concrète, les dossiers `/etc` et `/var` sont les seuls dossiers accessibles en lecture et écriture. Ils sont préservés en cas de mise à jour. En cas de modification de la configuration d’un logiciel dans `/etc`, ostree applique le _3‐way merge_ pour fusionner vos modifications avec celles fournies par la mise à jour. `/var` peut être utilisé pour reproduire une hiérarchie FHS traditionnelle, si nécessaire, exploitable via `chroot` ou similaire.
## Personnaliser le système ##
Se pose la question de la personnalisation du système. Comment faire dans ce cas pour ajouter un nouveau service dans une image ?
 
La première solution est de générer cette image personnalisée soi‐même. _rpm-ostree_ n’a pas de notion de paquets, mais on peut générer une image OSTree avec des paquets, donc à partir d’une image classique de Fedora, par exemple.
 
Ensuite, c’est d’installer un nouveau composant sous forme d’une surcouche au système de base. Par exemple, exécuter la commande `rpm-ostree install toolbox` va récupérer l’image produite par le paquet _toolbox_ et le déployer par‐dessus celui du système de base. Il suffit de générer le système de fichiers voulu avec les logiciels souhaités, avant de déployer l’ensemble et de maintenir les mises à jour soi‐même.
 
La philosophie de cette architecture est de recourir à des conteneurs pour isoler au mieux les applications personnelles et faciliter la maintenance et le déploiement.
## Mise en œuvre dans Fedora ##
Dès 2014, Fedora va travailler pour proposer une image de sa version _cloud_ minimale reposant sur le projet Atomic. Très rapidement, cette implémentation va devenir celle par défaut car elle correspond bien au but même du produit.
# Fedora Silverblue 
## Naissance du projet ##
Devant les promesses du projet Atomic, les réflexions de Fedora.next et la transition réussie pour Fedora _Cloud_, l’idée émerge de réaliser Fedora _Workstation_ avec le projet Atomic en marge du projet Fedora dans un premier temps. En revenant dans le giron de Fedora, l’équipe a décidé de renommer le projet en Fedora Silverblue en 2018 pour donner plus de visibilité à ce projet de long terme, tout en le distinguant de Fedora Atomic qui est associé à Fedora _Cloud_.
 
L’objectif est évidemment de fournir les avantages cités lors du traitement du projet Atomic, mais pour l’image phare de Fedora. Les avantages étant les mêmes, nous n’allons pas les énumérer à nouveau mais plutôt évoquer les difficultés et le travail qui reste à fournir. Et l’avenir éventuel de ce projet.
 
Il est évident que la conception du projet Atomic colle parfaitement avec les exigences d’une image minimale telle que Fedora _Cloud_. Pour _Workstation_ cela est plus complexe. Un utilisateur installe et configure beaucoup de logiciels différents. Cette combinaison est presque unique. Il est impensable d’avoir une image universelle qui contiendrait l’ensemble des logiciels pour chaque utilisateur avec une telle architecture. Et il est assez irréaliste d’exiger d’un utilisateur lambda de manipuler un outil tel que Docker pour parvenir à ses fins. Installer de nouveaux outils se fera par deux voies différentes.
## Flatpak ##
La première repose sur Flatpak. Flatpak est un projet pour fournir un système de paquets dit _universel_ dans un système isolé de bac à sable. Flatpak dispose de nombreux atouts dans ce contexte.
 
Pour commencer, il autorise l’installation de logiciels par des utilisateurs non privilégiés simplement, sans droits super‐utilisateur, contrairement à un paquet d’une distribution traditionnelle. Car le logiciel s’installe par défaut dans le répertoire de cet utilisateur.
 
Ensuite, à cause de l’isolation du logiciel et de l’universalité de la solution, il doit embarquer ses propres dépendances. Cela alourdit le paquet et complexifie la maintenance des bibliothèques très communes, mais un paquet Flatpak peut fonctionner sur n’importe quelle distribution, et il est possible d’installer plusieurs versions d’un même logiciel en même temps, ce qui donne plus de liberté à l’utilisateur.
 
Un autre aspect intéressant est le concept des [portails](https://docs.flatpak.org/fr/latest/basic-concepts.html#portals). Comme les paquets Flatpak sont isolés du système, ils n’ont accès qu’à peu de choses par défaut. Ils ne peuvent lire les données dans vos répertoires personnels, par exemple. Pour que cela soit possible, les paquets Flatpak vont utiliser des portails pour informer l’utilisateur que l’application a besoin de permissions spéciales pour effectuer une action, comme prendre une capture globale de l’écran, accéder au réseau, accéder à la webcam, lire un fichier personnel, etc. L’utilisateur peut librement autoriser ou non cette application à réaliser cette action à la volée. Ce fonctionnement ressemble au mécanisme de permissions des systèmes pour mobile comme iOS ou Android. Cette architecture permet d’améliorer la sécurité en minimisant les droits des applications au strict nécessaire, en alertant l’utilisateur, et limite les problèmes en cas de bogue de l’application.
 
Pour atténuer les inconvénients mentionnés précédemment, Flatpak fonctionne aussi avec des dépôts pour centraliser les mises à jour de l’ensemble de ses applications. Il dispose également de _[contextes d’exécution](http://docs.flatpak.org/fr/latest/available-runtimes.html)_ pour unifier les bibliothèques très communes et éviter que chaque application ne les embarque ou ne les mette à jour elles‐mêmes. Ces contextes d’exécution pouvant être installés en parallèle, on peut garder une application fonctionnelle même en cas de rupture de compatibilité entre deux versions d’un contexte d’exécution. La mise à jour par delta limite également le besoin en bande passante d’une mise à jour au strict nécessaire.
 
Cependant, Flatpak ne concerne que les applications disposant d’une interface graphique. Or, il y a d’autres composants qu’un utilisateur voudrait pouvoir installer sur sa Fedora Silverblue, comme des outils de développement.
## Fedora toolbox ##
C’est la deuxième voie pour installer des logiciels supplémentaires dans le système. Fedora toolbox repose sur _buildah_ et _podman_, qui est lui‐même un clone de Docker pouvant s’exécuter sans droits super‐utilisateur.
 
Ainsi, il devient possible d’installer facilement des conteneurs pour un utilisateur donné, pour ses développements par exemple. On reprend les avantages cités plus haut en termes de sécurité, de fiabilité ou encore de possibilité de manipuler des versions différentes d’un même composant. Ce qui est un besoin récurent en développement, par ailleurs.
 
En fait, cet utilitaire permet de créer un conteneur basé sur une version de Fedora de votre choix, avec une configuration par défaut pour que le partage avec l’hôte soit simple, comme la correspondance des noms utilisateurs et des différents identifiants. La base du conteneur peut être partagée entre les instances : deux conteneurs basés sur F31 ne requièrent de télécharger qu’une fois cette base.
## État du projet et avenir ##
Fedora Silverblue bénéficie d’un grand investissement et de grands progrès sont réalisés de version en version. Mais le projet est encore trop immature pour envisager de remplacer Fedora _Workstation_ par défaut, car les difficultés à résoudre restent nombreuses.
 
En effet, le public de Fedora _Workstation_ est très hétérogène et les besoins entre les différents utilisateurs sont importants. Il faut s’assurer que l’ensemble des cas d’usage soient couverts malgré leur diversité. Et cela sans que ledit système soit plus complexe.
 
Pour l’instant, l’intégration _rpm-ostree_, Flatpak et toolbox fonctionne plutôt bien. Pour des usages très simples et peu exotiques, c’est un système qui peut être utilisable. Mais les usages plus complexes ou exotiques sont encore mal gérés.
Quelques exemples de problèmes à résoudre actuellement :
 
* le fonctionnement des environnements de développement dans un tel contexte ;
* l’installation et l’usage de codecs multimédias additionnels ;
* certaines applications qui dépendent de pilotes spécifiques comme VirtualBox ;
* les extensions système.
Mais ceci n’est qu’un aperçu des problèmes, il y en a bien d’autres dans le détail. Et même s’il y a une volonté de tous les résoudre, personne ne sait si Fedora Silverblue pourra réellement remplacer Fedora _Workstation_ à terme. Du moins, avec le respect complet de son architecture telle qu’elle a été envisagée. Sans oublier les adeptes des distributions traditionnelles pour les avantages que cela leur procure.
 
L’équipe de Fedora Silverblue propose des versions majeures synchronisées avec le reste du projet. Donc, si cela vous intéresse de tester la bête en vrai, n’hésitez pas !
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/presentation-de-fedora-silverblue.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/presentation-de-fedora-silverblue.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>