Et si le système d’exploitation (OS) libre et souverain dont le monde a besoin était basé sur GNOME ? C’est ce que propose Thibault Martin dans un billet posté le 28 février 2025 sur son blog. L’idée est ambitieuse, et bien entendu elle peut froisser les gens qui préfèrent d’autres environnements de bureau, mais elle présente l’intérêt de s’appuyer sur deux tendances notables dans l’actualité récente de Linux : l’avènement des systèmes atomiques et la demande d’un OS dit “souverain”. Nous vous proposons, à travers le billet de Martin, d’en apprendre plus sur ces deux tendances. Ce premier journal se concentre sur la première : les systèmes atomiques, et le changement de paradigme qu’ils préfigurent pour le bureau Linux.
Sommaire
De quoi ça parle ?
Dans ce billet titré « Prosthetics that don't betray » (« des prothèses qui ne trahissent pas »), Thibault Martin, ancien membre de la fondation GNOME, appelle à changer la gouvernance du projet pour se donner les moyens d’en faire un OS “indépendant” et prêt à l’emploi, financé par l’Union européenne. Il est question ici de vendre des ordinateurs et des téléphones avec un système Linux pré-installé dessus, assemblé par et basé sur GNOME, indépendant de toute distribution existante, et le tout idéalement financé par l’Union européenne (« ça se verrait à peine dans son budget », argue Martin).
Pourquoi GNOME ? Parce que c’est l'environnement de bureau préféré de Martin, évidemment. Il vante notamment sa bonne intégration au mobile : on l’ignore peut-être (car il reste nettement plus difficile d’installer un Linux sur un téléphone que sur un PC), mais les développeurs GNOME travaillent depuis quelques années à rendre leurs applis adaptables aux petits écrans. Il ne s’agit pas de versions différentes, mais bel et bien de vos applis de bureau, qui se redimensionnent automatiquement pour être utilisables à l’écran tactile. Nick du Linux Experiment en a récemment dit du bien dans une de ses vidéos. Bien entendu, il existe d’autres interfaces mobiles dans le monde Linux, au hasard celle de KDE, Plasma Mobile. Mais ce n’est pas sur cet argument que cette dépêche aimerait s’attarder ; plutôt que de parler des avantages et inconvénients de GNOME sur les autres environnements graphiques libres, nous allons nous pencher sur deux autres idées avancées par Thibault Martin dans son billet, à savoir :
- pour être « utilisable par les masses », cet OS de rêve doit adopter une technologie dite “atomique”
- sa vocation principale sera d’échapper à « l’hégémonie américaine » et « sécuriser la souveraineté numérique de l’UE »
Les OS atomiques, ou la promesse du Linux qui juste-marche
C’était le 25 février dernier, et il l’a dit au premier degré : "We believe that 2025 is truly the year of the Linux gaming desktop ». Pourtant, Nirav Patel précise bien cinq secondes avant que ses ordinateurs (il est le fondateur et le PDG de Framework) supportent aussi Windows. Mais il a l’air de sincèrement croire que cette année, quelque chose de différent est en train de se passer avec le bureau Linux ; et sur la diapo où est écrite cette phrase, on peut voir les logos de Playtron OS et Bazzite, deux projets de Linux orientés “gaming”, mais qui présentent aussi la particularité d’être basés sur Fedora Silverblue, sans doute le plus populaire des Linux atomiques.
À moins que ce ne soit l’inverse ? Le 13 février dernier, Jorge Castro, fondateur du projet Universal Blue (dont est issu Bazzite), montrait fièrement les statistiques des appareils actifs sous Fedora atomiques (si vous ne le saviez pas, toutes les installations de Fedora envoient par défaut un signal anonyme aux serveurs afin d’être recensées). On y voit les machines sous Bazzite doubler de nombre entre octobre dernier et février, dépassant de loin les propres variantes atomiques officielles de Fedora (mais encore très loin derrière “la” Fedora Workstation ordinaire, selon Castro).
Bazzite a tellement la cote qu’elle a été saluée comme « mettant la honte à Windows » dans un article sur The Verge, ce qui est surprenant de la part d’un média tech “généraliste” qui jusqu’à présent n’avait d’yeux que pour les GAFAM et ne s’intéressait guère au monde du libre. Il y a, bien sûr, une explication simple à ce succès : Bazzite vise une niche particulière, celle des utilisateurs et utilisatrices de Steam Deck et autres consoles portables à base de technologie PC, et on peut arguer que cette niche est non seulement en pleine croissance, mais aussi peut-être un peu délaissée par un Microsoft qui n’a pas encore bien optimisé son Windows à un tel cas d’usage. Ce serait comme attribuer la hausse des téléchargements de Linux il y a 15 ans à la mode des netbooks. Mais nous aimerions arguer ici que le succès de Bazzite est aussi dû à son choix technologique de bureau atomique.
Pour rappel, “atomique” est l’expression qui tend à remplacer celles d'“immuable” (traduction anglaise d'"immutable") ou "image-based", et qui désigne une façon bien particulière de construire et distribuer un système d’exploitation. Solène Rapenne propose une définition dans un billet de 2023, où elle résume les principes essentiels des systèmes immuables :
- les mises à jour système ne sont pas effectuées sur le système en cours d’utilisation (celui-ci n’est jamais censé changer, d’où le qualificatif d'“immuable”)
- les modifications de paquets sont appliqués au prochain démarrage (mais pas celles des Flatpak par exemple)
- vous pouvez revenir en arrière (roll back) et restaurer le système dans l’état exact où il se trouvait avant une mise à jour
Les systèmes atomiques peuvent avoir chacun leurs particularités : ainsi, NixOS (lisez à son sujet notre récente dépêche), Endless OS, les images Universal Blue, Vanilla OS, MicroOS ou encore AerynOS, mais aussi ChromeOS et Android ne fonctionnent pas tout à fait de la même façon, bien qu’ils partagent ces trois principes en commun. Mais le gros joueur dans ce domaine, c’est Fedora : Renault nous expliquait il y a bientôt cinq ans comment les expérimentations du projet ont donné naissance à Silverblue et comment ce dernier s’utilisait. Depuis, Silverblue a été décliné en versions Plasma, Sway, Budgie et bientôt COSMIC et Plasma Mobile ; certaines de ses briques sont amenées à évoluer, comme l’expliquait Timothée Ravier à la sortie de Silverblue 41 en automne dernier (voir la section Notes), mais les principes fondamentaux restent les mêmes, et vous pouvez les retrouver décrits dans la documentation commune (en version bêta) des Fedora atomiques. Ravier les rappelle dans un récent entretien qu’il nous a accordé (à paraître après le 21 avril) et nous partage son espoir de voir un jour l’atomique devenir le modèle par défaut pour Fedora :
Je l’espère ! Il est impossible de donner une échéance et cela ne dépend pas vraiment de moi. La difficulté la plus importante est la prise en charge du matériel et les pilotes qui ne sont pas intégrés dans Fedora. C’est un problème que l’on ne peut pas résoudre dans Fedora à cause des contraintes légales et qui sont traitées par le projet Universal Blue, dont la variante Bazzite est très populaire.
Capture d’écran du site officiel de Bazzite
Les possibilités ouvertes par cette approche sont telles qu’elles inspirent beaucoup de Linuxiens à assembler leur propre bureau Linux atomique, y compris hors des mainteneurs de distributions : c’est le cas de Jorge Castro et de Thibault Martin. Mais Martin n’est pas le premier à avoir eu l’idée parmi la communauté GNOME : il cite un billet d’Adrien Vovk paru en octobre dernier, titré « Un bureau pour tous », et qui appelle déjà à s’appuyer sur GNOME, et plus précisément le projet GNOME OS (lequel est déjà atomique), pour « construire un OS qui rend le bureau Linux utilisable pour les non-passionnés » :
Je pense à mes amis et à ma famille : ils ne méritent pas plus que nous d’être maltraités par les entreprises de la tech. Beaucoup d’entre eux adorent l’idée de Linux et sont d’accord avec nos valeurs, mais ont décidé de ne pas rester dessus après l’avoir essayé pour de vrai. Ils sont intéressés, mais juste pas assez intéressés pour surmonter nos barrières à l’entrée. Ils se moquent des paquets, des codecs, des pilotes, des brevets, des licences, ou de toutes ces choses qui sont devenues ce qu’on doit gérer en tant que passionnés de Linux. Je crois que beaucoup se mettront à se préoccuper de ces choses-là une fois qu’ils auront rejoint nos communautés, comme nous l’avons tous fait nous-même, mais à l’heure actuelle, ils ne nous rejoignent pas…
L’idée ne séduit pas que chez GNOME : Vovk dit lui-même avoir été inspiré par KDE, après que ceux-ci aient annoncé un projet similaire lors de la conférence Akademy en septembre 2024, sobrement baptisé « KDE Linux ». Et pour pallier les défauts que les devs reprochent à KDE neon, laquelle vieillit trop vite du fait d’être basée sur Ubuntu LTS, KDE Linux sera donc, lui aussi, un OS atomique et immuable : « les applis viendront de Flatpak (et peut-être aussi de Snap si ce n’est pas trop difficile et que l’UX est convenable) ». Et lui aussi aura vocation à s’adresser au plus large public possible, « des développeurs KDE aux utilisateurs et aux vendeurs de matériel ».
Or, pour atteindre un tel objectif d’universalité, Vovk considère que GNOME OS se doit d’être complètement immuable, sans permettre à l’utilisateur d’installer des paquets traditionnels, contrairement au « modèle immuable-hybride en vogue » qui est celui de Silverblue et ses dérivés (où il est possible de faire du layering pour installer des paquets de la distribution, faisant ainsi entorse à l’immuabilité) :
À mon avis, permettre l’overlay de paquets dissuade le développement de vraies solutions permanentes aux fonctionnalités manquantes dans l’OS, puisque les utilisateurs peuvent juste se reposer sur les surcouches. Au bout du compte, la nécessité d’installer des paquets pour contourner ces problèmes va juste garantir que personne n’utilisera les distributions immuables-hybrides de manière immuable, ce qui annule les bienfaits de l’immuabilité tout en soumettant l’utilisateur aux points de friction [sharp edges] supplémentaires qu’apporte l’immuabilité.
Comme le rappelle Vovk, cette idée a déjà été formulée par le fameux Lennart Poettering en mai 2022, dans un long billet où il détaille sa vision personnelle (« et non celle de mon employeur », qui à l’époque était soit Red Hat, soit Microsoft) de la direction dans laquelle le bureau Linux doit aller :
Avant toute chose, je pense qu’il faut se concentrer sur un design basé sur une image plutôt que sur des paquets. Pour la robustesse et la sécurité, il est essentiel de travailler avec des images reproductibles et immuables qui décrivent l’OS ou des grandes portions de celui-ci dans leur entièreté, plutôt que de toujours travailler avec des paquets détaillés façon RPM/dpkg. Ce n’est pas dire que les paquets ne sont pas pertinents (je trouve en réalité qu’ils ont beaucoup d’importance !), mais je pense qu’ils devraient être moins un outil de déploiement de code, mais plutôt un outil pour construire les objets à déployer. Une autre manière de voir la chose : tout OS construit ainsi doit être facile à répliquer sur un grand nombre d’instances, avec une variabilité minimale.
C’est donc bien un nouveau paradigme qui bouleverse les principes traditionnels des distros, selon lesquels les empaqueteurs se chargent d’assembler et distribuer toutes les applications qu’ils veulent rendre disponibles à leurs utilisateurs. Or, dans les préconisations de la documentation de l’outil Blue-build, dédié à la création d’images atomiques customisées, il faut au contraire « résister à la tentation d’intégrer tout l’univers » :
Les systèmes dans ce genre sont conçus autour d’un cœur petit, simple et efficace, maintenable et performant. Rappelez-vous que les mises à jour de l’image de base nécessitent un redémarrage, donc idéalement vous allez vouloir limiter sa taille – laissez Flatpak et d’autres outils de l’espace utilisateur s’occuper du reste.
Diapositive issue de la présentation « Bazzite: Building the Future of Linux Gaming Together » donnée par Kyle Gospodnetich et Noel Miller au salon SCALE 22x, le 8 mars 2025
Jorge Castro dit lui-même :
Je ne voulais pas refaire une autre distro. J’ai fait ça pendant dix ans [chez Canonical, NDLR], je ne voulais pas faire d’empaquetage, je comprends les difficultés que ça entraîne de faire une distro, je ne veux plus jamais refaire ça.
Il nous faut avoir des applis en bac à sable, sans quoi autant faire nos valises et rentrer chez nous. Actuellement c’est flatpak via flathub. Malgré toutes les plaintes que vous pouvez lire sur le net au sujet de flatpak, il y a plein de monde qui en tire une bonne expérience. […] Et aussi nous avons abandonné tout l’aspect « allons empaqueter la planète entière nous-même » du modèle parce que nous savons que ça ne s’étend pas [it doesn't scale]. Ça veut dire que c’est aux développeurs d’applis de prendre en charge leur destin, et que c’est notre boulot de livrer tout ça à l’utilisateur. […] C’est aussi pour cela que nous ne sommes pas une distro – nous sommes trois distros, fedora pour la base, homebrew pour la ligne de commande, flatpak pour les applis à interface graphique. Oh et puisque vous avez aussi distrobox, n’importe quel autre paquet de distro.
Et évidemment, cet éloignement revendiqué du modèle de la bonne vieille distribution n’est pas sans causer quelques frictions, surtout au sein d’une communauté comme Fedora qui demeure avant tout dédiée à faire… une bonne vieille distribution. Le 21 janvier 2025, Michael Catanzaro demandait que Flathub devienne le dépôt Flatpak par défaut des Fedora, plutôt que le dépôt Flatpak de Fedora comme c’est le cas jusqu’alors, affirmant que ces flatpaks “maison” étaient « une source notable de problèmes de qualité », et citant des « plaintes de multiples développeurs upstream », notamment ceux du célèbre OBS qui sont allés jusqu’à réclamer formellement le retrait du Flatpak que Fedora distribue pour leur appli. Le conflit s’est depuis détendu et les développeurs d’OBS ont rétracté leur demande, mais pas sans que le Project Leader de Fedora Matthew Miller ne déclare sur la chaîne YouTube de Brodie Robertson que « les règles d’acceptation sur Flathub sont plutôt laxistes » et que rien ne garantissait l’absence de code malveillant dans leurs flatpaks, ce qui a provoqué une levée de boucliers et une clarification officielle de Flathub quant à leur processus de vérification. Miller a salué cette clarification et précisé sa pensée, et à l’heure actuelle, c’est toujours les dépôts de Fedora qui sont présélectionnés par défaut lorsqu’on cherche à installer un Flatpak via Logiciels ou Discover dans une Fedora.
Alors, faut-il imaginer un projet tout neuf et émancipé des distributions, comme GNOME et KDE aimeraient le faire, pour être digne d’être l’OS atomique dont l’Europe a besoin ? À moins que ce dont l’Europe ait besoin, ce n’est pas d’un seul mais de plusieurs OS atomiques ? C’est l’idée que défend openSUSE, qui propose aux gouvernements non pas d’adopter une seule et unique solution qui "surfe sur l’idée de souveraineté européenne", mais plutôt une stratégie multi-distributions, qui inclurait, au hasard, les propres projets atomiques d’openSUSE – Aeon (sous GNOME) et Kalpa (sous Plasma) :
L’idée globale dont les gouvernements ont besoin de débattre va au-delà du standard des distros. À l’âge du rançongiciel, du verrouillage dans le nuage et du capitalisme de surveillance, il est temps d’aller au-delà de la façon traditionnelle de penser les OS de bureaux. Le monde de l’open-source a déjà les outils pour avancer vers cette nouvelle façon de penser :
- L’immuabilité avec des mises à jour transactionnelles (MicroOS, Aeon, Kalpa, Kinoite)
- Une configuration système déclarative (Agama, Ansible)
- Des options de bureaux pour des besoins utilisateur variés (GNOME, KDE Plasma, Xfce)
- Des standards d’identités et d’authentification ouverts (LDAP, OpenID)
- Des formats de paquet transparents (Flatpak, RPM)
La gouvernance des Linux : suffit-il d’être libre pour être souverain ?
Ce second volet fera l’objet d’une dépêche future, à laquelle vous pouvez d’ores et déjà contribuer (comme à toutes les autres dépêches en cours de rédaction sur Linuxfr). À bientôt !
Notes
- Les Steam Deck sont vendus avec SteamOS, qui n’est pour l’instant pas disponible au téléchargement (Valve a déclaré vouloir le faire d’ici avril 2025), et qui est également un OS atomique. Bazzite est fortement inspiré de SteamOS et en reprend directement une partie de son code, publié sous licence libre par Valve.
- Un des signes distinctifs d’Universal Blue est son usage de bootc, qui permet purement et simplement de rendre des conteneurs bootables (ce que Jorge Castro résume par « Podman dans une boucle for » ; Colin Walters en parle dans une vidéo de Red Hat) et qui devrait bientôt être adopté par Fedora à son tour, en remplacement d’OSTree. Sur la feuille de route de ce projet, Timothée Ravier précisait en janvier dernier que, bien que ses propres machines reposent sur des conteneurs bootables, il considère que « ce n’est pas prêt pour l’usage général ».
- À l’heure actuelle, la distribution vitrine de Linux sur téléphones est sans doute postmarketOS. Les développeurs de celle-ci ont annoncé le 30 mars dernier travailler à une version immuable de pmOS, qui sera partiellement subventionnée par la fondation européenne NLnet (la question du financement des Linux sera abordée dans la 2ᵉ partie de cette dépêche).
# Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+10/-0). Dernière modification le 07 avril 2025 à 11:47.
Merci pour cette définition, qui mériterait de figurer en haut de l'article.
Le dernière point est très intéressant, en revanche, pour les deux premiers, j'ai dû louper le moment où le fonctionnement à la Windows, où il faut redémarrer pour appliquer des mises à jour, avait commencé à être considéré un modèle.
Sérieusement, il y a des gens qui aiment ça, devoir redémarrer pour mettre à jour des logiciels ? Quel intérêt ? Relancer les logiciels concernés, évidemment. Redémarrer l'ordinateur si le logiciel concerné est le noyau, évidemment. Mais redémarrer dans tous les cas, ça ressemble à du masochisme.
[^] # Re: Atomique ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4 (+2/-0). Dernière modification le 07 avril 2025 à 12:10.
C'est parce que ça ne concerne pas "tous" les cas, seulement ceux où tu touches à l'image système. Les flatpaks, les snaps, les paquets Homebrew, pip et consorts (sans parler des conteneurs comme Toolbx et Distrobox) ne nécessitent aucun redémarrage. L'idée, c'est de privilégier ces canaux-là dans ton usage quotidien.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+11/-0).
Ah, parce que ça va avec le concept de système vs applications. Typiquement le genre de truc que je n'ai jamais réussi à comprendre et qui à mon sens ne fait qu'ajouter de la complexité.
S'il y a bien un truc que je trouve super sous Debian et autres, c'est bien le fait que tout, y compris le noyau et la libc, vient de paquets qui se gèrent de la même façon.
[^] # Re: Atomique ?
Posté par octane . Évalué à 2 (+2/-2).
Un système (windows, mac, linux) et des applications (firefox, openoffice, vi, etc..), c'est au contraire d'une simplicité désarmante. Dire que tout est pareil et doit être traité pareil, ça n'amène que de la confusion.
Des fois j'aime bien BSD pour ça: un système homogène, et des ports. Quelque fois j'aimerai un système à l'android: le système se met à jour de manière un peu magique, de temps en temps il couine en disant "met moi à jour, gros", et à côté de ça j'installe des applis sans me poser des questions depuis un store. Indépendemment de la mise à jour. Je veux une appli todo list, je cherche todolist dans le store, je clique, ça marche.
Parceque bon, pitié quoi, mais t'installes un truc avec apt-get et ça te conseille d'installer libtruc et donner les droits root et/ou au passage te demande d'activer les statistiques d'utilisations des logiciels avec un message qui te dit que t'as eu beau faire apt-get update && apt-get upgrade le paquet linux-image sera pas mis à jour parceque lol.
Que tu te dis tiens j'installe une calculette et que ça te tire l'intégralité de gnome avec, oué, il y a un problème et les gens préfèrent snap.
Franchement, je veux un bouton "mise à jour" et un équivalent du store (genre synaptics). Tout le reste devrait être planqué et utilisé par "les gens qui savent (tm)". Tout le reste, c'est du n'importe quoi.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9 (+6/-0).
Un noyau et des trucs en espace utilisateur, ça je comprends. C'est d'ailleurs à peu près la seule distinction réellement fondée. Bon, ok, on peut aussi distinguer l'init et le considérer comme copain du noyau. Et éventuellement la libc, et encore, ça se discute.
Mais le reste, que ce soit la libgtk3 ou le compositeur utilisé par ton gestionnaire de bureau, ça n'a rien de si particulier qui en ferait un truc à considérer comme faisant partie du « système ». Ou alors, je demande à voir quel serait le critère, pour que ça ne dérive pas selon la sensibilité du lecteur.
Jamais eu ce genre de problème.
Ah ben si telle calculatrice dépend de plein de choses de Gnome, bonne nouvelle, en Snap ça va être pareil en fait. Juste au lieu d'installer une calculatrice de 5 Mio et 1 Gio de dépendances, ça va installer un Snap unique qui inclut 1 Gio de dépendances.
Le problème ne vient pas des paquets mais bien du logiciel amont.
[^] # Re: Atomique ?
Posté par Renault (site web personnel) . Évalué à 7 (+4/-0).
Le critère dans la plupart des projet atomique c'est que le système qui fonctionne en atomique est le minimum pour démarrer le système et qui soit fonctionnel pour l'utilisateur.
Mais bien sûr ça dépend des usages.
Pour un usage bureautique c'est afficher un bureau où tu peux télécharger / mettre à jour / supprimer des applications. C'est logique en même temps, si un utilisateur novice n'a pas accès à son environnement graphique il ne pourra rien faire, le système est non fonctionnel et il faut revenir à l'état précédent. Si GNOME Shell ne démarre pas car le lien mesa-GTK3 est cassé avec le pilote graphique Intel, le système n'est pas fonctionnel.
Pour un usage serveur ou conteneur, c'est le système minimal qui initialise le matériel et logiciel qui permet de démarrer l'application (ou les applications) souhaitées. Donc là pas besoin d'interface graphique dans la base du système. Le système de base sera plus léger.
En fait tu te concentres sur le critère technique alors qu'ici on se base sur "l'expérience". La notion de système dépend de l'usage que sera fait de l'ordinateur. Pour un serveur inclure GNOME Shell dans la notion de système n'a pas un grand intérêt, pour un utilisateur bureautique ça l'est. Il est donc normal qu'il y a de 'larbitraire car l'objectif est justement de s'adapter à des cas d'usages différents.
Et d'ailleurs, suffit de regarder les autres systèmes. Oui tu parles de Linux+systemd+libc = système sous Linux. Mais sous Windows, le système c'est un tout. C'est le noyau de Windows, son environnement graphique, quelques applications de base, etc. Pareil pour macOS, pour Android, iOS, etc. Et pour beaucoup d'utilisateurs je pense que le curseur de systèmes / application sera différent du tien. En fait tout est arbitraire, la question est de savoir ce qu'on veut faire fonctionnement parlant.
Se concentrer sur l'espace noyau + quelques outils autour c'est trop restrictif, tu ne fais rien avec ça.
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
C'est beaucoup plus souvent une question d'empaquetage et c'est très bien. Les mainteneurs le font pour appliquer une certaine cohérence. D'autres distributions font autrement et c'est génial d'essayer d'autres choses.
Comment est ce que Debian choisi ce qu'il y a derrière gnome-desktop ? C'est tout à fait arbitraire. Ça ne les empêche pas de le faire, c'est leur subjectivité et c'est bien pour ça qu'ils font une distribution.
C'est le boulot même des distributions de faire ce genre de choix
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Atomique ?
Posté par Renault (site web personnel) . Évalué à 9 (+6/-0).
Alors il y a des différences avec Windows en fait.
Tout d'abord c'est juste la base du système qui est concernée. Noyau, libc, systemd, etc. C'est la couche 0 du modèle d'un système atomique qui répond à ce critère. Cela ne touche pas le reste. Donc à priori ce n'est pas tous les jours que tu auras un tel changement.
D'autre part, la mise à jour fonctionne par état. En gros c'est comme "git" pour le code d'un projet, la mise à jour est juste un rebase à partir d'une branche spécifique. Le rebase se fait lorsque le système tourne normalement. Le redémarrage ne sert qu'à changer le commit de référence pour exécuter le système. En gros au redémarrage c'est quasiment instantanée, contrairement à Windows où ça prend du temps. Car la partie longue aura été faite quand l'ordinateur est utilisé normalement.
Avec ce fonctionnement, comme cela a été expliqué, l'avantage c'est que de revenir en arrière est fiable et tout aussi rapide si c'est nécessaire. Cela peut même se faire automatiquement si la machine est incapable de booter entièrement avec le nouvel état du système.
Enfin, oui l'approche de Windows reste théoriquement une bonne approche malgré tout. Des bogues qui arrivent et qui sont difficiles à corriger ou à identifier car on met à jour lorsque que le système tourne, cela arrive même sous Linux. Et si ton système crashe en pleine mise à jour pour X ou Y raisons, les problèmes peuvent vite s'accumuler. Appliquer les mises à jour quand le système est dans un environnement minimaliste réduit ces problèmes, en terme de fiabilité c'est mieux quoiqu'on en pense.
L'avantage ici c'est que la partie minimale du système nécessite une telle approche tout en restant fiable et le redémarrage reste une opération très rapide ce qui limite l'inconvénient de Windows.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+2/-1).
Oui, ça je m'en doutais. Ça vient avec le fait que c'est conçu de façon réfléchie, pas comme Windows qui a évolué sans réflexion initiale pour ce genre de problème.
Et ça nécessite vraiment une distinction artificielle entre logiciels de base et logiciels supplémentaires ?
C'est sûr que Windows est réputé pour être vachement plus fiable.
La mise à jour d'un logiciels, c'est du remplacement de fichiers, et ça se fait très bien en fonctionnement. Pas en réécrivant directement les fichiers, évidemment, mais en les installant avec un nouveau nom puis en retirant les anciens et en renommant les nouveaux.
[^] # Re: Atomique ?
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Oui.
L'objectif est d'améliorer aussi la robustesse, la sécurité et la fiabilité.
Si tu mets trop de composants dans le système de base, tester dans le détail l'intégration c'est compliqué. Plus de risques qu'il y ait des problèmes profonds qui peuvent compromettre le démarrage de la machine, processus de mises à jour plus lentes car rebaser avec des application en plus c'est lent.
L'objectif est qu'un maximum d'applications soient distribuées via Snap ou Flatpak dans ce modèle. Plus de sécurité grâce à l'isolation logicielle mais aussi plus de flexibilité car si tu souhaites avoir Firefox beta + Firefox stable en même temps sur ta machine c'est facile. Si tu veux le dernier LibreOffice également, tu ne dépends plus uniquement du cycle de ta distribution qui est une contrainte pénible pour beaucoup d'utilisateurs.
Cela paraît simple, mais en vrai ça ne fonctionne pas toujours aussi bien. Car là tu décris le cas idéal. Le cas le plus courant mais il est illusoire de croire que les soucis n'arrivent jamais.
En pratique ce que tu décris se fait déjà, mais il faut voir les problèmes qui peuvent survenir.
Que se passe-t-il si tu as une coupure de courant ou un crash au milieu des opérations ? Pour l'avoir expérimenté, ton système peut être dans un état irrécupérable car tu as des fichiers à jour, d'autres pas pour un paquet, tu as un paquet à jour mais ses dépendances (ou ce qui en dépendent) qui ne le sont pas, la BDD RPM qui est dans un état incohérent, etc.
Une mise à jour implique des scripts notamment de conversions de fichiers, de relance de services et autres et parfois pas de bol il y a un problème ou un conflit avec l'usage normal de la machine et hop pépin.
Ou tu démarres une application alors que certains fichiers sont à jour et pas les autres, ou qu'un paquet est à jour et pas sa dépendance et tu peux avoir des crashes ou bogues bizarres.
Ce n'est pas un hasard si l'industrie migre vers ce genre de conceptions. Dans l'embarqué cela se fait, sur les téléphones cela se fait, Windows le fait, GNOME Logiciels le fait, les systèmes atomiques le font, etc. C'est pour cette raison, pour couvrir correctement les cas où il y a des soucis potentiels.
[^] # Re: Atomique ?
Posté par orfenor . Évalué à 4 (+2/-0).
Aucun problème sous Debian les 2-3 fois où c'est arrivé : il a suffit de relancer la mise à jour. Ça ne prouve rien, j'ai pu avoir de la chance, mais est-ce que la différence des formats de paquets et des outils RPM / dpkg peut expliquer ça ?
[^] # Re: Atomique ?
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Non, car ça m'est aussi arrivé d'avoir le soucis avec RPM et relancer la procédure a fonctionné.
Que tu utilises RPM ou DPKG cela ne change rien car mettre à jour un système c'est une opération +/- longue et que si ça s'interrompt au milieu tu n'as aucune garantie que ça fonctionnera bien après.
La seule solution pour n'avoir aucun problème c'est d'avoir la possibilité de faire une mise à jour de manière atomique d'une façon ou d'une autre : si ça fonctionne, tu utilises le système à jour, si ça n'est pas allé au bout, tu gardes le système tel qu'il était et tu recommences la procédure.
[^] # Re: Atomique ?
Posté par ff9097 . Évalué à 0 (+3/-5).
Ça y est voilà la mauvaise foi
Ce qui n'a rien d'atomique
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+20/-0).
Bon alors pour rappel, la nécessité de redémarrer pour les mises à jour de Windows vient d'une erreur de conception historique : l'absence de compteur de liens et d'ouvertures sur les fichiers, qui sont par conséquent censés avoir un unique nom qui ne peut pas être supprimé tant qu'un fichier est ouvert.
Sous *nix, un fichier peut avoir un nombre quelconque de noms au sein du système de fichiers qui l'héberge. Un fichier a souvent un seul nom, mais il peut en avoir plusieurs, on parle alors de liens physiques. Il peut aussi avoir zéro nom, lorsque son dernier nom a été supprimé ; pour autant il peut continuer d'exister tant qu'il y a encore un processus qui a un descripteur dessus, qui l'a ouvert quoi.
Cela implique d'avoir, pour chaque fichier, un compteur de liens et d'ouvertures, puisqu'un fichier ne peut être supprimé du système de fichiers que s'il n'a plus aucun nom et n'est plus ouvert par aucun processus.
Le rapport avec les mises à jour, c'est qu'avec des compteurs de liens et d'ouvertures, on peut installer une mise à jour d'un fichier
pouet.soavec un nouveau nom, disonspouet.so.new, puis supprimer le nompouet.somême s'il est ouvert par un logiciel, et enfin renommerpouet.so.newenpouet.sosans affecter les processus en cours.Ça, c'est infaisable sous Windows, ce qui pose un gros problème pour remplacer des trucs ouverts en utilisation normale du système. Du coup, on diffère les mises à jour au moment où on est sûr qu'il n'y a pas grand chose d'ouvert, au tout début du démarrage je crois.
[^] # Re: Atomique ?
Posté par fortytwo . Évalué à 6 (+5/-0).
Ben pour moi ce n'était pas un rappel. Depuis le temps que je me demandais pourquoi Windows me gavait… Au moins maintenant j'ai une explication technique !
Grand merci.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
En effet, mais ça peut le devenir en s'aidant de fonctionnalités du système de blocs, genre LVM, ou du système de fichiers, genre Btrfs.
[^] # Re: Atomique ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
L'utilisation de Btrfs est justement la particularité des systèmes atomiques d'OpenSuse.
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à -1 (+1/-4).
Moi j’ai raté le moment où se définir par rapport aux autres était pertinent et où le déshonneur par association était un argument intéressant.
Apple fait tout pour que tu n’éteigne jamais ta machine c’est mieux comme association ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9 (+6/-0). Dernière modification le 07 avril 2025 à 15:29.
Ben oui, beaucoup mieux.
La comparaisons à Windows n'était pas censé évoquer une piètre qualité en général, mais simplement une caractéristique précise assez connue et largement reconnue comme assez mal fichue.
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 2 (+2/-2).
Le fait de devoir redémarré pour avoir une mise à jour n’a jamais était un problème, mais plutôt :
Ce n’est pas le redémarrage en soit qui pose problème mais comment il est fait. Redémarrer pour partir sur la dernière snapshot btrfs c’est indolore.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9 (+6/-0).
C'est très subjectif, ça. Personnellement, j'ai toujours trouvé bien préférable de disposer d'un système où tous les logiciels, y compris la libc et sauf le noyau, peuvent être mis à jour sans interrompre l'utilisation normale, et où ces mises à jour peuvent prendre effet en redémarrant simplement les logiciels concernés.
Après, sur un système qui ne nécessite pas de redémarrage, tu es toujours libre de redémarrer si ça t'amuse. Je ne vois pas l'intérêt, mais vu que ça ne te dérange pas…
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Il n’y a pas de différence notable entre redémarrer et devoir se relogguer parce que mon login shell et/ou mon DE doivent être relancés. C’est une position de principe que de ne pas vouloir redémarrer parce que ça rappel tel ou tel OS.
Pas chez Apple. Mais par principe j’éteins les machines que je n’utilise pas. J’ai beaucoup de RAM et je ne veux pas allouer autant de place à une partition swap pour ne pas faire comme windows.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
Le DE, c'est du vent, c'est juste un tas de logiciels, donc autant préciser de quoi on parle.
Si c'est ton gestionnaire de fenêtres X11 qui a été mis à jour, pas besoin de te reloguer, ça peut se relancer. Si c'est X.Org qui a été mis à jour, là oui, il va falloir se reloguer. Si c'est ton compositeur Wayland, il va falloir se reloguer aussi.
Disons que ce sont les deux seuls cas qui sont presque aussi contraignants qu'une mise à jour du noyau.
Après, si c'est le gestionnaire de fichiers ou un autre outil qui fait partie de ce que tu appelles ton environnement de bureau qui a été mis à jour, aucune raison de se reloguer.
[^] # Re: Atomique ?
Posté par xryl669 . Évalué à 2 (+1/-0).
Et encore, tu peux relancer le compositeur Wayland sans avoir à tuer les applications, vu que, in fine, ce sont les applications qui possèdent leur buffer d'affichage (contrairement à X11). Il existe probablement un protocole wayland pour cela, je ne sais pas s'il est implémenté dans les compositeurs actuels (au moins un, forcément). Rien n'empèche en pratique au compositeur d'avoir un signal qui lui indique de se sérialiser (dans un fichier temporaire) et de quitter pour relancer une autre version en lui passant le fichier temporaire. Au démarrage du nouveau compositeur, il désérialise l'état du système et c'est complètement transparent pour les applications.
De même pour Linux, il existe des tas de solutions pour changer le kernel en live sans redémarrer (typiquement ce qui est fait dans les serveurs cloud, les machines virtuelles ne sont pas interrompues lorsque le porteur redémarre son noyau). Il faut pour cela que les drivers soient capables de correctement sauvegarder leur état et/ou faire un reset propre. C'est exactement la même problématique pour la veille prolongée (hibernation), le noyau sauvegarde ses états sur disque et les recharge en redémarrant. Si tu supprimes la phase "boot" au passage (qui n'a rien à faire lors d'une mise à jour), tu as une mise à jour transparente pour l'utilisateur (au pire, un freeze de quelques secondes pour la récréation des zones mémoires).
[^] # Re: Atomique ?
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Alors le live patching du noyau ça fonctionne mais pas pour tous les correctifs non plus et c'est loin d'être trivial à exploiter.
C'est vraiment conçu comme un moyen de corriger pour de grosses failles ou gros problèmes immédiatement avant de procéder à un redémarrage plus tard à un moment plus opportun comme le weekend ou la nuit par exemple.
De toute façon il faut redémarrer aussi pour la mise à jour de certains composants type systemd ou libc de temps à autres.
La course à l'uptime n'est clairement pas une bonne stratégie de sécurité de nos jours.
[^] # Re: Atomique ?
Posté par fortytwo . Évalué à 2 (+1/-0).
Windows a tout de même un point positif puisque le changement de driver graphique se fait de manière quasi transparente. Je n'ai pratique qu'avec Nvidia, mais je suppose que ça doit être pareil avec les autres.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Le changement de pilote graphique, genre pour le mettre à jour ?
Parce que sinon, passer du pilote libre, enfin, pardon, du pilote propriétaire Microsoft au pilote Nvidia ou je ne sais quoi, c'est le genre d'opération qu'on doit faire genre une fois.
Mais changer de pilote graphique à la volée, chapeau, c'est bien classe en effet.
[^] # Re: Atomique ?
Posté par saltimbanque (site web personnel) . Évalué à 4 (+2/-0).
De manière générale si ton reproche principal tient dans le besoin de redémarrer, NixOS pourrait te satisfaire puisque l'atomicité fonctionne différemment, en versionnant les binaires et configs dans le /nix/store, et il est possible de basculer sur le système mis à jour en live. (Mais NixOS a ses propres contraintes évidemment!)
Sinon je suppose que le débat devrait être précisé - de quels redémarrages parle t'on, ceux d'un serveur, d'un ordi pro, perso, d'un téléphone ou objet connecté? A mes yeux l'enjeu est trop différent pour généraliser le débat.
[^] # Re: Atomique ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+1/-1).
C’est parce qu'il n’à pas donné l’intérêt de l’OS atomique. C’est que l’image de l’os est inchangeable. Cela veut dire qu’un malware ne peut pas insérer son binaire malveillant, il changerait la signature de l’OS.
Actuellement avec le SecureBoot seul la signature du noyau est vérifié dans un OS standard.
En fait l’OS fait tourner des Docker et les Docker peuvent être ajouter en lives. Mais pour un virus ce n’est pas discret d’ajouter un Docker.
Le problème c’est que cela fragilisé la sécurité des applications. Dockerisées elles ne sont pas checkées par la distribution. Alors que quand il faut l’empacketé il faut bien vérifier la version systeme de la lib bidule car elle est partagée avec les autres applications.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Définition de distribution « Atomique »
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Je n'ai pas eu le temps de contribuer à la dépêche, mais j'aurais ajouté :
Ce qui est atomique dans ces distributions-là, ce sont les mises à jour et roll-backs du système. Soit l'opération est faite entièrement, soit elle n'est pas faite du tout. C'est une opération qui est indivisible, « atomique ».
Avec une distrib classique, pendant que les paquets sont mis à jour il ne faut pas qu'il y ait de coupure de courant, sinon le système est entre-deux et il n'est alors peut-être plus possible de le démarrer.
L'implémentation avec OSTree
En interne, OSTree implémente l'opération atomique en changeant juste un lien symbolique. Un lien qui pointe vers le dossier système à utiliser.
OSTree c'est comme Git mais pour des fichiers binaires. Les fichiers du système sont stockés dans la sorte de « base de donnée » avec un système de hash (comme dans
.git/objects/), donc il y a de la déduplication (deux fichiers ayant le même hash seront stockés qu'une seule fois).Au démarrage, le dossier système est créé à la volée en faisant des hard-links depuis la base de données des fichiers OSTree. (Créer des hard-links est une opération très rapide). Une fois que ce dossier est créé, le lien symbolique peut être mis à jour vers le nouveau dossier. C'est cette dernière opération qui est atomique, la création du dossier système en lui-même ne l'est pas.
Quand le système tourne, les mises à jour sont simplement téléchargées dans la base de données OSTree et crée une nouvelle entrée de boot. Donc faire une mise à jour ou un rollback, ça se passe au démarrage, et c'est très rapide, il n'y a pas de temps d'attente.
Voilà pour la petite explication :-)
Explication simple
Pour monsieur et madame tout-le-monde, une explication possible serait : les mises à jour du système sont téléchargées dans un dossier, et puis l'ordinateur démarre dans ce dossier.
« Ben oui c'est évident voyons, pourquoi n'y avons-nous pas pensé plus tôt ?! » ;-)
[^] # Re: Définition de distribution « Atomique »
Posté par mahikeulbody . Évalué à 4 (+2/-0). Dernière modification le 11 avril 2025 à 19:10.
Avec une distribution classique et des snapshots BTRFS […] le système est entre-deux mais il est toujours possible de le démarrer.
# je ne comprends pas trop la logique
Posté par mahikeulbody . Évalué à 9 (+7/-0).
Le titre et la phrase d'introduction mettent en avant Gnome et un Gnome OS Linux idéal mais au final on parle d'atomicité ce qui n'a rien de spécifique à Gnome, du moins j'ai pas vu dans cette partie 1.
[^] # Re: je ne comprends pas trop la logique
Posté par Guillaume Maillard (site web personnel) . Évalué à 4 (+2/-0).
oui, sans compter que "l'atomicité" est loin dans la liste des problèmes de linux sur desktop.
[^] # Re: je ne comprends pas trop la logique
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5 (+3/-0). Dernière modification le 07 avril 2025 à 15:39.
Je dirais que le postulat de base du billet de Martin suggère l'exact contraire. Pour lui (et Vovk, et Poettering, etc.), Linux est trop complexe et trop peu fiable pour être adopté par le grand public, et l'atomicité vient justement résoudre ces problèmes : plus de différences entre les distros (voire plus de distros du tout), plus de conflits de dépendance, plus de mises à jour qui foirent. Dans son raisonnement, c'est la condition sine qua non à l'objectif principal qui est, comme toujours, de permettre à un maximum de monde de se passer de Windows et macOS ; devenir un OS "idéal", donc.
Pour répondre au commentaire précédent : dans sa forme initiale (avant d'être scindée en deux parties), cette dépêche avait d'abord vocation à questionner la proposition de Thibault Martin, mais elle a évolué vers quelque chose de plus descriptif. Au final, il s'agit ici moins de GNOME en lui-même que de la possibilité de voir un "GNOME OS" (ou "KDE Linux", ou Bazzite) supplanter les distros traditionnelles dans les usages grand-public, de par les bénéfices que son approche atomique est censée lui conférer. On retrouvera ça dans la 2e partie de cette dépêche, qui examinera les autres aspects de la proposition de Martin (à savoir, transformer la gouvernance de GNOME pour lui permettre de toucher plus de subventions et d'embaucher les devs du "GNOME OS").
[^] # Re: je ne comprends pas trop la logique
Posté par saltimbanque (site web personnel) . Évalué à 2 (+0/-0).
Concernant Poettering tu fais référence par ex. à son billet https://0pointer.net/blog/fitting-everything-together.html j'imagine, mais est-ce que tu as d'autres sources? je voulais creuser un peu le sujet…
[^] # Re: je ne comprends pas trop la logique
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Pas pour Poettering en particulier. Mes sources sont toutes dans la dépêche. Tu peux aussi checker l'interview de Timothée Ravier dans l'espace de rédaction, ou les futures interventions de Jorge Castro et Jordan Petridis au Linux App Summit qui se tient dans 15 jours. Ou relire ce que racontaient déjà Petridis et Tobias Bernard au LAS de 2019.
[^] # Re: je ne comprends pas trop la logique
Posté par Maderios . Évalué à -1 (+5/-8).
Le terme "Idéal" me laisse rêveur dans la mesure où Gnome est un environnement qui mange 1 GO de ram dès son lancement, qui est lent, qui offre bien peu de possibilités et de personnalisations. On y sent l'influence de Windows, une prétendue simplification qui conduit en fait à recréer un autre type d'usine à gaz. Appliqué à un OS, on voit ce que la démarche "Gnome" pourrait donner. Voilà, Gnome est habillé pour l'hiver :) mais comme je le répète, chacun ses goûts, à condition que certains goûts ne deviennent une norme, même si cette norme est nommée "Linux idéal".
# Atomique ancien
Posté par Zorro . Évalué à 8 (+7/-0).
Quand je lis toute cette hype sur l'atomique et l'immuable, ça me rappelle tellement les Knoppix et les Mandriva Flash.
Ou l'Easy Gate de Neuf-Cegetel, tiens. Il y a 20 ans. Avec son OS installé sur 2 partitions, avec les MàJ qui se faisaient sur l'autre partition, et au démarrage suivant, ça switchait sur cette autre partition, comme ça c'était jamais cassé ; c'était très astucieux, à l'époque… On a vite appelé ce genre d'ordi des stations ou des "ordi pour vieux".
[^] # Re: Atomique ancien
Posté par mahikeulbody . Évalué à 3 (+1/-0).
Avec un système de fichiers pour les nouveaux vieux (btrfs) on peut faire pareil via les snapshots.
[^] # Re: Atomique ancien
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
C'était le projet Stateless Linux (2004). Extrait :
Ce qui a permis la création des live CD notamment.
11 ans plus tard : Planning for an "Atomic Workstation" (Owen Taylor, 2015), qui reparle du projet Stateless Linux et le met en perspective.
# A l'ouest, rien de nouveau
Posté par Singman . Évalué à 5 (+5/-0).
Franchement, présenter une mode cyclique comme une avancée majeure, c'est vraiment ignorer que l'informatique n'est qu'un grand balancier qui oscille régulièrement.
Le mode "atomique" de ces OS n'est pas une véritable nouveauté et profite actuellement d'un effet de mode qui disparaitra aussitôt qu'une légère brise soufflera dans une autre direction. Cette proposition n'apporte que peu d'intérêt pour 90% des utilisateurs, tout au plus laissera t'elle une petite trace dans la future architecture des autres Unix, peut être au niveau de l'organisation des différentes couches du système, et encore…
Bref, vous l'avez compris, je ne suis pas fan du tout :)
[^] # Re: A l'ouest, rien de nouveau
Posté par saltimbanque (site web personnel) . Évalué à 4 (+2/-0).
Pas de souci que tu ne sois pas fan mais en quoi est-ce une mode cyclique qui n'a pas d'intérêt? Les avantages de l'atomicité sont clairs. S'il n'y a pas d'argument sérieux contre alors cela revient à critique systemd simplement parce qu'il représente une nouvelle méthode.. on a vu la suite : tout n'est pas mode cyclique!
# Bref c'est une idée pourrie
Posté par devnewton 🍺 (site web personnel) . Évalué à 1 (+4/-6).
L'idée d'un système atomique réponds à quel problème concret ?
J'utilise Ubuntu ou Debian sur mes PC personnels, professionnels et familiaux depuis une petite vingtaine d'années et la dernière fois que j'ai eu un problème avec une mise à jour, c'était heu… Je m'en souviens pas :-) Les seules pannes que j'ai eu viennent du matériel, en général le disque dur.
GNOME n'est pas pour les michus.
Même mes utilisateurs 100% michus font leurs mises à jour tous seuls depuis des années. En général, ils m'appellent… parce que l'IHM a changé et qu'ils ne savent plus où cliquer. Un problème que je mitige en leur mettant XFCE dont l'UX/UI est plus simple et plus stable que Gnome.
Flatpak, c'est nul. Snap est privateur.
Pour distribuer un logiciel hors distrib, la méthode KISS est de faire une appimage ou un exécutable avec tout lié en statique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bref c'est une idée pourrie
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5 (+3/-0). Dernière modification le 08 avril 2025 à 11:21.
Je dirais ceux-ci :
[^] # Re: Bref c'est une idée pourrie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+6/-5).
Ça pour moi c'est précisément l'exemple à ne pas suivre. Je ne sais pas à quel point c'est lié à cette conception avec un système magique intégré et des applications en bac à sable, mais Android est une horreur à administrer. Même en ayant activé un accès root.
Vous avez déjà essayé de faire des sauvegardes ? Des sauvegardes complètes je veux dire, un truc qu'on peut restaurer en cinq minutes sur un nouvel appareil en cas de panne de votre téléphone.
Il y a des logiciels géniaux pour faire des sauvegardes incrémentales et dédupliquées, personnellement j'utilise Restic. Eh bien, pour utiliser ça sur Android, et écrire dans un périphérique de stockage USB, vous pouvez toujours courir.
Premier problème, installer Restic (ou Borg, ou ce que vous voulez). C'est un outil en ligne de commande, et pas de bol, la ligne de commande, sous Android, n'est accessible que par USB, avec un outil qui s'appelle adb, pour Android debug bridge. Et pas moyen d'installer des logiciels utilisables dedans.
Il y a une solution tout de même, qui consiste à installer Termux, qui est une distribution GNU/Linux pour Android. Et là, Restic est dispo. J'ai quand même l'impression de complètement contourner le système normal de gestion de paquets – pardon d'applications –d'Android.
Enfin, utiliser cet outil pour faire une sauvegarde sur un périphérique de stockage USB. Pas moyen. Termux n'a pas accès aux supports de stockage externe, ne me demandez pas pourquoi. Il faut faire ça par réseau.
[^] # Re: Bref c'est une idée pourrie
Posté par Psychofox (Mastodon) . Évalué à 9 (+6/-0).
Tout ce que tu présentes ici n'a rien à voir et est complètement orthogonal avec le caractère "atomique" de Android.
[^] # Re: Bref c'est une idée pourrie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
Ah, très bien. Je doute que ça s'améliore sur Android, mais du moment que, sur les systèmes GNU/Linux atomiques dont on parle ici, il sera possible d'installer le Flatpak – ou quoi que ce soit d'équivalent – de Restic puis de lancer directement des trucs comme ce qui suit dans une terminal, ça me va.
[^] # Re: Bref c'est une idée pourrie
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Restic est sur Homebrew et fonctionne via Distrobox. Et tu peux même utiliser Restic en GUI avec Déja Dup.
[^] # Re: Bref c'est une idée pourrie
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0).
ça ne résout pas tous les problèmes. On avait depuis longtemps la garantie d'une mise à jour d'un fichier de façon atomique. Et le fait que le descripteur de fichier est valide tant qu'il reste au moins une utilisation. Du coup on pouvait remplacer
libtruc.so.2.0parlibtruc.so.2.1, et même pour les processus utilisant l'ancienne version au même moment, ça allait (par contre le changement effectif nécessitait un redémarrage du processus).Avec du
btrfsou avec une installation séparée dans une autre arborescence (ce que fait Nix), on a une bascule atomique d'un ensemble de fichiers vers un autre (et le retour arrière possible). Donc on élimine les cas où on a mis à jour la moitié des fichiers seulement avant d'être interrompu par une erreur du script, une saturation du disque ou une coupure électrique par exemple. Mais il faut toujours gérer les redémarrages.Et ça ne traite pas forcément le cas des données (si tu migres de TrucSQL v2 à TrucSQL v3, les binaires sont mis à jour, les données sont éventuellement converties avec "pertes", et peut-être que le retour arrière n'est pas prévu…).
Et ça ne traite pas forcément le cas des fichiers utilisateurs (configuration, fichiers temporaires, cache, etc.) : si la v3 ajoute un fichier
trucet que la v2 ne peut pas fonctionner avec ce fichiertrucprésent, et que personne ne personne à l'enlever/mettre de côté pendant le retour arrière, alors ça casse encore.trucpourrait aussi être uncore dumpimprévu par exemple.Et ça ne traite pas le cas des fins de vie : tu mets à jour ton appli parce qu'elle contient/utilise une ressource qui expire (genre un certificat ou une clé GPG), alors le retour arrière ne fera pas de miracle non plus.
Et probablement d'autres cas…
Et comme on ne peut pas avoir toutes les propriétés que l'on veut en simultané, si chaque logiciel vient avec ses propres dépendances "privées" à lui, alors gérer la sécurité globale de tout cela est plus compliqué par exemple.
[^] # Re: Bref c'est une idée pourrie
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1). Dernière modification le 08 avril 2025 à 14:46.
Le lien qui critique les appimages fait comme si Flatpak fonctionnait, mais de mon expérience c'est très mauvais : pas de doc pour java, des applis mal sandboxés, mal intégrés avec l'OS, un flathub façon foire à la saucisse…
Et c'est pire avec Snap.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bref c'est une idée pourrie
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 1 (+0/-1).
À quand remonte ta dernière expérience avec Flatpak ? Parce que dans la mienne, l'intégration à l'OS est nickel (en même temps, j'utilise Silverblue, donc de l'atomique), le sandboxing est bien plus rigoureux qu'à une époque, et pour la "foire à la saucisse" je te renvoie au billet de blog de Flathub linké dans cette dépêche. Je sais que tu as galéré à créer un flatpak pour Newton's Adventure mais de là à dire "il ne faut pas faire comme si Flatpak fonctionnait" alors que Flatpak fonctionne en fait, ça me paraît peu étayé.
[^] # Re: Bref c'est une idée pourrie
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+3/-1).
Perso, mon expérience avec Flatpak, qui se résume à l'utilisation de quelques logiciels qu'Ubuntu a décidé de ne plus distribuer en paquets Debian, c'est en gros : ça marche bien, mais pour ouvrir un truc avec Firefox il faut que je pense à le copier ou à le lier dans le répertoire « Téléchargements » parce qu'il n'a accès qu'à ça.
Bref, rien que du moins bien, mais pas trop quand même.
[^] # Re: Bref c'est une idée pourrie
Posté par Renault (site web personnel) . Évalué à 9 (+6/-0).
Ou alors tu configures les permissions du bac à sable ?
Avec l'application Flatseal par exemple tu peux prendre n'importe quelle application Flatpak et augmenter ou réduire les droits. Tu veux donner accès à tout le système de fichiers de la machine à Firefox ? Tu le peux. Uniquement le répertoire utilisateur ? Tu le peux aussi.
Et c'est justement un gros point fort. Tu utilises une application car tu en as besoin mais tu n'en as pas une confiance absolue (genre logiciel proprio pour le boulot), hop dans le bac à sable avec les paramètres que tu veux.
Ou à l'inverse, Firefox est libre mais c'est gros, ça a des bogues, des failles de sécurité, tu peux réduire au maximum les accès en fonction des besoins pour limiter les dégâts.
Et c'est très bien, c'est un atout réel.
J'ai quand même l'impression que dans ce fil tu n'as pas beaucoup expérimenté et que tu émets des critiques qui n'ont pas lieu d'être. Sans dire que c'est parfait, c'est bien plus puissant et fonctionnel que tu ne le penses.
[^] # Re: Bref c'est une idée pourrie
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 08 avril 2025 à 16:10.
Ça fonctionne, sauf quand ça ne fonctionne pas :-)
Sur le fond, flatpak, snap ou docker, même lorsqu'ils fonctionnent ont, je trouve, le même défaut : ils apportent une couche compliquée qui permets de lancer des logiciels compliqués (trop de dépendances, des builds à la mord moi le Makefile…).
Et si on encourageait plutôt les logiciels simples ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bref c'est une idée pourrie
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Comme on te l'a déjà fait remarqué, et moi même par ailleurs, tant mieux que tu n'as jamais eu de soucis mais ce n'est pas le cas de tout le monde.
Pourtant des AppImage qui ne fonctionnent pas car une dépendance de base du système n'est pas compatible ça arrive, ça m'est arrivée, je crois même te l'avoir montré il y a quelques années quand tu faisais la promo de la techno en commentaire.
Le AppImage KISS et parfait distribuable sur tous les systèmes Linux est un leurre. L'approche de Snap ou de Flatpak qui ont des abstractions pour supprimer ces limitations sont la seule possibilité.
[^] # Re: Bref c'est une idée pourrie
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1). Dernière modification le 08 avril 2025 à 20:06.
Une appimage est plus portable qu'un snap ou un flatpak. Ne serait-ce que parce qu'elle ne dépends pas de snap ou flatpak 😀.
Après les appimages c'est comme l'andouillette, faut que ce soit bien fait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bref c'est une idée pourrie
Posté par saltimbanque (site web personnel) . Évalué à 2 (+0/-0).
appimage c'est cool
Donc finalement les critiques à flatpak ne sont pas si pires. Peut être que flatpak prend un peu de place, oui, mais ça passe certainement en 2025, et appimage bundle aussi. Les soucis d'intégration? 99% dûs au sandboxing, qui est une fonctionnalité supplémentaire de flatpak que les appimage n'offrent pas - et ça va certainement beaucoup mieux maintenant, et ça ira de mieux en mieux puisque flatpak est devenu super populaire. Oui il y a une difficulté mais qui n'est pas la technologie flatpak per se qui serait foireuse mais la volonté d'avoir la sécurité : le débat c'est plutôt ça, sandbox ou pas sandbox.
Bon je suppose qu'on s'en fiche un peu. Si un dépôt offre un appimage + un flatpak, 99,9% des linuxiens vont pouvoir l'utiliser sans peine. Il y a aura bien une âme charitable pour proposer cela au dév et cela sera facile à maintenir. Il y a aura bien un geek pour créer un AUR, celui sous Nix créera tousseul son .nix comme un grand, celui sous Gentoo compilera tousseul comme un grand, et Debian & dérivés vont toutes mourir pour le desktop.
# Enfin !
Posté par pasBill pasGates . Évalué à -3 (+4/-8). Dernière modification le 08 avril 2025 à 11:00.
Cela fait 25 ans qu'on annonce que Linux arrive pour le grand public, ravi d'apprendre que cette fois ce sera la bonne, promis juré !
Tant qu'on est sur le sujet, la fusion comme source d'énergie inépuisable, c'est pour Jeudi c'est cela ?
# Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Andréas Livet . Évalué à 8 (+7/-0).
Autant, je comprends le besoin d'atomicité dans les OS, mais j'ai vraiment du mal à comprendre pourquoi on a chercher à créer des système "bac à sable" dans le monde du libre, si ce n'est pour "autoriser" ou du moins permettre l'utilisation de logiciels potentiellement malveillants sur un OS.
Perso, je suis juste très content d'avoir une distribution linux et c'est un des grands avantages que je met en avant quand j'installe linux à des néophytes : tes paquets proviennent de sources vérifiées, c'est géré par une communauté qui vérifie la qualité de ce qu'ils mettent dedans et comme c'est libre, y a une possibilité d'audit.
Je n'ai pas envie de voir apparaître des distos à la mode Android où tu peux installer toutes sortes de logiciels malveillants et ou Google est juste là pour faire "Market place" et empocher de l'argent.
De plus, il existe déjà des formats de paquets qui gère l'atomicité comme Nix et qui sont déjà installables sur toutes les distros.
Pourquoi alors, ne pas utiliser Nix (ou autre) comme format par défaut, ça me paraît vachement plus simple à créer que flatpak (enfin à ce que j'en ai vu).
Après, j'aime l'idée de laisser au développeur la responsabilité d'empaqueter et de n'avoir au final qu'un format d'empaquetage, ça évite des bugs spécifiques aux distributions, mais encore une fois Nix peut très bien faire ça, et vous savez quoi ? En plus, avec le même fichier Nix, vous bénéficier d'un environnement virtuel de dev !
Donc on peut réunir trois outils (paquet de distribution, environnement virtuel de dev, paquet "universel") en un. J'avoue que j'ai du mal à comprendre pourquoi ce paradigme (qui est plus ancien que flatpak) ne s'est pas plus imposé.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par rewind (Mastodon) . Évalué à 8 (+7/-2).
On est quelques uns à être dubitatif sur le sujet parce que les exemples cités donnent plutôt l'impression d'enfermer l'utilisateur plutôt que de le libérer. Mais c'est pour son bien, paraît-il ! C'est la logique d'Android, c'est la logique de MS et de bien d'autres : limiter ce que peut faire l'utilisateur pour des raisons de «sécurité», et in fine le faire passer par des stores officiels.
Mais grande nouvelle, on peut avoir le même effet avec la liberté en plus, ça s'appelle une distribution Linux, ça existe depuis des lustres. Bref, je ne vois pas l'intérêt du truc non plus.
En fait, on voit bien la contradiction interne du truc : au départ, on crée snap/flatpak/wtf parce que «ouais mais je pouvais pas installer la dernière version de ce logiciel précis parce que ma distrib était pas à jour donc c'est trop bien snap/flatpak/wtf», et puis ça se transforme en «ok, on ne va plus installer que comme ça», et à la fin, «ha merde, on ne peut plus installer tout un tas d'autres trucs qu'on pouvait installer avant». Donc, retour case départ, mais au passage on a perdu en liberté pour l'utilisateur.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Renault (site web personnel) . Évalué à 10 (+8/-1).
Et c'est dans la pratique une bonne chose.
Ton système Linux "libre" ne te permet pas de faire tout et n'importe quoi non plus pour des raisons de sécurité. Tu as des utilisateurs avec des droits différents par exemple et par défaut tu n'es pas superutilisateur. Est-ce mal ? Non bien au contraire.
La sécurité c'est un sujet compliqué, les logiciels sont compliqués, il y a des failles, des bogues ou des logiciels malveillants dans la nature. Je suis plutôt content qu'on réfléchisse à la question des impacts si quelque chose tourne mal. Firefox a une faille, je suis content qu'il ne puisse pas forcément lire tous les fichiers du système dont des données persos par défaut. Et si pour un besoin X ou Y je veux faire ça, je peux le lui autoriser à la volée via un portail ou de manière permanente avec un gestionnaire de permissions.
Je ne vois pas où l'utilisateur a moins de liberté, mais au moins par défaut le comportement est plus sain et plus conforme aux besoins des utilisateurs qui ne s'y connaissent pas techniquement. Car leur demander de sécuriser correctement leur système par défaut, bon courage hein.
Ah c'est sûr quand on balaye d'un revers de la main les avantages de ce système et qu'on minimise les problèmes de l'approche traditionnelle, il n'y a pas un grand intérêt effectivement.
Flatpak et Snap ne sont pas depuis le début juste des paquets universels comme AppImage (ce qui rend d'ailleurs la comparaison frontale entre les deux un peu ridicule car les champs d'action sont différents depuis le départ).
L'approche de la sécurité avec la notion de bac à sable et gestion plus fine des permissions sont là aussi depuis le début en tête et c'est une avancée importante. Le fait de pouvoir installer facilement des logiciels sans droits administrateurs (et donc avec un impact réduit sur le système en cas de défaillance aussi) est également un bénéfice qui a de nombreux cas d'usage.
De toute façon la distro traditionnelle ne disparaîtra pas, et si elle disparaîtra c'est que personne n'a voulu le maintenir en vie pour d'autres raisons. Je pense qu'il y aura une cohabitation des deux approches à long terme selon les besoins. L'atomique ne t'intéresse pas ? Personne ne te force à t'en servir, et personne ne forcera une distro à ne pas fonctionner comme avant. Le code de tout ceci est libre et le restera. L'utilisateur n'a rien à perdre, tout à gagner à avoir le choix justement.
Et c'est bien qu'il y ait des gens qui expérimentent des choses et tentent de proposer des idées nouvelles qui conviendront à certaines personnes même si pas à tous. Il y a des besoins à répondre et les distros traditionnelles ne peuvent pas y répondre en gardant la même approche car il y a forcément des compromis à faire et tu ne peux pas gagner sur tous les tableaux à la fois.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Stéphane Ascoët (site web personnel) . Évalué à -1 (+2/-4).
Mouais, on connaît ce discours hein…
Et quant à dire que c'est ça qui va assurer la popularité de Linux (hors embarqué) pour le grand public, j'ai de gros doutes. Les blocages sont bien ailleurs.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Renault (site web personnel) . Évalué à 7 (+4/-0).
Tu as des éléments de penser que toutes les distributions deviendront atomiques ?
Soyons sérieux, même dans les promoteurs de la techno je ne connais personne qui pense que cela remplacera les distros actuelles entièrement.
Pour que cela remplace l'ancienne manière de faire, ça veut dire que les avantages ont tellement surpassé les inconvénients qu'il n'y a plus assez de mainteneurs pour faire comme avant. On n'y est pas à ce jour et on est loin d'un consensus que cela sera vrai un jour.
Je doute que cela arrive un jour car les avantages et inconvénients de chaque modèle sont impossibles à converger. Donc selon les cas d'usage, une approche sera meilleure que l'autre.
Cela est pourtant utile pour le grand public qui a en fait un bénéfice plus important de cette conception que le lecteur moyen de linuxfr.org. Est-ce suffisant ? Certainement pas, et personne ne pense que c'est la solution magique, mais pourquoi ne pas essayer ?
En fait c'est amusant, on parle de liberté, de pouvoir changer le code pour adapter à ses besoins et tout mais il y a un conservatisme énorme sur ce genre de sujets. Si des développeurs veulent faire un Linux atomique pour les avantages qu'ils peuvent procurer, pourquoi on devrait les en empêcher ou critiquer la démarche ? D'autant qu'il y a de bons arguments pour un tel modèle (mais aussi de vrais arguments contre, évidemment).
Qu'ils essayent, qu'ils expérimentent et on verra si la sauce prend ou pas.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par rewind (Mastodon) . Évalué à 3 (+2/-2).
Pour qui ? Dire que les stores sont des bonnes choses (surtout étant donné ceux que je cite)… J'aurais jamais cru lire ça sur linuxfr.
La sécurité, bien souvent, c'est pas un problème technique mais un problème humain. Prétendre résoudre un problème humain avec une solution technique, c'est ne pas avoir compris le problème. Parce qu'il ne faut pas faire comme s'il n'existait pas déjà tout un tas de garde-fou avec Linux. Déjà le système de droits qui limite quand même bien ce qu'on peut faire, et ensuite des solutions type AppArmor, qui viennent se greffer encore par dessus. Sauf que toutes ces solutions, y compris celles proposées dans ce journal se heurtent à l'humain qui, quand une application va lui demander des droits pour pouvoir fonctionner, va sans doute appuyer sur oui sans bien comprendre les implications. Aucune solution technique ne peut résoudre ce problème. Pas plus les anciennes que les nouvelles.
En fait, je ne vois pas bien les avantages de ce système. Il n'apporte pas grand chose de plus par rapport à l'existant. Et en revanche, je vois bien les inconvénients, dont certains me paraissent assez contradictoires avec les buts premiers des logiciels libres en général.
Comme si c'était une nouveauté… On peut déjà le faire aujourd'hui ça. Ça donne vraiment l'impression qu'on réinvente la roue carrée.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Renault (site web personnel) . Évalué à 9 (+6/-0).
Car tu mélanges tout. Le problème n'est pas l'existence des stores, c'est la possibilité d'avoir des alternatives.
C'est très bien qu'un OS ait un store, c'est gênant si tu n'as pas le droit d'installer quelque chose d'en dehors d'un store unique.
Sinon le fait qu'une distro ait des dépôts devrait te faire bondir car c'est finalement la même chose.
Avec Flatpak et l'OS atomique tu peux installer des logiciels de différentes sources, Flatpak supporte des dépôts, tu peux créer le tien si tu veux par exemple. Donc je ne vois pas le problème.
C'est un problème humain et technique. La technique reste important dans ce contexte et tu ne peux l'enlever.
Sinon j'imagine que tu es superutilisateur en permanence, que tu envoies tes mots de passe en clair partout où tu te connectes, etc. ?
Et oui il y a des conceptions logicielles plus sécurisées que d'autres, parfois au détriment d'autre chose, c'est une affaire de compromis évidemment.
Ce n'est pas la solution miracle, mais ça évite des problèmes tout de même. Et ceux qui ont conscience de ces enjeux c'est un complément appréciable. Je suis bien content que par défaut une application ne puisse pas à priori prendre une photo de la webcam ou des captures d'écran sans que je n'y autorise par exemple dans mon dos. Cela nécessite une architecture particulière pour que cela soit possible.
De toute façon la sécurité n'est pas le seul enjeu ici, c'est un élément parmi d'autres.
Pourtant, dans les commentaires on a plusieurs fois expliqué ces avantages, que cela ne t'intéresse pas ou te paraissent secondaire c'est ton droit, cela ne veut pas dire que ton point de vue est universel.
Ce genre de propos n'a vraiment aucun sens.
Un logiciel libre ne signifie pas que par défaut le logiciel doit laisser l'utilisateur faire n'importe quoi n'importe comment. C'est juste que si l'utilisateur n'est pas content, il peut modifier (lui même ou via un tiers) le code pour s'adapter à son besoin. Les considérations de configuration et de souplesse à l'usage n'a rien à voir avec le caractère libre ou pas du logiciel. Tu peux avoir du libre très peu flexible et du proprio qui l'est énormément. Ce n'est pas l'enjeu ici.
D'ailleurs, tu le dis toi même, Linux fournit déjà beaucoup de restrictions pour des raisons de sécurité. Linux n'est donc pas libre ? On devrait bypasser la MMU pour être libre de notre machine car jardiner en mémoire c'est une liberté fondamentale ? Pourquoi le système tel qu'il est aujourd'hui malgré ses restrictions c'est "logiciel libre compatible" mais les mêmes logiciels organisés un peu autrement ne le seraient pas ? Tu définis comment la limite de l'acceptable ?
Ici tout le système est libre, tout autant qu'une distro classique en fait, donc ça n'a rien de contradictoire. On peut même ajouter que pour de nombreux utilisateurs, être capables d'installer un logiciel facilement sans dépendre de sa distro c'est une liberté plus importante que d'avoir par exemple un système de fichiers du système en lecture / écriture en permanence.
C'est peut être plus intéressant aussi d'avoir la possibilité de dire à l'application de chat de sa boîte de ne pouvoir accéder qu'à certains dossiers liés au travail plutôt qu'à tout le répertoire utilisateur.
Ah bon, tu fais ça comment qui fonctionne sur toutes les distros ? Et qui fourni un bac à sable avec la possibilité de restreindre les permissions au cas par cas selon les besoins et envies ?
Oui c'est faisable, mais en terme d'expérience utilisateur c'est vraiment compliqué à mettre en place proprement et encore plus de le faire de manière générique.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Vrai utilisateur libre ne monte pas de périphériques en lecture seule ?
Seul root est un utilisateur libre ?
Ou alors l'utilisateur et les logiciels ce n'est pas la même chose et le fait que l'utilisateur puisse dire non à ce que tente de faire un logiciel lui donne plus de droit.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Okki (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Les avantages que j'y vois :
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
Ça tu peux l'enlever de la liste, ça n'est pas spécifique aux Flatpak. C'est une généralité sous *nix.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Okki (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Bien avant que GNOME ne se mette à faire les mises à jour lors du redémarrage ou de l'extinction de la machine, j'avais déjà eu à plusieurs reprises des problèmes avec les mises à jour de Firefox faites pendant qu'il tournait et sans le relancer.
Les mises à jour en elles-mêmes se déroulaient sans problème, mais ensuite, dans le navigateur, on constatait tout un tas de petits problèmes (pages mal rendues, problèmes de menus…) tant qu'il n'était pas relancé.
Donc, plutôt que de dire aux gens qu'il faut bien penser à relancer tel ou tel service et les applications qui auraient été mises à jour, je préfère de loin la situation actuelle qui fait les mises à jour système au redémarrage ou à l'extinction. Et pour les Flatpak, il n'y a même plus besoin de s'en préoccuper. Tout se fait de façon transparente tout en étant super fiable et robuste.
Le Fedora Magazine avait sorti un article sur le sujet, il y a quelques années : Restarting and Offline Updates.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
D'après mon expérience de tous les jours, c'est effectivement un problème de Firefox, et de lui seul. C'est dans doute lié à un fonctionnement particulier de ce navigateur puisqu'il utilise plusieurs processus qui semblent interagir assez fortement entre eux.
Par opposition à des logiciels qui n'utilisent qu'un seul processus, ou plusieurs mais avec des interactions entre eux limitées et surtout, cadrées, par exemple le serveur de courrier Postfix.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Jérôme FIX (site web personnel) . Évalué à 4 (+3/-0).
Cela fait longtemps que Firefox continue à fonctionner dans les onglets précédemment ouvert, mais demande un redémarrage dès que l'on ouvre un nouvel onglet lorsqu'on vient de changer sa version.
Je ne dis pas qu'il n'y a pas de potentiel soucis sur l'ouvert, mais en règle général cela prend 5 secondes à relancer suite à une mise à jour. De plus il conserve les onglets précédemment ouvert.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par rewind (Mastodon) . Évalué à 5 (+3/-1).
Si l'application n'est pas populaire, c'est par définition que personne ne l'utilise. Si elle est populaire, alors elle sera dans les distributions.
Il est bien connu que les développeurs sont les meilleurs empaqueteurs (non).
Toutes les distributions (même Debian) ont des moyens de distribuer des versions récentes des logiciels les plus utilisés ou ceux qui nécessitent d'être à jour.
Ça, c'est la promesse. Java aussi disait «write once, run anywhere».
C'est déjà le cas.
C'est déjà le cas (ou alors il faut changer de distribution).
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Tit . Évalué à 0 (+1/-3).
Ah bon ? on ne doit pas avoir la même définition de populaire, mais prenons la tienne :
j'en déduis que si une personne utilise une application alors celle-ci devient populaire et donc elle sera dans les distibution… c'est magique ;)
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 10 avril 2025 à 17:04.
Java propose le modèle parfait : la jvm assure la portabilité, le runtime a les API les plus stables du monde, le sandboxing est faisable via des policies…
Mais la majorité OS (libres ou privateurs) n'ont pas voulu l'intégrer correctement à leurs bureaux (côté serveur c'est un succès).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Okki (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Le fait qu'une application ne soit pas populaire ne signifie pas qu'elle n'intéressera personne. Mais moins il y a d'utilisateurs, moins il y aura de chance de trouver dans le lot des bénévoles pour s'occuper des packages Debian, Fedora, Arch, Slackware et autres distributions mère. En jetant un rapide coup d'oeil sur Flathub, on trouve des applications d'entraînement à la dactylographie (Keypunch, 28 374 installations), pour apprendre l'assembleur 6502 (Learn 6502 Assembly, 593 installations), mesurer des objets à l'écran (Longueur, 2260 installations), démosaïquer du porno japonais (Lada, 3924 installations), vérifier sa réception GPS (Satellite, 12 404 installations), obtenir la valeur d'une résistance par rapport à ses codes couleur (Color Code, 6088 installations)…
C'est clairement le genre d'applications de niche qui ne sont pas empaquetées par les distributions et qu'il fallait autrefois compiler soi-même à partir du code récupéré sur GitHub. Je suis bien content que ce soit désormais facilement installable par tout un chacun, avec le suivi des mises à jour qui va bien.
Sur Flathub, les manifestes de construction sont publics. S'il y a le moindre souci, la communauté peut faire des rapports de bugs ou soumettre des correctifs.
Hormis quelques rares logiciels (comme les navigateurs), en dehors des distributions en développement continu comme Arch, chez les autres ça attendra toujours la version suivante de leur distribution. Tandis qu'avec Flatpak, c'est bien l'ensemble de la logithèque utilisateur qui est mise à jour.
D'ailleurs, je ne l'ai pas soulevé dans les avantages, mais toutes les distributions n'ont clairement pas les ressources humaines de Debian. Budgie, Linux Mint ou elementary OS, pour ne citer qu'elles, sont bien contentes de bénéficier de toute la logithèque de Flathub.
J'ai 72 applications en Flatpak et n'ai encore jamais rencontré le moindre problème. Donc en ce qui me concerne, ça vaut ce que ça vaut, mais la promesse est pour le moment bien tenue.
Utilisateur satisfait de GNOME et de tout son écosystème d'applications Adwaita, la seule application Qt que j'utilise, c'est qBittorrent. Ça a peut être changé depuis (je trouverai tout de même ça étonnant), mais autrefois, avec le paquet Fedora RPM, ça utilisait le sélecteur de fichiers de KDE. C'est depuis que j'utilise tout en Flatpak qu'il utilise désormais celui de GNOME.
Par contre, j'ai récemment lu que la dernière version de GTK utiliserait le portail pour le sélecteur de fichiers, que les applications soient sandboxées ou non. C'est peut-être déjà le cas chez KDE / Qt ? (sans oublier tous les autres toolkits…)
Je trouve d'ailleurs que le principe des portails, créés initialement pour les applications sandboxées, devrait grandement aider le développement d'applications, et que ces dernières soient bien mieux intégrées à chaque environnement de bureau.
Parce qu'autrefois, il y avait bien les spécifications Freedesktop, mais les différents environnements de bureau et les développeurs d'application n'étaient pas obligés de les suivre et d'implémenter rapidement les dernières versions. Désormais, avec Flatpak, qui doit fonctionner de la même manière chez tout le monde, j'ai l'impression qu'il y a bien plus d'obligation à tout bien respecter et que tout soit bien carré 🤔
Ça n'a jamais été le cas. Quand je parlais du cache, je ne parlais pas des paquets en cache. Avec apt remove --purge ça va te nettoyer ce qu'il connaissait au moment de l'installation. Si l'application créée ou télécharge tout plein de fichiers après coup, ça ne va rien te nettoyer.
Ça fait de nombreuses années que je n'ai plus utilisé Debian en tant que poste de travail et ça a peut être changé depuis, mais dans mes souvenirs, ça se contentait de dire que le répertoire en question n'était pas vide et n'avait donc pas pu être supprimé. À l'utilisateur de faire lui-même la suppression manuellement. Ce que ne feront jamais la majorité des utilisateurs, qui se retrouvent donc avec un système de plus en plus pourri au fil du temps.
Avec Flatpak au moins, tout est carré. Un dossier pour l'application elle-même, un autre pour tout ce qui touche aux paramètres, cache et compagnie. Lors de la désinstallation, ça te laisse le choix de garder ou non les paramètres et données ou de tout supprimer définitivement.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Bon sang mais c'est ça dont l'OS souverain de l'Europe a besoin. Pourquoi Lennart Poettering n'a pas commencé par là ??
Plus sérieusement : je suis bien d'accord avec toi. Comme je l'ai évoqué dans un autre commentaire, je suis passé par Arch Linux à une époque où j'en avais marre d'attendre la saint-glin-glin pour avoir ce que je voulais dans les dépôts d'Ubuntu (ou les PPA, qui se rappelle des PPA ?), et il fallait quand même que j'aille régulièrement taper dans l'AUR, ce que je ne qualifierais pas de Michu-compatible ;suffit de voir sur Reddit ce qui arrive aux jeunes chevaux qui ne font pas la différence entre pacman et l'AUR et bousillent leur Manjaro. Ayant vécu tout cela, je peux dire que oui, à mes yeux Flatpak représente le meilleur des deux mondes. Et le concept d'un Linux taillé sur mesure autour de cette approche pour viser le grand public m'intéresse tant et si bien que j'ai fini par écrire cette dépêche pour le faire connaître à plus de monde.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+1/-1).
Les portails c'est le plus intéressants dans cet écosystème : je pense qu'on pourrait pousser le concept plus loin en l'utilisant à la place des bibliothèques dynamiques. On aurait ainsi un vrai OS avec une architecture orienté service.
Attention le premier qui dit "microservice" est un consultant d'ESN avec un micro pénis).
En parlant de ca, l'appli de demosaification de porno japonais devrait un service et pas une appli.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par lym . Évalué à 3 (+3/-1).
Et on sait comment cela a (mal) tourné: Chaque applicatif Java traînant avec lui sa JVM et dépendances dans la version testée! Avec le début de la décroissance (certes lente, vu la masse de l'existant) de ce langage à la clef.
Bref, le syndrome windows avec les compilations statiques ou les DLL quasi-doublons venant avec quasiment tout ce qu'on ajoute et s'installe certes d'un clic, en pire…
Franchement, je n'ai pas hâte de voir cela sous Linux car cela ruine toute l'efficience matérielle de gestion de la mémoire virtuelle d'une part et que l'alibi de la gestion fine des droits ne fait à mon sens que souligner le cadre pour lequel les diverses formes de conteneur, s'ajoutant ici aux doublonnages crades de non gestion intelligente des dépendances, ont été crées: Permettre de tester des applicatifs qui ne soient pas de confiance… ou de se faire un environnement d’exécution sur mesure de vieux trucs encore nécessaires à son usage/production mais devenus impossibles à recompiler/faire évoluer, par exemple car on en a perdu les sources créés avant que les systèmes de gestion de conf n'existent!
Puis comme dit par ailleurs, à la base, on peut aussi minimiser les dépendances un peu hétéroclites en les intégrant de manière statique… voir en codant la fonctionnalité soit-même plutôt que de gauler un truc plus ou moins bien fait/stable ajouté en mode quick&dirty pour ensuite le payer en maintenance sur la durée tout en emmerdant l'utilisateur final.
Niveau MAJ, je suis sous Debian depuis ~13 ans après quelques années sous Ubuntu (la LTS 10.04 fut ma dernière, après cette distro se voulant "résoudre le bug Microsoft" a de mon point de vue trop fait de gras, délires de bureau, pour finir par remplacer un "bug" par un autre), jamais eu aucun problème: Zéro, nada, néant. Autant sur des machines perso/famille (8 ou 10 références utilisées sur cette durée) qu'au boulot sur des machines lab auto administrées/hors IT.
Si j'ai eu des merdes, c'est surtout sur qq RH du boulot installées par d'autres "parce que c'est plus pro" et qui, avec des dépots vides comparés à Debian, obligent à bidouiller avec des dépôts tiers/Fedora pour tout ce qui ne se build pas facilement soit-même (option à privilégier pour tout hors-dépots sur ce système, mais pas toujours possible/aisé): Mauvaise distro, changer distro…
En réalité, tout ceci me semble venir du web qui a un développement qu'on pourrait simplement qualifier ainsi: TTM-Driven… Et on s'en fout de la durée à maintenir, on refera tout dans 2 ou 3 ans avec le nouveau framework à la mode.
Sauf que dans le cas qui nous intéresse, la durée on ne s'en fout pas!
L'autre sujet, plus personnel, c'est le bureau choisi: Gnome dans sa version canonique je n'ai jamais accroché. Si j'y suis revenu après quelques années d'errance au passage à Gnome 3 c'est car Cinnamon offre une expérience desktop classique et pas une sorte d'hybride mobile (et avant cela, les tentatives depuis avortées d'Ubuntu sur ce modèle m'avaient rebutées aussi).
A ce sujet on remarquera qu'Apple, qui ne s'est jamais trop planté sur l'ergonomie, n'a jamais tenté ce type de mauvaise fusion de ses interfaces mobiles et desktop! Probable qu'ils aient étudié cela, ayant bouleversé l'expérience mobile et collé une pomme sur la tête de la concurrence endormie sous l'arbre, sans y trouver de pertinence…
D'où cette interrogation pour moi: Vouloir rendre Linux plus accessible… avec ce choix de DE, quelle cohérence?
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Andréas Livet . Évalué à 3 (+2/-0).
Je réagis peut-être un peu tard, mais pour moi, tous les avantages que tu cites se trouvent dans des approches comme Nix ou Guix.
Je ne vois donc pas pourquoi on a inventé Flatpak ou snap, à part peut-être pour le sandboxing et la gestion fine des droits et en encore on peut faire ça aussi sous Nix (avec moins de finesse si j'ai bien compris).
Donc pourquoi ne pas s'être basé sur un système qui me paraît mieux pensé ?
C'est une vraie question, j'ai vraiment du mal à comprendre la motivation derrière ces approches.
En plus, on gagne quelque chose d'important avec Nix et autre : la possibilité de partager des libs entre applications. Et c'est pour moi un gain important en sécurité.
Car, aujourd'hui, si j'ai bien compris, si y a un prob dans la libC d'un de tes flatpaks, t'es obligé de mettre à jour ton appli, alors qu'avec Nix, si l'appli pointait vers une version non spécifique de la libC, alors si la libC se met à jour, ton appli aussi, pas besoin de faire intervenir le développeur de l'appli. On a le meilleur des deux mondes comme ça :).
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Tu peux avec Nix demander des permissions à la volée ? Genre une notification pour dire "tu peux prendre le flux vidéo de la webcam maintenant" ? Je ne le crois pas.
J'adore aussi le à part peut être comme si c'était un détail en fait. Flatpak est un tout, ce n'est pas juste un format de paquet universel. Je pense que c'est vraiment problématique de ne considérer que cet aspect, on passe à côté d'une bonne partie du concept.
Mieux pensé mieux pensé, avec ses limites aussi.
Avec Flatpak aussi. Tu utilises GNOME ? Une bonne part des bibliothèques de base des applications GNOME utiliseront les mêmes versions grâce au concept de runtime. Ton application a juste besoin de dire le runtime auquel il dépend et si plusieurs applications utilisent le même (et c'est souvent bien partagé) tu as peu de redondance pour ces bibliothèques essentielles. Donc la mise à jour reste simple et efficiente tout en gardant une bonne compatibilité.
Il faut mettre à jour le runtime en général, plus rarement l'application.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Andréas Livet . Évalué à 1 (+0/-0).
Non à ma connaissance ce n'est pas possible, mais tu peux créer des sandbox, c'est vrai que c'est moins fin comme droits que Flatpak et si c'est l'intérêt de Flatpak alors je comprends la différence.
Mais donc flatpak est plus qu'un format de paquet en effet, c'est plutôt une autre manière de faire des logiciels, vu que ton logiciel doit prendre en compte le fait qu'une autorisation doit se faire pour pouvoir utiliser certaines fonctionnalités non ?
Ok c'est déjà mieux.
Bon par contre, y a quand même un autre souci avec Flatpak : si j'ai bien compris c'est fait pour tourner sur une session utilisateur "graphique", c'est pas bien fait pour des serveur headless non ?
En tout cas, si les droits fins sont le truc important en effet y a pas vraiment d'autres alternatives que Flatpak (snap est géré par Canonical et refuse les autre hub c'est ça ?).
Après, est-ce qu'il n'y avait pas moyen de mettre au point ce genre de "surcouche" sur les droit autrement ? J'imagine que c'est possible via des libs mais donc plus intrusif.
Merci pour les réponses et le débat en général, je comprends mieux les tenants et les aboutissants de tout ça.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Au passage, on a fait semblant de ne pas voir SELinux et AppArmor pour des droits fins…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par lym . Évalué à 2 (+2/-1).
Je ne voit pas comment assurer une cohérence qui peut fonctionner dans un système centralisé de dépôts, non sans déjà causer quelques maux de têtes aux mainteneurs, pourrait être ici viable en pratique… avec chaque développeur des applicatifs aux manettes.
La réalité, c'est que les utilisateurs d'Ubuntu a qui on a fait passer pas mal d'applicatif dans le pendant Snap ont bien vu les temps de chargement/démarrage exploser au changement, surtout s'il ne sont pas passé au SSD NVME voir racheté des barrettes de RAM (car la mémoire virtuelle mappait chaque dépendance partagée dans chaque process sur une seule physiquement présente).
Ici, on s’assoit juste sur toute la pertinence d'un modèle de distribution en sources ouvertes vs binaires fermés: Tout ce qui permets de rendre un Linux plus efficace qu'un Windows et avec quasiment zéro impact performance sur un upgrade à matériel constant.
# Petite precision sur bazzite os
Posté par ThomasJ . Évalué à 4 (+4/-0).
Pour info il en existe une version desktop. Vraiment très heureux, s’ameliore constamment, tout se met à jour en une ligne de commande appelable du menu,avec firmware paquet pip et conteneurs, tout configurer pour jouer rapidement. Oui c’est peut être michu oriented, mais c’est justement ce que je cherchais.
# Questions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 08 avril 2025 à 13:48.
Quelques questions sur cette idée de système atomique et d'applications en bac à sable.
Comment est définie la frontière entre système et logiciels ordinaires ?
Le noyau, l'init et probablement la libc sont certainement considérés comme faisant partie du système, mais qu'en est-il des autres logiciels ? Par exemple :
Comment s'intègrent des logiciels « un peu spéciaux » ?
Je pense par exemple à des logiciels serveurs, des outils en ligne de commande et des outils d'administration, tels que GParted, Parted, RSync, Samba, Postfix, Apache httpd, lshw, btrfs-progs, LVM, cryptsetup, v4l2loopback…
Ça s'intègre bien en Flatpak ou équivalent, ce genre de truc ? Et installé ainsi, c'est aussi utilisable ?
[^] # Re: Questions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Dans les logiciels un peu spéciaux, je peux aussi ajouter quelques autres exemples intéressants, pour questionner les limites du modèle : JACK, bridge-utils ou encore les pilotes graphiques propriétaires Nvidia.
[^] # Re: Questions
Posté par saltimbanque (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 08 avril 2025 à 22:34.
je laisserai un connaisseur répondre, mais on peut trouver sur https://flathub.org/ deux trois choses. Oui il y a bien des navigateurs et oui ça a demandé du boulot au début pour avoir un firefox sous flatpak.
Sur des applis "limites", on peut trouver quelque chose comme DejaDup, un env de développement Builder, Emacs, FileZilla, "Logs" pour explorer journalctl, un
dugraphique, de quoi faire tourner des machines virtuelles ou écrire un .iso sur une clé usb. Cela donne déjà une idée et je pense que la limite a pu évoluer par le passé pour élargir un peu, je ne sais pas si cela continue d'évoluer.Pilote graphique ou Samba là je pense qu'on est clairement dans la catégorie "jamais jamais"
edit - et oui bien sûr on trouve mail, lecteur vidéo
https://flathub.org/apps/org.gnome.DejaDup
https://flathub.org/apps/org.gnome.Builder
https://flathub.org/apps/org.filezillaproject.Filezilla
https://flathub.org/apps/org.gnome.Logs
https://flathub.org/apps/org.gnome.baobab
[^] # Re: Questions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
Je questionne, parce que mine de rien, s'il y a des catégories de logiciels qui ne passeraient pas avec un tel format de distribution et d'utilisation, c'est bloquant en fait.
Je peux bien avoir un système de base atomique et plein de logiciels ordinaires sous forme de Flatpak, s'il n'y a pas moyen d'utiliser ainsi un truc comme Samba, ça implique qu'on peut se diriger, au mieux, vers un système triple : système de base atomique, paquets ordinaires et Flatpak. Mais en aucun cas système atomique et Flatpak seuls du coup.
[^] # Re: Questions
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Pour ce qui est des distros "atomiques" comme Fedora silverblue/universalblue, tu peux toujours installer des paquets à l'ancienne. Les rpms sont ajoutés par dessus l'image sous forme de couches.
[^] # Re: Questions
Posté par Okki (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
X.Org / Wayland feront parti du système, de même que l'environnement de bureau de base (GNOME Shell, KDE Plasma) et certaines applications cruciales, qui peuvent varier d'un bureau à l'autre. Par exemple, GNOME ne propose pas de Flatpak de Nautilus, tandis que Dolphin semble y avoir droit chez KDE.
Pour les applications bas niveau que t'as cité, le Freedesktop SDK en fourni un certain nombre (btrfs-progs, cryptsetup, cups, rsync, libmicrohttpd, lvm2, v4l-utils…) (voir la liste complète).
Si ça ne fait parti d'aucun runtime (GNOME, KDE et elementary ont également les leurs), une application peut inclure les dépendances dont elle a besoin dans son propre Flatpak. Par exemple, l'outil de sauvegarde Déja Dup va inclure duplicity, fasteners, rclone et restic.
Mais dans l'ensemble, Flatpak est très orienté applications graphiques. Ceux qui adorent tout faire en ligne de commande resteront sans doute sur des distributions traditionnelles.
[^] # Re: Questions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
Ça confirme une impression personnelle, et donc un corollaire : le tout atomique + Flatpak ou équivalent n'a aucune chance de remplacer complètement nos distributions.
[^] # Re: Questions
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
C'est oublier qu'il n'y a pas que Flatpak "ou équivalent" : tu peux aussi installer des applis en ligne de commande sur des systèmes atomiques, via Homebrew ou Toolbx ou Distrobox. Je ne sais pas si le modèle strictement immuable n'a "aucune chance" de remplacer complètement les distributions, mais il m'apparaît clair que c'est précisément ce que ses promoteurs cherchent à démontrer.
[^] # Re: Questions
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 10 avril 2025 à 13:15.
Soit dit en passant j'ai les deux à la maison et quand je veux utiliser la ligne de commande sur mes distros "atomique", je les utilise dans une toolbox/distrobox.
Donc tu ne perds pas vraiment les paquets traditionnels quand tu utilises une distro atomique, ils sont juste installés dans un (ou plusieurs) container et ceux-ci ont l'avantage d'être supprimable si tu te rends compte que tu n'as plus besoin d'un environnement spécifique. Et ça n'a rien à voir à utiliser docker, c'est assez convivial et transparent puisque tu as accès à ton home par défaut, tes périphériques amovibles, le réseau, ton compositeur/serveur d'affichage et tu peux avoir accès à ton gpu sans avoir à connaître mille options.
https://containertoolbx.org/
https://distrobox.it/
EDIT: Laurent m'a battu au sprint.
[^] # Re: Questions
Posté par saltimbanque (site web personnel) . Évalué à 2 (+0/-0).
Est-ce que c'est adapté par ex. pour tourner nginx?
[^] # Re: Questions
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 13 avril 2025 à 19:44.
Dans ce genre de distro tu privilegiera plutôt de le faire tourner dans un conteneur mais ça reste possible en utilisant le paquet rpm.
# je suis perdu
Posté par mahikeulbody . Évalué à 5 (+3/-0).
J'avoue être un peu perdu : quels sont les rapports entre immuable, atomique et flatpak ?
Ça me semble des trucs techniquement indépendants qu'on combine avec pour objectif une distribution plus robuste et simple à utiliser.
Par exemple, si je prends une distribution avec des snapshots btrfs et des flatpaks, qu'est-ce qu'il lui manque pour prétendre la même chose ? (c'est une vraie question)
[^] # Re: je suis perdu
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Pour rajouter un terme en plus dans la soupe : image-based.
C'est la même « image » système chez tout le monde, peu importe le matériel. Cette image a (normalement) été bien testée. Lors d'une mise à jour majeure, c'est comme si on avait fait une installation fraîche.
Avec une distrib classique à base de paquets qu'on installe (avec snapshots btrfs c'est mieux comme ça y a le roll-back), chaque système diverge de plus en plus. Lors de mises à jour majeures, c'est parfois plus délicat et l'aide d'un sysadmin est nécessaire.
[^] # Re: je suis perdu
Posté par mahikeulbody . Évalué à 4 (+2/-0). Dernière modification le 11 avril 2025 à 22:34.
Ok, du coup image-based implique forcément flatpak (ou équivalent). Mais alors comment ça se passe quand on a installé des choses hors flatpak (il y des commentaires ici qui disent que ça reste possible) ? Il faut les réinstaller après une mise à jour du système ?
[^] # Re: je suis perdu
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Tu as plusieurs manières d'installer une application hors Flatpak dans Silverblue :
La dernière méthode est parfois nécessaire dans certains cas, et est globalement à limiter au maximum car cela réduit les avantages du système atomique en tant que tel.
[^] # Re: je suis perdu
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 11 avril 2025 à 23:36.
D'ailleurs, sais-tu où s'insère Homebrew (qui est inclus par défaut dans les images Universal Blue et dont l'usage est recommandé par le projet) dans ce schéma ?
[^] # Re: je suis perdu
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
J'ai l'impression que c'est une alternative à Flatpak qui utilise les répertoire utilisateurs pour installer les binaires qu'il gère.
Homebrew semble plus générique dans le sens adapté pour les outils CLI et compatible macOS au passage, mais manquant l'aspect bac à sable de Flatpak et la possibilité de partager des bibliothèques communes via des runtimes.
Mais du coup cela permet d'éviter d'installer ces outils au niveau du système atomique.
# Ardour ?
Posté par mahikeulbody . Évalué à 2 (+0/-0).
Je me souviens que quand j'ai installé Ardour pour ma fille, j'avais lu que flatpak n'était pas recommendé car cela bloquait (rendait difficile ?) l'ajout de plugins externes.
Ce genre de problème est toujours vrai ?
[^] # Re: Ardour ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Bonne question. La page Flathub d'Ardour a un onglet "Modules d'extension", dans lequel sont listés les plugins compatibles ; j'imagine que ceux-ci peuvent être installés quand tu affiches l'appli dans Discover ou Logiciels. Ceci dit, il s'agit d'un Flatpak non-officiel, maintenu par Hubert Figuière, qui explique dans le forum officiel d'Ardour qu'il ne supporte pas 100% des plugins existants, et qu'il vaut mieux utiliser la version officielle pour cela.
Maintenant, est-ce que c'est quelque chose qui concerne toutes les applis Flatpak utilisant des plugins, ou seulement Ardour qui ne semble pas optimisé pour ça ? Je l'ignore. Dans le doute, commence par vérifier si une appli a son badge "vérifié" sur Flathub, et à défaut, regarde ce que recommande le dev upstream. C'était ce que je faisais à l'époque où j'utilisais l'AUR, parce qu'on avait souvent de mauvaises surprises (et d'ailleurs, on peut même avoir ce genre de problèmes avec les paquets de distro : cf. le cas d'OBS évoqué dans la dépêche, ou ceux de Bottles et xscreensaver que j'avais déjà relayé ici).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.