Connexion
Abonnez-vous

Silverblue : le futur de Fedora, mais une route encore longue

Sécurité contre expérience utilisateur

Silverblue : le futur de Fedora, mais une route encore longue

Le 30 octobre 2019 à 08h04

Aux côtés de l’édition Workstation classique de Fedora grandit une autre variante, moins connue : Silverblue. Fondée sur le concept de système inaltérable et les conteneurs, ses concepteurs y voient le futur de la distribution.

Fedora est depuis longtemps le laboratoire de Red Hat pour tester l’ensemble des nouveautés logicielles qui l’intéressent. Tout ce qui a été éprouvé au cours des versions et assure un bon niveau de fiabilité peut être incorporé ensuite dans RHEL (Red Hat Enterprise Linux).

La distribution n’est cependant pas disponible qu’en une seule variante. Les plus connues, largement mises en avant sur le site officiel, sont Workstation et Server, dont les noms sont suffisamment parlants. Il en existe d’autres, dont Silverblue. Visuellement, il est difficile de les séparer. Sous le capot, c'est une autre paire de manches.

La philosophie derrière Silverblue

Avant d’aborder son fonctionnement particulier, il faut comprendre ce qu’est Silverblue, qui possède des bases techniques très différentes de Fedora, en dépit de son appartenance à la même famille.

Elle en reprend d’ailleurs peu ou prou les mêmes composants. L’idée générale est d’approcher l’architecture du système de manière plus moderne, pour obtenir des gains en fiabilité, sécurité et performances. Cette variante de la distribution repose donc sur deux concepts généraux : une base inaltérable et des conteneurs.

Cette base inaltérable (immutable en anglais) vient de la manière dont est géré le système proprement dit. Contrairement à la version classique de Fedora, Silverblue ne présente pas une collection paquets RPM s’installant les uns à la suite des autres. La base est en fait une image uniforme et cohérente copiée sur le disque de la machine pendant la phase d'installation (depuis une ISO), puis paramétrée en fonction du matériel et des choix de l’utilisateur.

Mais cela va plus loin, notamment dans la manière dont le système est mis à jour. L’application des rustines se fait ainsi sur une copie de l’image système. Ces modifications sont mises en attente jusqu’au redémarrage. La copie de l’image remplace alors la précédente et devient le système actif. Ces opérations sont effectuées par rpm-ostree.

Gros avantage de la méthode : la fiabilité et la sécurité. L’image système est en effet en lecture seule et ne peut donc être modifiée. Si d’aventure le processus de mise à jour échouait, il n’y aurait pas d’impact sur Silverblue puisque les opérations s’effectuent sur une copie, à part. En outre, on peut facilement revenir à l’état antérieur de la machine. Inconvénient bien sûr : les modifications ne seront prises en compte qu’après un redémarrage.

Ce dernier point peut représenter un problème selon l’usage que l’on souhaite faire de Silverblue. Mais la distribution est surtout présentée comme visant les machines de travail, pas les serveurs. La distribution s’appelait d’ailleurs Atomic Workstation précédemment. Pour les serveurs focalisés sur les conteneurs logiciels, Fedora propose CoreOS après son rachat en 2018, reprenant globalement les mêmes concepts, mais avec une approche nettement plus minimaliste. Red Hat en propose une version commerciale, nommée Container Linux (anciennement CoreOS aussi).

Notez que ce fonctionnement « immuable » n’est ni spécifique à Silverblue, ni même une nouveauté. D’autres systèmes d’exploitation, particulièrement Android et Chrome OS, se servent de ce type d’architecture. Plus récemment, macOS Catalina s’y est mis aussi, comme mentionné dans notre dossier qui lui est consacré.

L’autre grand versant de Silverblue, ce sont les conteneurs. Il s'agit, dans les grandes lignes, d'une forme de virtualisation ramenée au niveau d’une application. Dans un paquet isolé du reste du système, on embarque tout ce dont elle a besoin. Pour s’exécuter, il suffit de s’assurer que l’infrastructure utilisée est cohérente entre le système hôte et l’application.

Les développeurs n’ont ainsi pas à se soucier des versions des bibliothèques et donc de nombreux problèmes de compatibilité. Les modifications générées par le conteneur restent circonscrites à son espace virtualisé et ne peuvent atteindre le système. En contrepartie d’un poids plus élevé (toutes les dépendances sont embarquées notamment), on obtient un fonctionnement général plus fiable.

Il y a certains bénéfices inhérents à cette méthode, comme par exemple l’exécution concurrentielle de plusieurs versions différentes d’un même logiciel, sans qu’elles créent d’interférences.

Présentation générale de Fedora Silverblue

On l’aura compris, cette édition particulière de Fedora n’a pas grand-chose à voir techniquement avec la distribution d’origine. Ses différences ne sauteront d’ailleurs même pas aux yeux à l’installation, tant la procédure est pratiquement identique. Visuellement, rien ne distingue les deux variantes.

Il faudra attendre d’arriver sur le bureau GNOME (les briques logicielles sont globalement les mêmes) et de creuser un peu pour s’apercevoir des changements opérés. On remarque d'ailleurs vite que les performances sont excellentes. Comme nous l’avions noté dans notre article consacré à Fedora 31, la réactivité générale avait fait un nouveau bond plus que sensible. Cette impression est renforcée dans Silverblue.

Mais pour comprendre ce qui vous attend réellement avec cette variante, il faut ouvrir l'application Logiciels. Le constat est rapide : il y a beaucoup moins d'éléments proposés que dans Fedora classique. Pourquoi ? Parce que le gestionnaire de paquets DNF est absent. L’utilisateur ne peut donc pas procéder à des installations ordinaires.

Et la question de l’installation se pose vite, car Silverblue ne fournit que le strict minimum. Un coup d'œil à la grille des applications disponible le fait aisément comprendre :

Fedora Silverblue

En clair, seul Firefox est fourni. Si vous ouvrez les paramètres, section Logiciels par défaut, le désert applicatif vous sera confirmé. Il faut donc aller dans Logiciels et installer ce qui manque… si vous le pouvez.

On y trouve en effet seulement les versions Flatpak (donc des conteneurs) des applications dont les développeurs se sont donné la peine d’en produire. Elles sont peu nombreuses dans la boutique. La partie « Audio et vidéo » n’en possède par exemple que deux : Cheese et Enregistreur de son. On pourra trouver Thunderbird dans la partie « Communications », mais « Bureautique » n’embarque même pas LibreOffice.

L’utilisateur est-il condamné pour autant à devoir s’en contenter ? Non, car du propre aveu de Fedora, il est conseillé de se rendre sur la boutique indépendante Flathub, dont la sélection est beaucoup plus importante.

Pour celles et ceux qui ne connaîtraient pas, il suffit de chercher une application sur le site, puis de cliquer sur « Install ». Un petit fichier de quelques ko est alors téléchargé. Une fois ouvert, il lance Logiciels sur la page correspondante, permettant alors de déclencher l’installation.

Fedora SilverblueFedora Silverblue

Une fois que l'application Logiciels aura été ouverte une fois depuis Flathub, le dépôt correspondant sera automatiquement ajouté dans ses paramètres. En clair, toutes les recherches suivantes pourront se faire depuis, sans avoir à passer à nouveau par le site de Flathub. La sélection devient du coup beaucoup plus importante.

Besoin de VLC ? Il s’y trouve, la source mentionnant bien son origine (dl.flathub.org). Des logiciels propriétaires sont également présents, comme le binaire de Visual Studio Code. Notez que les installations classiques peuvent quand même se faire, via la commande rpm-ostree.

Elle n’est cependant pas recommandée, plutôt à garder s’il n’y a vraiment pas d’autre solution. Ce type d’installation va réclamer en effet une modification du système. Au vu du fonctionnement de Silverblue, la suite est donc prévisible : les changements ne seront pris en compte qu’après un redémarrage.

Créer ses propres conteneurs

Si vous aimez l’idée d’un système séparant par défaut sa base de tout l’applicatif, Silverblue peut d’emblée être une option, même si le système en tant que tel reste pour l’instant plus proche d’un travail en progression qu’une véritable version à mettre entre toutes les mains (nous y reviendrons).

Mais c’est bien avec les conteneurs que cette variante de Fedora prend tout son sens. Les flatpaks en sont déjà bien sûr, mais l’inclusion de Toolbox permet d’aller plus loin. Ce dernier est un outil pour créer des conteneurs et y insérer des applications via DNF. Une manière, en quelque sorte, de construire un type de flatpak personnalisé. 

La commande toolbox create va générer le premier conteneur. À la première exécution, Silverblue détectera qu’aucun environnement n’est présent pour servir de base au conteneur. Il proposera donc de télécharger l’image correspondante, ici Fedora 31. 500 Mo plus tard, le socle est prêt à l’emploi et le premier conteneur apparaît sous la forme « user@toolbox », pour bien montrer le changement de périmètre (il n’est plus dans localhost).

Fedora Silverblue

Les conteneurs sont créés par podman (compatible avec les images OCI de Docker) en mode rootless, donc sans aucun droit administrateur. L’utilisateur y retrouve son nom, ses permissions, l’accès à son dossier personnel et les principaux outils en ligne de commande, dont DNF. Ce dernier permet alors d’installer d’autres outils en ligne de commande ou même directement des applications.

Toolbox fournit des commandes pour créer autant de conteneurs que souhaité, les lister, entrer et sortir (exit) de celui en cours ou encore les supprimer, y compris s’ils sont en cours de fonctionnement.

Une distribution pour l’instant surtout destinée aux développeurs

À quoi sert donc cette variante si particulière de Fedora ? Pour le commun des mortels, sans doute à rien… pour l’instant. Silverblue se destine actuellement aux développeurs ayant affaire aux conteneurs, Toolbox permettant de créer facilement un environnement temporaire pour orienter par exemple des tests de compatibilité pour un code particulier.

L’idée générale derrière Silverblue est de retrouver, dans un conteneur, l’environnement familier basé sur RPM, permettant au développeur de se lancer dans des opérations qui, en temps normal, pourrait mettre en danger l’intégrité du système. Il pourrait bien sûr créer une machine virtuelle et sauvegarder/restaurer des états avant et après les tests. Mais la création de conteneurs permet d’enchainer les opérations sans avoir à se soucier des états.

Quand les tests sont terminés, on sort simplement du conteneur.

L’étrange statut de Silverblue pour l’instant

Un système inaltérable peuplé uniquement de conteneurs, voilà la vision globale de Silverblue. Les développeurs de Fedora n’hésitent pas à annoncer sur la page officielle du projet que cette variante représente le futur de la distribution, même si personne ne se hasarde pour l’instant à donner de date.

Et pour cause, il reste de nombreuses questions en suspens, car ce fonctionnement particulier impose ses propres limites. Toutes les applications ne peuvent pas forcément fonctionner dans des conteneurs. Il y a plusieurs années par exemple, des éditeurs ont quitté le Mac App Store car Apple y imposait l’utilisation de la sandbox. Étaient notamment concernés des outils système ou de développement.

Le problème est pour l’instant en partie le même avec Silverblue. Des outils d’analyse réseau comme nmap ou tcpdump peuvent ne pas fonctionner, selon le paramétrage des conteneurs. Des soucis apparaitront également avec tous les applications qui auraient besoin, pour quelque raison que ce soit, d’accéder au matériel.

Exemple, dfu-util, dont la mission est l’envoi de firmwares dans des périphériques USB. Même l’installation des polices, qui passe par RPM, réclame un redémarrage du système.

En l’état, Silverblue garde un peu son statut de « bête curieuse », dont le test vaut le coup d’œil. Le fonctionnement général embarque son lot de promesses très intéressantes sur la sécurité, la fiabilité et les performances. Mais l’équipe de développement le dit elle-même : « Il est possible que Silverblue finisse par remplacer la Workstation classique. Mais il reste une longue route à parcourir pour que Silverblue fournisse les mêmes fonctionnalités et expérience utilisateur que la Workstation ». Et de préciser que jusqu’à nouvel ordre, les deux moutures seront proposées en même temps.

On imagine facilement que les prochaines évolutions de Silverblue se concentreront sur la facilité d’utilisation au quotidien, pour que des opérations aussi courantes que l’ajout d’une police puissent se faire de manière transparente.

En attendant, tester Silverblue – voire l’utiliser – ne représente aucune difficulté. On peut facilement récupérer son image ISO (environ 2 Go) et s’en servir dans un client de virtualisation comme VirtualBox ou VMware Workstation. On peut également l’installer nativement, avec un processus Anaconda strictement identique côté utilisateur.

Commentaires (20)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

En fait on passe d’un modèle distribution (OS + applis) a un nouveau framework qui ne fournis plus que l’OS, une sandbox et quelques exemple d’appli utilisant la sandbox.



L’OS se protège de l’applicatif et laisse se démerder développeurs et l’utilisateur entre eux.

votre avatar







XXC a écrit :



L’OS se protège de l’applicatif et laisse se démerder développeurs et l’utilisateur entre eux.







Non. Hormis pour les cas où une application aurait besoin d’une bibliothèque peu commune ne faisant pas parti des principaux runtimes, la plupart des applications n’auront pas besoin d’inclure de bibliothèques dans leur Flatpak.



Et les runtimes sont maintenus collaborativement, comme pour les distributions. Voir même mieux, puisque les runtimes et les Flatpak étant distribution-agnostiques, des mainteneurs / membres des équipes sécurité des différentes distributions ou environnements de bureau peuvent collaborer ensemble à la bonne gestion des runtimes.



Quant aux applications, en retirant un intermédiaire (la distribution), les développeurs pourront plus rapidement proposer de nouvelles versions aux utilisateurs.


votre avatar







Okki a écrit :



Non. Hormis pour les cas où une application aurait besoin d’une bibliothèque peu commune ne faisant pas parti des principaux runtimes, la plupart des applications n’auront pas besoin d’inclure de bibliothèques dans leur Flatpak.



Et les runtimes sont maintenus collaborativement, comme pour les distributions. Voir même mieux, puisque les runtimes et les Flatpak étant distribution-agnostiques, des mainteneurs / membres des équipes sécurité des différentes distributions ou environnements de bureau peuvent collaborer ensemble à la bonne gestion des runtimes.





Mais à l’inverse, en tant qu’utilisateur, si je veux recompiler une lib pour corriger un bug qui me bloque, ou changer un comportement (cf les variantes FreeType infinality), ça devient beaucoup plus compliqué que de recompiler le paquet rpm avec un patch.


votre avatar

 







Renault a écrit :



Pas du tout, l’installation via rpm-ostree se base sur des overlays, liens matériels et clichés du système. D’ailleurs ostree est souvent surnommé git du binaire. Donc en fait quand tu changes ton système, tu fais un changement d’état. Ce changement est indolore et instantané et tu peux revenir en arrière sans problèmes. D’ailleurs GRUB peut maintenant proposer les différentes versions de ton système pour revenir facilement en arrière si nécessaire.





Pourtant, ce n’est pas ce qui est indiqué dans l’article (pour les polices en tout cas).

Dans le principe de fonctionnement, il y a des choses intéressantes (le système devient un sanctuaire intouchable), par contre, si l’on a besoin de faire des modification sur un fichier de configuration du système, l’obligation de redémarrer pour appliquer les modifications peut être problématique.



Et d’ailleurs si l’on veut modifier un fichier de config d’un logiciel (hors système), ça se passe comment ?

Exemple : J’utilise SSH pour accéder à mon système à distance, si je souhaite en modifier les paramètres (pour interdire le log avec mot de passe au bénéfice de celui avec clés publiques / privées), cela va se passer comment  une fois la modif effectuée ?

Il va falloir redémarrer le système ?

Un nouveau conteneur SSH sera créé ?



Tu vas sans doute me répondre que je n’ai qu’a testé et tu as sans doute raison, mais pour le moment, dans la théorie, je vois ce système, bien qu’intéressant sur certains points) comme étant (potentiellement) rigide et potentiellement problématique quand à mon usage.



P.S. : Article très intéressant. <img data-src=" />


votre avatar

Dans Fedora Silverblue, /var et /etc sont en lecture et écriture pour des raisons évidentes de configuration et de stockage de données de travail pour certaines applications serveurs ou systèmes. Cependant tes binaires ou bibliothèques qui sont dans /usr eux ne sont pas modifiables sans changement d’état du système.

votre avatar

J’ai du mal à voir un quelconque avantage :




  • os livré en image en lecture seule :

    Donc tu ne peux rien changer, si t’as installé Gnome tant pis pour toi tu ne pourras pas essayer KDE ou XFCE ?!

    C’est très windowsien comme philosophie, je dirais même à l’exact opposé du mode libre <img data-src=" />



  • tout isoler dans des conteneurs, j’y vois pleins de défauts :

    taille des applis,

    nombre et temps de mise à jour, (télécharger encore et encore les mêmes librairies)

    reboot à chaque install



  • Fausse impression de sécurité :

    Ça n’est jamais complètement isolé (il faut bien copier/coller d’une appli à l’autre ou utiliser des fichiers communs). On le voit sous Android cette partie (partage entre appli et gestion des fichiers) est très mal gérée, et source de failles.

    En cas de faille sur un composant majeur (ex récent openssh), il a suffi de prendre 5min pour mettre à jour la lib en central, avec le système de containeur il faudrait (attendre qu’elles soient dispo &) mettre à jour toutes les applis utilisant openssl ?! C’est vraiment un fonctionnement archaïque !



  • stabilité du système : Je ne vois pas où est le pb avec nos distrib classiques, si je veux revenir en arrière, je désinstalle / résinstalle la version précédente, même pas besoin de rebooter <img data-src=" />

    Par défaut tout est aussi en lecture seul, donc à moins de jouer du sudo comme un goret c’est assez compliqué de casser quoi que ce soit.

    Ma distrib (une gentoo parfaitement à jour) a été installée vers 2004-2005, je n’ai jamais eu à réinstaller quoi que ce soit même en changeant tous les composants, ou en faisant des migrations majeures, les seuls reboot nécessaire sont pour les maj de noyaux.

votre avatar







fofo9012 a écrit :



Donc tu ne peux rien changer, si t’as installé Gnome tant pis pour toi tu ne pourras pas essayer KDE ou XFCE ?!







Il suffit d’installer une image avec KDE ou Xfce. Où est le problème ?







fofo9012 a écrit :



nombre et temps de mise à jour, (télécharger encore et encore les mêmes librairies)







La majorité des bibliothèques sont dans les runtimes, et en cas de mise à jour, il n’y a besoin que de récupérer les différences entre deux révisions, pas besoin de tout re-télécharger.







fofo9012 a écrit :



En cas de faille sur un composant majeur (ex récent openssh), il a suffi de prendre 5min pour mettre à jour la lib en central, avec le système de containeur il faudrait (attendre qu’elles soient dispo &) mettre à jour toutes les applis utilisant openssl ?!







Déjà répondu dans un précédent commentaire. OpenSSL fait partie du runtime Freedesktop et n’est donc pas embarqué dans chaque Flatpak. Lorsque une faille est corrigée, le runtime est mis à jour et tous les Flatpak bénéficient aussitôt du correctif.



La technologie a beau être différente, le résultat est finalement le même que pour les distributions actuelles. C’est même mieux pour toutes les petites distributions qui n’ont pas forcément une équipe sécurité ou qui ne sont pas forcément aussi réactives que les grosses distributions, puisque là, le travail est fait en commun et bénéficie à tous, peu importe la distribution utilisée.







fofo9012 a écrit :



stabilité du système : Je ne vois pas où est le pb avec nos distrib classiques, si je veux revenir en arrière, je désinstalle / résinstalle la version précédente, même pas besoin de rebooter <img data-src=" />







Tout dépend où ça casse et ce qu’a prévu la distribution pour que l’utilisateur puisse réussir à se dépatouiller sans trop de connaissances techniques. Des problèmes, il peut y en avoir des milliers. Tu fais une mise à jour, paf, coupure de courant au même moment, et manque de bol, c’était en train de mettre à jour un élément critique nécessaire au bon fonctionnement du système.



Par le passé, je me suis déjà retrouvé avec un système qui bloquait lors du boot, sans arriver à retrouver un shell fonctionnel et encore moins une interface graphique. Ou plus récemment, ici même, SebGF qui possède une carte nVidia et qui s’est retrouvé avec un écran noir suite à l’installation du pilote propriétaire.



C’est donc bien plus pratique et à la portée de monsieur tout le monde de pouvoir redémarrer sur une image système qu’on sait fonctionnelle. D’autant plus que le système peut voir de lui-même s’il ne réussit pas à démarrer normalement et donc revenir automatiquement sur la précédente image qui était ok.







fofo9012 a écrit :



Par défaut tout est aussi en lecture seul, donc à moins de jouer du sudo comme un goret c’est assez compliqué de casser quoi que ce soit.







Ce n’est pas en lecture seule. C’est juste qu’il y a un système de droits qui empêche les simples utilisateurs de modifier les fichiers nécessitant d’être root. Ce qui ne protège donc pas d’un malware qui exploiterait une faille permettant une élévation de privilèges ou, comme dit précédemment, une simple coupure de courant au mauvais moment, voir une erreur de la distribution elle-même (toutes y ont déjà eu droit, comme Manjaro ou Fedora, mais on pourrait en citer plein d’autres).


votre avatar

C’est intéressant ce concept, même si je ne me vois pas l’utiliser au quotidien. De toutes façons, il est bien dit dans l’article que c’est quelque chose d’expérimental, dont acte.



Il me paraît envisageable que cela devienne le mode de fonctionnement des OS d’ici quelques années, l’isolation des logiciels dans des conteneurs avec leurs dépendances, pour qu’ils n’emportent pas le système avec eux en cas de pépin, ça paraît intéressant au non-spécialiste que je suis. Bien que je n’ai jamais rencontré moi-même ce problème sous Linux depuis bientôt 15 ans…



Après, je ne suis pas un spécialiste de la chose, et je suis ouvert à tous les avis argumentés sur la question. À suivre…

votre avatar

Ce fonctionnement a cependant un problème, au delà de l’esapce de stockage grandissant des applications. En effet, l’effort de mise à jour des bibliothèques n’est plus portée par le système mais par les développeurs. S’il y a une faille sur l’une d’elle, un OS va souvent le patcher rapidement, les développeurs ne s’empresseront pas toujours. De plus cela ne les incitera pas à forcer la compitibilité avec les nouvelles versions des dépendances s’il est plus simple pour eux de garder les anciennes en cas de non rétrocompatibilité. En plus j’imagine la taille des mises à jours quand un openssl changera de version et que les 15 applications que tu as qui l’utilise redescendront en même temps.



Je reste donc partagé sur le principe, d’un côté c’est génial et de l’autre ça demande trop de faire confiance en matière de sécurité à des développeurs pour qui ce n’est pas forcément le travail.

votre avatar

Ça ressemble fortement à QubeOS quand même. Pour du serveur je vois clairement l’intérêt, qui est de fournir une meilleure isolation des services. Pour de la workstation par contre…

votre avatar

Donc, d’après les concepteurs de Fedora, l’avenir de Linux (en tout cas, de leur distribution), c’est de faire comme Windows* en ce qui concerne le processus de mises à jour (téléchargement puis installation mise en attente pour être effectuée au redémarrage de l’OS, dans un environnement où l’utilisateur n’a pas la main et où la machine est inutilisable pour autre chose en attendant) ? J’en connais déjà qui vont hurler… :/



* Et pas seulement lui : c’est aussi le cas sur Android, PlayStation 4…



Quant au fait que même le rajout de polices de caractères nécessite un redémarrage pour être effectif… :/ Ils ont intérêt à arranger ça d’ici à ce qu’ils considèrent cette déclinaison Silverblue comme mûre !



Linux, c’était mieux avant c’est plus ce que c’était…

votre avatar

Pas du tout, l’installation via rpm-ostree se base sur des overlays, liens matériels et clichés du système. D’ailleurs ostree est souvent surnommé git du binaire. Donc en fait quand tu changes ton système, tu fais un changement d’état. Ce changement est indolore et instantané et tu peux revenir en arrière sans problèmes. D’ailleurs GRUB peut maintenant proposer les différentes versions de ton système pour revenir facilement en arrière si nécessaire.



Il n’y a donc absolument pas la latence de Windows là dessus qui repose sur des mécanismes très différents.



L’article est bien fait, par ailleurs je suis en train d’en rédiger un à ce sujet. Cependant il oublie (volontairement ou pas) des éléments. Silverblue et Atomic puisent leurs origines dans Fedora.next qui était la période de brainstorming de Fedora en 2013-2014. Silverblue n’est que la concrétisation de ce travail mais n’est aussi qu’un aspect et un test.



Il n’est pas sûr que Silverblue parvienne à devenir la version de Fedora Workstation par défaut. C’est l’objectif mais les difficultés restent nombreuses et tout le monde ignore si on pourra aboutir à ce que l’on souhaite.



Ensuite, l’objectif aussi de la distribution est de reposer au maximum sur les Flatpak et podman. Le système immuable doit être le plus minimal possible (dans l’idéal il n’y aurait que le noyau, le chargeur de démarrage et le système d’init et ce qui est nécessaire pour eux). Ce qui contourne la limitation liée à rpm-ostree.



Les conteneurs, surtout les Flatpak, devraient user de portails et de droits d’accès pour faire des actions nécessaires en dehors du conteneur. Mais c’est encore en développement et pas opérationnel. Fedora travaille aussi pour que les paquets RPM de logiciels graphiques génèrent automatiquement un Flatpak associé pour augmenter la quantité de logiciels disponibles via les dépôts de Fedora dans Silverblue. Mais ce n’est pas encore pleinement opérationnel.



Toolbox et podman sont plutôt dédiés dans l’idée aux outils de développements et aux codeurs. Genre si tu veux coder une application qui utilise Python 3.6 pour le contexte professionnel.



Très clairement Silverblue n’est qu’expérimental et reste un travail de R&D essentiellement. Il y a bien du chemin à parcourir avant d’envisager que Silverblue devienne la version de référence voire unique de Fedora Workstation.

votre avatar







Trit’ a écrit :



Donc, d’après les concepteurs de Fedora, l’avenir de Linux (en tout cas, de leur distribution), c’est de faire comme Windows* en ce qui concerne le processus de mises à jour (téléchargement puis installation mise en attente pour être effectuée au redémarrage de l’OS, dans un environnement où l’utilisateur n’a pas la main et où la machine est inutilisable pour autre chose en attendant) ? J’en connais déjà qui vont hurler… :/







Pas forcément, sur NixOS tu peux rebuild et appliquer ta configuration sans devoir rebooter (et heureusement). Après je ne sais pas sur quoi s’appuie Silverblue.



Moi j’ai un peu de mal à imaginer les clients de Red Hat ou de CentOS passer sur ce système…


votre avatar

L’espace de stockage ne sera pas vraiment un soucis dans les années à venir vu l’explosion de celui-ci sur les stations de travail (surtout si la taille de l’image du système de base + celles utilisées pour les containers diminuent). De plus l’isolation va ajouter une couche de sécurité supplémentaire.



Je suis vraiment curieux de voir ce que cela va donner quand le projet aura plus avancé. C’est réellement un concept intéressant qui peut avoir un grand intérêt dans un cadre de dev/QA.

votre avatar

« Dans un paquet isolé du reste du système, on embarque tout ce dont elle a besoin. »



Ce n’est pas totalement vrai. Flatpak propose le concept de runtimes. Pour le moment il en existe trois : Freedesktop, GNOME et KDE. Le runtime Freedesktop contient par exemple Python, SDL, SQLite, Vulkan, OpenSSL, Mesa… et un paquet d’autres bibliothèques.



Quand il y a une faille dans l’une d’entre elles, le runtime est mis à jour et l’ensemble des Flatpak qui en dépendent bénéficient donc de la mise à jour. Ce n’est donc pas à chaque développeur de tout embarquer et de gérer lui-même la sécurité de l’ensemble des bibliothèques qu’il utilise.

votre avatar

Espace de stockage peut être, mais pour les temps de chargement et l’utilisation de la RAM c’est la fête du slip.

Le flatpack est la négation même des librairie partagées.

votre avatar

Même si je reste encore un adepte des paquets autant que possible, perso je ne vois pas grande différence au quotidien avec les quelques snap que j’ai sur mes machines niveau conso RAM/temps de chargement, etc (alors qu’ils sont plus lourds que les flatpack).

Bien sûr que ça va bouffer plus que des paquets. En contre partie ça permet aussi de garder son système propre, et dans certains cas c’est bien utile.



Sinon cf le commentaire au-dessus du tiens.

votre avatar

Oui Flatpak va de fait réduire l’usage de bibliothèques partagées, du moins pour les moins connues car sinon les runtimes gèreront cet aspect de la manière la plus efficiente possible.



Mais il y a une raison aussi à cette conception, c’est que les bibliothèques partagées c’est sexy sur le papier mais ça a des inconvénients non négligeables. C’est à cause d’eux qu’il est difficile de distribuer une application proprement sous Linux entre les distributions car les dépendances et les versions diffèrent.



Puis cela génère des bogues, car le développeur de l’application X et celui de Y même s’ils utilisent la même bibliothèque, ils n’ont probablement pas développé et testé avec la même version. Or choisir une version commune aux deux peut engendrer des bogues difficiles identifier et à résoudre.



Et générer ces paquets, près de 10 000 pour Fedora seulement, demande beaucoup de travail que ce soit pour créer et maintenir ces paquets tout comme l’infra. Flatpak permet d’alléger la tâche, car ce travail peut être fait plus facilement par le développeur de l’application même ou par une mutualisation des efforts (comme Flathub) qui touche toutes les distributions.



Bref, Flatpak (et plus largement Silverblue) est une remise en cause de la distribution traditionnelle. C’est un but assumé. Car il y a des problèmes avec le modèle traditionnel qui ne sont solubles qu’avec une remise en cause de celui-ci. Et encore il y a tentative d’essayer de concilier les deux aspects au maximum, car cela reste des modèles antagonistes. De toute façon chaque distribution fera le choix d’adopter ce changement ou pas, il n’y a pas de contraintes, donc il y a aura toujours moyen de rester comme avant pour ceux qui le veulent.

votre avatar

Je suis tout à fait d’accord.

Vu la taille des disques actuellement, l’espace utilisé par les conteneurs, bien que beaucoup plus important, n’est pas un problème à considérer.

Par contre, la charge de la mise à jour change de main (du système aux développeurs d’applications) ce qui compromet fortement la sécurité pour l’utilisateur (car les développeurs ne mettront pas à jour leurs applications aussi rapidement que Red Hat).&nbsp;

Quand on parle de sécurité améliorée pour les systèmes de conteneur, c’est par rapport à l’intégrité du système (qui ne risque plus de subir des modifications erronées) mais les applications et les données, sont elles beaucoup moins sécurisées de cette façon, car mises à jour de façon trop disparates.

Tant que la charge de mise à jour des applications conteneurisées dépendra des développeurs, ce type de système n’aura pas de réel avenir.

votre avatar

L’avenir que dessine Red Hat pour sa distribution de bureau est techniquement original avec de nombreuses innovations pour le « bureau Linux » (conteneurisation, bac à sable, système inaltérable, flatpak…). Le rôle de laboratoire de développement de Fedora est bien perceptible, d’autant plus que cela s’intègre dans la réorganisation récente du monde des distributions soutenues par Red Hat (Fedora, Cent OS, Cent OS Stream, RHEL).



&nbsp;      

A contrario, pour l'autre mastodonte du milieu, Canonical, on ne voit pas trop où veut aller l'entreprise avec Ubuntu sur le bureau. Priorité est mise sur l'IoT, la virtualisation, les snaps mais le bureau semble marginalisé depuis l'abandon d'Unity et de la convergence bureau-mobile. Certes, il demeure bien une petite équipe dédiée au desktop qui améliore les outils existants (GTK et notamment gnome-shell) mais mis à part une compilation de logiciels libres livrée tous les 6 mois (dont une version LTS tous les 2 ans) étiquetée « Ubuntu », l'entreprise ne me semble pas avoir de grands projets ambitieux sur long terme pour la version bureau de sa distribution.

Silverblue : le futur de Fedora, mais une route encore longue

  • La philosophie derrière Silverblue

  • Présentation générale de Fedora Silverblue

  • Créer ses propres conteneurs

  • Une distribution pour l’instant surtout destinée aux développeurs

  • L’étrange statut de Silverblue pour l’instant

Fermer