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.
Sommaire
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’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.
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.
Le projet Atomic
Genèse
En 2014, le projet Atomic 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. 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 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 !
Aller plus loin
- Site de Fedora Silverblue (221 clics)
- Site officiel du projet Fedora (73 clics)
- Site officiel de la communauté francophone de Fedora (79 clics)
# Mais où est CoreOS ?
Posté par Coles . Évalué à 2.
Tout d'abord, j'ai trouvé l'article plutôt intéressant. Mais je suis surpris de retrouver Atomic sans même une mention de CoreOS. Pourtant, ce premier a été déclarer en fin de vie en novembre en faveur de CoreOS.
[^] # Re: Mais où est CoreOS ?
Posté par Renault (site web personnel) . Évalué à 8.
Attention à ne pas tout confondre. Je ne suis pas expert du sujet d'autant que la terminologie est ici assez confuse. J'espère ne pas me planter.
D'abord Silverblue tire origine du projet Atomic d'un point de vue historique, il est normal de parler d'Atomic car c'est évidemment comme cela que ça s'est construit.
Ensuite, de ma compréhension, le projet Atomic en tant que tel n'est pas mort. D'ailleurs Atomic en lui même n'est qu'une collection d'outils, d'une conception particulière. Silverblue utilise toujours ces outils et n'a pas changé de conception non plus.
Ce qui a changé c'est que Fedora Atomic, qui est le nom de l'ancien Fedora Cloud en se basant sur le projet Atomic, a changé pour devenir Fedora CoreOS. Pour notamment tirer profit de CoreOS qui a été racheté par Red Hat et dont le but de ce système collait parfaitement avec le besoin de Fedora Cloud / Atomic. Ce qui en tant que tel n'a pas d'impact pour Silverblue car c'est un produit indépendant. Et Silverblue ne cherche pas à exploiter CoreOS car le but diffère quelque peu sur ce point : sa cible c'est un ordinateur personnel, pas d'être en lui même dans un conteneur pour lancer une application.
# Petite faute
Posté par Cetera . Évalué à 4.
Cela alourdi → cela alourdit.
[^] # Re: Petite faute
Posté par antistress (site web personnel) . Évalué à 7.
Râââ le lourt !
[^] # Re: Petite faute
Posté par Davy Defaud . Évalué à 2.
Corrigé, merci. C’était loin d’être la seule faute. ;-)
# Merci Renault
Posté par bepolymathe . Évalué à 10.
Après avoir lu l’article, je me rends compte que j’ai bien mieux compris de quoi il retournait. Merci Renault pour tout le travail pédagogique et associatif que tu fais pour la communauté Fedora !
[^] # Re: Merci Renault
Posté par Renault (site web personnel) . Évalué à 5.
De rien, ravis que ça plaise ! Merci.
[^] # Re: Merci Renault
Posté par dinomasque . Évalué à 5.
Super article en effet !
Quand j'ai vu les massifs blocs de texte, ma peur du TLDR s'est activée.
Mais en fait ça se lit très bien : c'est super bien écrit et on sent que le sujet est maîtrisé.
BeOS le faisait il y a 20 ans !
[^] # Re: Merci Renault
Posté par Davy Defaud . Évalué à 3.
Ravis ?! Pourquoi, vous êtes plusieurs comme Tyler Durden ?
# Intéressant
Posté par lierre . Évalué à 0.
Très intéressant, merci ! Ça me rappelle un post de Poettering sur le même problème. Ils ne sont jamais à cours d'idée chez Redhat ;)
Bon, ceci dit, le modèle de paquet actuel nécessite un gros boulot pour les distributions, mais pour l'utilisateur, c'est un bonheur de simplicité. Pouvoir gérer de multiples versions de tout, c'est une souplesse sans doute appréciable, mais c'est aussi le début du chaos.
[^] # Re: Intéressant
Posté par antistress (site web personnel) . Évalué à 4.
En flatpak cela se fait de façon très organisée et contrôlée
[^] # Re: Intéressant
Posté par ʭ ☯ . Évalué à 2.
cad? Comment flatpak fait-il les mises à jour de sécurité des différentes versions de qt utilisées par différentes applications flatpakéees?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Intéressant
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 08 mai 2020 à 12:37.
Une application est liée à un ou plusieurs runtimes (contextes d'exécution en français dans la dépêche).
Par exemple Freedesktop, KDE (pour Qt, car il n'y pas Qt seul) + codecs
Les runtimes reçoivent des mises à jour comme les applis
Et tu peux avoir différentes versions installées d'un même runtime, servant des applis différentes.
Chez moi : $ flatpak list
Name Application ID Version Branch Origin Installation
Video Downloader com.github.unrud.VideoDownloader 0.2.8 stable flathub system
VidCutter com.ozmartians.VidCutter 6.0.0.7 stable flathub system
Transmission com.transmissionbt.Transmission 2.94 stable flathub system
Scribus net.scribus.Scribus 1.5.5+ stable flathub system
Audacity org.audacityteam.Audacity 2.3.3 stable flathub system
Codecs org.audacityteam.Audacity.Codecs stable flathub system
Avidemux org.avidemux.Avidemux 2.7.4 stable flathub system
FileZilla org.filezillaproject.Filezilla 3.48.0 stable flathub system
Freedesktop Platform org.freedesktop.Platform 19.08.10 19.08 flathub system
default org.freedesktop.Platform.GL.default 19.08 flathub system
Intel org.freedesktop.Platform.VAAPI.Intel 19.08 flathub system
openh264 org.freedesktop.Platform.openh264 2.0 flathub system
Frozen Bubble org.frozen_bubble.frozen-bubble 2.213 stable flathub system
Éditeur d’image GIMP org.gimp.GIMP 2.10.18 stable flathub system
Outil de sauvegarde Déjà Dup org.gnome.DejaDup 40.6 stable flathub system
Extensions org.gnome.Extensions 3.36.2 stable flathub system
GNOME Application Platform version 3.34 org.gnome.Platform 3.34 flathub system
GNOME Application Platform version 3.36 org.gnome.Platform 3.36 flathub system
Shotwell org.gnome.Shotwell 0.30.8 stable flathub system
Adwaita theme org.kde.KStyle.Adwaita 5.14 flathub system
KDE Application Platform org.kde.Platform 5.14 flathub system
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.14 flathub system
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.14 flathub system
LibreOffice org.libreoffice.LibreOffice 6.4.3.2 stable flathub system
Thunderbird org.mozilla.Thunderbird 68.8.0 stable flathub system
Firefox org.mozilla.firefox 77.0b3 beta flathub-beta system
Pitivi org.pitivi.Pitivi 0.999 master pitivi-origin system
VLC org.videolan.VLC 3.0.10 stable flathub system
[^] # Re: Intéressant
Posté par barmic 🦦 . Évalué à 2.
C'est un avis tout à fait personnel, mais je trouve que les runtimes standards/classiques/supportés son beaucoup trop gros. Grosso modo quand on en voit la taille et comment ça a était fait, c'est fait pour avoir des distributions linux relativement complète (c'est presque l'équivalent de
kde-plasma-desktop). Ça donne l'impression que c'est avec des œillères, il y a d'autres solutions qui existent depuis plus longtemps ça aurait était intéressant de faire un état de l'art avant de pondre quelque chose et pas que d'un point de vu technique mais aussi d'un point de vu écosystème. Et ailleurs on voit que la taille de ces choses là est importantes.L'autre point qui est dommageable amha c'est le fait de complètement orienté la techno pour les bureaux. Ça complexifie le travail des distributions qui ne sont pas particulièrement orientée bureau. Elles doivent jongler avec ces 2 profiles qui sont tout à fait arbitraires.
Pour un travail qui se veut standard et issu d'un consensus (contrairement à snap par exemple), je trouve que ça aurait pu être bien mieux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intéressant
Posté par Renault (site web personnel) . Évalué à 4.
Pour info n'importe qui peut créer ou maintenir un runtime pour en avoir des plus petits s'il le juge nécessaire.
Ensuite, par essence, une application KDE ou GNOME va faire appel à pas mal de bibliothèques que les autres applications de cet écosystème utilisent aussi. Ces écosystèmes étant gros, les runtimes le font aussi. Mais si tu utilises beaucoup de ces applications ensemble, finalement tu seras proche de la taille d'installation qu'avec ta distribution préférée aujourd'hui.
Donc oui pour installer une application en Flatpak seulement, ce sera un gros poids en plus. Mais si ton système repose dessus (comme c'est le cas avec Silverblue) finalement ça devient intéressant.
L'état de l'art a été fait, et Flatpak a trouvé des solutions pour conserver la flexibilité d'installation, avoir un bac à sable tout en évitant d'avoir un système trop lourd et difficile à maintenir en terme de sécurité. Aucune solution existante ne permettait de gérer tout ça à la fois. Surtout l'aspect bac à sable par ailleurs qui est manquant et non trivial à implémenter.
[^] # Re: Intéressant
Posté par barmic 🦦 . Évalué à 2.
C'est pour ça que je parle des classiques/standards/supportés et oui je ne l'ai pas dis mais ce n'est pas forcément un problème systémique, ça peut évoluer.
Je sais bien et je me doute que le choix est fait pour simplifier la vie des développeurs qui ont moins de question à se poser. C'est important quand comme c'est le cas de flatpak tu es bon dernier arrivé. Si tu embête les développeurs, ton store restera vide et ne servira à rien.
Mais malgré ça cette taille pose des problèmes. Par essence flatpak est fait pour gérer de la profusion et de la simplicité pour l'utilisateur. Avoir plusieurs versions d'une même application, installer la petite application Qt alors que ton bureau est gtk,… Ce sont des comportements explicitement encouragés par flatpak (ce qui est bien), mais les runtimes vont se multiplier. L'espace disque c'est pas chère, mais tu le vois à l'usage. Télécharger et installer en 3s ou en 30s ça n'a rien à voir en terme de ressenti pour l'utilisateur que celui-ci soit un utilisateur final ou un développeur.
Et si je parle de Qt ce n'est pas pour rien. Il existe des applications juste Qt, est-ce qu'il vaut mieux qu'elles utilisent KDE qui est immense pour elles, mais qui augmente la potentielle réutilisation ou bien une plus petite qui va tuer la réutilisation mais être plus légère pour ceux qui n'utilisent pas KDE.
Je ne parle que flatpak en soit et pas de silverblue, mais même lui est sujet à ce problème il l'est juste moins.
Ce n'est pas ce que j'ai dit. J'ai dit que je vois les même travers que les débuts de docker en particulier et que je ne serait pas surpris que dans les prochaines années on voit les même mouvements. Le contexte est différent et on peut imaginer que ça n'arrivera pas et c'est tout ce que je leur souhaite, mais j'en serais surpris.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intéressant
Posté par yabb85 . Évalué à 0.
Personnellement le poids des images flatpak m'a pas mal freiné. Les mises a jours étant de taille conséquentes (de 1 a 3 Go) et ceci presque toutes les semaines. De plus l'espace disque ne coûte pas cher dans une tour mais sur un laptop c'est différent. Hormis les modèles pro, il est souvent impossible de rajouter de l'espace sur un laptop grand publique. Vu qu'ils sont actuellement vendus avec des SSD a 256Go ça fait pas énorme si ont veut stocker un peu. Donc pour workstation c'est sûr, pour desktops beaucoup moins.
[^] # Re: Intéressant
Posté par lierre . Évalué à 4.
Ce que je veux dire c'est qu'avoir plusieurs versions de quelque chose c'est intrinsèquement plus compliqué que d'en avoir qu'une. Les distributions font un gros boulot pour qu'à un instant T tout marche avec une seule version de chaque paquet, et ça simplifie énormément la vie de l'utilisateur. Je comprends que ce travail soit de plus en plus contraignant et difficile à mener, mais si on l'abandonne, on ne fait que transférer un fardeau sur l'utilisateur.
Par exemple, les environnement virtuels Python ont réglé de nombreux problèmes, mais quand on analyse, on a simplement transféré un fardeau sur l'utilisateur. On a dit voilà, puisque personne ne peut organiser cette masse de paquets incompatibles, de versions de python incompatibles, on va donner des sceaux aux utilisateurs pour qu'il puissent trier le fumier eux-même sans que ça pue dans toute la maison.
Un autre exemple concret, c'est la configuration des paquets. Mon GTK, je le configure comment s'il n'est pas présent au niveau du système mais au niveau de chaque application ? Sur quelle version je me base pour savoir ce qui est valide au non ? Le travail de la distribution passe à l'utilisateur.
[^] # Re: Intéressant
Posté par ff9097 . Évalué à 0.
Tu es donc contre quelque chose comme Docker également ?
Les paquets flatpak ne sont pas isolés à 100% du host, ils peuvent avoir accès à certaines informations.
Mais ce n'est pas open bar comme maintenant, où n'importe quel processus à accès à tous ce qui appartient à l'utilisateur
[^] # Re: Intéressant
Posté par Kerro . Évalué à 4.
À quel moment tu as lu qu'il est contre ?
[^] # Re: Intéressant
Posté par Laurent Mouillart . Évalué à 3. Dernière modification le 08 mai 2020 à 16:32.
Justement je trouve qu'avec flatpak pour l'utilisateur c'est plus simple.
Déjà la séparation entre OS, application/runtime globale, application/runtime par utilisateur est très simple.
Ensuite si je prends l'exemple de Pitivi, celui-ci nécessite souvent des versions assez précises de bibliothèques. C'est totalement trivial et transparent en flatpak. Avec des dépendances aur, deb ou rpm, c'est très souvent cassé. Idem pour avoir simplement plusieurs branches en //.
En utilisation flatpak ça fonctionne très bien depuis bien 2-3 ans. Les snap la dernière fois que j'ai essayé, c'était encore bien laborieux, en termes de rapidité de lancement, homogénéité des thèmes, qualité, suivi des versions des logiciels …
En plus avec flatpak ça permet d'avoir strictement le même fonctionnement et donc les mêmes jeux de données, configurations, … entre les distributions sur une même architecture.
Donc en temps qu'utilisateur c'est vraiment bien plus simple et souple qu'un système de paquets à l'ancienne.
[^] # Re: Intéressant
Posté par antistress (site web personnel) . Évalué à 4.
et aussi pour aider les dév à déboguer du coup, puisque utilisateur et dév roulent exactement la même version
[^] # Re: Intéressant
Posté par barmic 🦦 . Évalué à 2.
Le problème n'est pas le système de paquet et flatpak ne sera pas une solution. Si le runtime sur le quel s'appuie Pitivi est mis à jour avec une version d'une dépendance qui le casse tu ne pourra pas le mettre à jour (même si ce nouveau runtime fixe des CVE ou apporte une version d'une autre dépendance qui elle t'apporterait quelque chose). Ça n'est qu'à peine plus enviable et c'est la situation que tu as déjà en moins bien avec une distribution stable.
Ce que t'es entrain de dire c'est que les distributions font mal leur travail. C'est possible, mais je pense que si on envisageait sous ce biais là on pourrait parler de solutions très différentes et potentiellement bien différentes.
Tu apprends dans les journaux qu'il y a une CVE critique sur libBiduleTruc. Ils viennent de sortir les versions 1.2.123, 1.4.3 et 2.0.4 qui corrige la faille. Comment tu t'assure de ne pas l'avoir ? Qu'est-ce que tu fais de pitivi qui va planter avec la dernière version des runtimes ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intéressant
Posté par Renault (site web personnel) . Évalué à 3.
Une application Flatpak a une dépendance à une version du runtime. Ce runtime en théorie pour une version donnée ne doit proposer que des mises à jour avec une ABI conservée. En gros les seuls correctifs sont des failles de sécurité ou des bogues.
Donc il n'y a pas de raison qu'une mise à jour du runtime casse l'application qui en dépendait.
Si l'ABI est mis à jour ou que le correctif est plus important, le runtime change de version. Les applications maintenues utiliseront la nouvelle version dès qu'ils seront compatibles avec celui-ci et les non maintenus pourront utiliser l'ancien.
Donc cela fonctionne très bien, tu gardes la possibilité d'avoir un système assez à jour tout en évitant de casser ton application à cause d'une maj pour laquelle la dite application n'est pas prête.
Les distributions font d'ailleurs beaucoup de travail, parfois bancal pour s'assurer que l'ensemble fonctionne. Car à quelques exceptions près, toute application doit utiliser la même version d'une bibliothèque alors qu'elles ont rarement été développées pour ces versions. Donc cela requiert beaucoup de tests, de correctifs manuels dans tous les sens pour s'assurer qu'elles seront fonctionnelles. Beaucoup de maj ont du retard à cause de cela : le nécessaire doit être fait avant pour que tout fonctionne en bloc.
Flatpak apporte la possibilité de le faire en plusieurs étapes. Les applications très maintenues peuvent bénéficier très vite des derniers correctifs, les applications qui le sont moins en profiteront quand elles seront prêtes. Et entre temps, l'utilisateur peut profiter de toutes ses applications.
Comme je l'ai précisé dans l'article, le fonctionnement traditionnelle d'une distribution n'est pas magique. Elle fait un compromis qui a ses avantages et inconvénients pour l'utilisateur comme les mainteneurs. Flatpak propose un autre modèle, avec aussi ses avantages et inconvénients. Aucune solution n'est parfaite et universelle. Il est bon de le reconnaître.
[^] # Re: Intéressant
Posté par barmic 🦦 . Évalué à 2.
Ça c'est en théorie. L'ABI ne fait pas tout et les problème sus-nomé de pitivi ne sont pas au niveau de l'ABI je présume.
C'est là dessus que travaillent les distributions stables.
C'est exactement ce que tu décris, ils restent sur la même ABI donc comme tu le dis plus haut il n'y a pas de raison que ça ne marche pas hors effectivement ça ne marche pas.
Beaucoup de tests oui bien sûr si tu prend debian tu ne peux pas envisager 60k paquets et un logiciel de la même façon c'est évident. Mais en terme de correctifs manuels, je ne crois pas qu'il y en ai tant que ça (je serais intéressé de regarder). Debian s'est fait connaître à cause de plusieurs histoires là dessus, mais cet éclairage important sur quelques cas donne une fausse impression qu'il y a beaucoup de modifications.
Il peut profiter de ces vielles applications des failles de sécurité qui vont avec, de l'occupation disque des runtime devenu obsolètes,… En soit cette flexibilité a un coût avec ou sans flatpak, c'est quelque chose à assumer.
On est tout à fait d'accord. Je ne viens pas dire que les distributions sont la solution. Flatpak est une brique très intéressante, il faut tout de même être conscient de ses limites et que c'est une solution encore jeune qui va encore évoluer en fonction de son usage et des problèmes rencontrés (la création de paquet ne semble pas toujours aisée d'après devnewton - ça fait aussi parti de ce qui me donne l'impression que la démarche loin d'être universelle a était de remplir les besoins des application Gnome et KDE -).
Je ne suis moi même pas sur une distribution vanilla et utilise une distribution stable pour l'énorme majorité de ce que j'utilise et installe moi-même les quelques logiciels dont j'ai besoin qu'il soit à jour. C'est ma façon de faire et je ne doute pas qu'elle ne convienne pas à tout le monde.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intéressant
Posté par Renault (site web personnel) . Évalué à 5.
L'ABI ne fait pas tout, en effet.
Mais bon si le comportement applicatif reposait sur un comportement erroné de la bibliothèque (et dont la correction pose soucis) ou que un changement de comportement essentiel casse les utilisateurs de la bibliothèque dans une version mineure, le problème est insoluble. Et étant donné que ce serait très problématique, je doute que cela soit le cas souvent.
Les problèmes d'ABI ou de changements plus profonds sont quant à eux déjà bien plus fréquents.
C'est difficile à faire et parfois elles n'y parviennent pas.
Debian est sans doute la distribution populaire qui a le plus de correctifs en interne. De part ses objectifs et sa taille. Elle a sa réputation à ce sujet et ce n'est pas infondé.
Par ailleurs, mon boulot fait que je touche beaucoup à Yocto voire buildroot donc les problématiques des distributions avec le support et l’intégration qui va avec je connais plutôt bien. La quantité de correctifs internes pour chaque paquet est immense. Il n'y a pas de raisons que Debian avec ses contraintes propres n'en aient pas plus encore !
La vie est faite de choix. Personnellement ça m'amuse un peu les positions extrêmes car elles renient souvent le droit de faire des compromis, ou de le faire de manière différente. Même si tu mets de l'eau dans ton vin par après, cette partie reste assez typique.
La sécurité n'est pas un tout absolu, je conçois qu'un gars préfère utiliser un logiciel qui a quelques failles connues si cela lui permet de faire son travail (ou ses loisirs) en attendant que le correctif arrive (s'il arrive).
L'avantage de Flatpak c'est aussi de cloisonner. Ce cloisonnement n'est pas une protection absolue mais elle permet justement de limiter la surface d'attaque d'une part, et le potentiel des dégâts d'autre part.
Puis niveau sécurité dans l'informatique, exiger l'infaillibilité en permanence est une chimère. Travaillant dans l'embarqué, je le vois. La plupart des box Internet utilisent des noyaux antédiluviens avec une pile réseau pas maintenue à jour (ou du moins, pas suffisamment !), peu de téléphones ont la dernière version du système dans la nature car la maintenance a toujours une date de fin et que pas tout le monde abandonne son périphérique quand cela arrive à échéance. Et je ne parle pas des gens qui ont des Windows ou macOS pas à jour sans parler des applications dessus. Et changer tout ça pour avoir une sécurité convenable est sans doute possible, mais ça aura un coût de formations et financier. :)
Et dans ce petit monde, qui met à jour le BIOS ou l'UEFI ? Pourtant des correctifs de sécurité du constructeur, il y en a plusieurs les premières années après le lancement du produit.
Et tu voudrais que le monde applicatif de Linux soit rigide pour apporter un petit gain de sécurité potentiel au détriment du reste ? Bof. Je ne crois pas que cela soit une démarche très cohérente en fait. Sauf dans des cas très précis où la sécurité doit passer avant le reste.
Je ne dis pas que l'ancien monde des distributions va et doit disparaître. Je pense que comme tout, il y a des compromis et que selon l'objectif il faudra choisir l'un ou l'autre.
Personne n'a dit ici que Flatpak était parfait, mature et allait tout remplacer. ;) Même pas moi. J'utilise des Flatpak avec bonheur mais j'ai bien conscience de ses défauts et de ses limites actuelles aussi.
[^] # Re: Intéressant
Posté par antistress (site web personnel) . Évalué à 3.
Sur un point précis, je ne comprends pas bien ce mic mac autour de la version Flatpak de GNOME Web
https://github.com/flathub/flathub/pull/1147#event-3318431061
Si t'as compris qqch, je veux bien que tu m'expliques !
[^] # Re: Intéressant
Posté par Renault (site web personnel) . Évalué à 4.
Apparemment le mainteneur d'Epiphany (et de son Flatpak) a retiré Epiphany de Flathub. La raison est que GnuTLS a reçu des MaJ de sécurité que le runtime de Freedesktop ne veut pas mettre à jour car l'API a légèrement changé (de nouvelles fonctions seulement, pas de retrait ou de changement de comportements).
Or pour lui le navigateur Web doit être proposé si GnuTLS est à jour pour des raisons de sécurité. Pourquoi pas, ça se défend.
Et ensuite une longue tirade sur qui est responsable de la situation et devrait le corriger. Pas très pertinent. La conclusion est que le retour d'Epiphany sur Flathub se fera à cette condition.
[^] # Re: Intéressant
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 09 mai 2020 à 01:54.
Sauf qu'il vient d'être déposé sur FlatHub !
Je pense que mcatanzaro va se fendre d'un billet dont il a le secret.
Le dév flathub dit que les correctifs sont couramment intégrés mais je crois que ça suffit pas, et mcatanzaro a cette réponse : "nobody is responsible for security response" mais je ne comprends pas ce qu'il entend par là ?
[^] # Re: Intéressant
Posté par Renault (site web personnel) . Évalué à 3.
Après rien n'empêche quelqu'un de Flathub de pousser Epiphany sur leur dépôt. Même si mcatanzaro est contre par principe. Tout comme Zenitram ne peut pas envoyer boulet Fedora si mediainfo est poussé dans les dépôts dans les conditions qui ne lui plaisent pas en terme de qualité par exemple.
Ce n'est pas clair comment ça a été fait ici.
Je présume qu'il se plaint que Flathub n'a pas une équipe orientée sécurité pour s'assurer du suivi en cas de problèmes ? Ce que les distributions ont en général.
Mais c'est ambigüe je trouve aussi.
[^] # Re: Intéressant
Posté par antistress (site web personnel) . Évalué à 3.
ha oui, sans doute
merci !
[^] # Re: Intéressant
Posté par ff9097 . Évalué à 1.
Pourquoi refuser une mise à jour si le comportement ne change pas ?
[^] # Re: Intéressant
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 09 mai 2020 à 08:00.
Il ne s'agit pas d'une position extrême, juste de pointer une limite. C'est dommage de tenter de mettre du personnel dans la discussion. Comme tu le dis c'est un compromis et c'est ce que j'ai voulu exprimer en parlant d'assumer.
J'utilise avec parcimonie flatpak. Paspparce que je ne veux pas m'en servir plus mais parce que j'en ai pas besoin de plus. Si un logiciel n'est pas dispo dans ma distribution ou pas dans la version qui me convient je suis là procédure du site officiel etje ne me plain pas.
Il est là ton extrémiste qui exige quelque chose.
Dans mon travail quand je prends une décision, je produit architecture decision record qui décrit le choix et sa raison d'être et pointe les limites connues. Tu aura remarqué que cette question n'est pas dans les 2 points que je trouvais dommage dans flatpak un peu plus haut.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intéressant
Posté par barmic 🦦 . Évalué à 2.
Hum ? virtualenv n'est pas fait pour l'utilisateur de ce que je crois en savoir. Donc rien est transféré à l'utilisateur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Réduction du domaine de la lutte
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Aujourd'hui c'est vrai à cause de l'enfer des environnements d'exécution et bibliothèques partagées. Mais demain?
Je vois dans ma boule de cristal que bientôt toutes les applications seront écrites avec un langage comme Go, Rust ou Cristal qui permettent de créer un gros binaire avec toutes les bibliothèques liées statiquement.
Je vois aussi que les langages interprétés ou octetcompilés permettront aussi de faire ces "obèsebins", par exemple avec l'aide d'Appimage.
Si nous sommes bien dans cette ligne temporelle, est-ce qu'il ne faudrait pas faire sauter la ring "stack" ? Ou en tout cas ne pas trop investir de temps dessus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Réduction du domaine de la lutte
Posté par Renault (site web personnel) . Évalué à 3.
De plus en plus oui, mais totalement j'ai de gros doutes.
Oui et non.
Pour l'utilisateur d'une application tu as raison et techniquement Flatpak comme Toolbox s'en chargent déjà.
Le problème est pour les développeurs. Quand tu développes ton logiciel avec Python tu as besoin d'un accès à crrtains composants et potentiellement en plusieurs versions. Tu gères ça comment ? Il te faut quelque chose qui gère la couche Stack pour ça, ici Toolbox.
[^] # Re: Réduction du domaine de la lutte
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je ne connais pas Toolbox, mais j'avais testé flatpak : https://linuxfr.org/nodes/118997/comments/1795082
Je change de langage :-) Plus sérieusement, c'est pas le rôle de pip/venv?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Premières impressions et interrogations
Posté par Gauthier (Mastodon) . Évalué à 1.
J'ai décidé d'installer Silverblue pour avoir une vision objective de son utilisabilité.
Sur un autre disque, j'ai toujours mon ancien système, basé sur Fedora également, mais avec d'autres contraintes qui ne sont pas négligeable non plus.
Pour ceux qui connaissent c'est Qubes-OS. C'est un OS vraiment sécurisé, prévu pour bien cloisonner ses usages. Mais Qubes-OS nécessite une machine puissante avec beaucoup de mémoire. De plus il est parfois compliqué de faire tourner certaines applications.
Premières impressions:
Mes interrogations:
[^] # Re: Premières impressions et interrogations
Posté par Renault (site web personnel) . Évalué à 3.
Oui et c'est expliqué pourquoi. ;)
Comme expliqué dans l'article suivant sur la mise en pratique de Silverblue, en fait pour une première application d'un écosystème type GNOME ou KDE, la première fois tu vas télécharger le runtime qui contient les bibliothèques communes avec les autres applications. Du coup pour la 2e application, le poids sera proche de la normale.
Snap n'a pas ce comportement par conception mais c'est un inconvénient dans le cas d'un système qui a beaucoup d'applications installées ainsi.
En effet mais je crois avoir vu des idées pour résoudre ce problème via le système hôte. À voir. :)
Je ne sais pas, mais je dirais que cela devrait être possible via les overlays de rpm-ostree. Essaye et raconte !
Il n'y a pas de contre indication même si cela n'a pas été prévu pour. Il faudra probablement l'installer à la base du système avec rpm-ostree au préalable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.