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é à 8 (+5/-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 totof2000 . Évalué à 1 (+0/-1).
La dessus je pense que des distributions telles que Ubuntu ou debian, se vautrent lamentab lement sur la lotion de "minimum pour démarrer le système et qu'il soit fonctionnel pour l'utilisateur". Je n'ai jamais compris pourquoi des outils tels que netstat, traceroute, ou ce genre d'outils de diagnostic réseau (présents de base sur les Unix originels) ne fait pas partie des paquets de base …
Combien de fois j'ai pesté contre le c** qui a décidé ce genre de choses lorsque je me suis retrouvé avec un système qui démarre, mais qui a un problème de réseau que je ne peux pas débugger via traceroute ( installation qui nécessite le proxy - que justement je n'arrive pas à atteindre, d'ou le besoin de traceroute).
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 5 (+3/-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 zephyr32 . Évalué à 1 (+0/-0).
BSD BSD, sur freeBSD ça fait des jours/semaines qu'un "pkg update" fait sauter tout l'environnement de bureau. Ça revient à la normale mais certains environnement ont encore ce problème.
Ici, la compilation de tout Gnome saute parce que dépend de…gnome-chess. Et le paquet gnome-chess ne compile pas :
https://pkg-status.freebsd.org/beefy20/build.html?mastername=142amd64-quarterly&build=52d4684f6c02
Du coup c'est pas si homogène que ça 😂 Après, évidement il faut lire les résultat de la commande pour voir que tu vas perdre tout ton DE.
[^] # Re: Atomique ?
Posté par totof2000 . Évalué à 1 (+0/-1).
En même temps … c'est Gnome. Qui peut être assez fou pour utiliser Gnome sur un système BSD ?
[^] # Re: Atomique ?
Posté par zephyr32 . Évalué à 2 (+1/-0).
Bah c'est un paquet comme un autre. S'il est présent c'est qu'il est fonctionnel :)
Non sérieusement, c'était tous les DE. Même xfce avait sauté.
Sur le forum, d'après les Monsieur "ca fait 20 quand que j'utilise freeBSD" c'est jamais arrivé.
En tout cas j'avais sous-estimé le temps de bidouille nécessaire sous freeBSD du coup je suis revenu sur ma bonne vieille Debian.
[^] # 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 Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Ça marche toujours snap ?
J ai eu une blague avec docker sur ubuntu : impossible de faire docker kill avec snap.
"La première sécurité est la liberté"
[^] # 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é à 9 (+8/-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 pasBill pasGates . Évalué à 2 (+2/-1).
C'est d'une naiveté…
Il y a plein de systèmes client-serveur dans un OS (ex: un service en background dans son compte à lui et un client tournant en compte utilisateur qui fait office d'interface)
Il est fréquent que les 2 partagent les mêmes librairies. Un client, cela s'arrète et redémarre bien plus souvent qu'un serveur par contre d'habitude.
Tu installes ton update, en remplaceant un fichier que les 2 utilisent. Le service utilise la v1, si le client se relance entre les 2, le client utilisera la v2, ce qui pose potentiellement des problèmes selon les usages, ou alors il faut assurer une compatibilité de protocole, etc… ce qui est lourd à gérer et chiant.
Sans parler du fait que si tu installes ton fichier sans rien relancer, il n'est pas chargé en mémoire, l'ancien est toujours utilisé. T'as installé 3 mois d'updates sur ton serveur sans rien redémarrer c'est cool, en mémoire tu auras toujours le code vulnérable d'il y a 3 mois.
Bref, ton idée que l'approche Linux est clairement meilleure est naive, en pratique la différence est très faible car dans les 2 cas il faut stopper et redémarrer le code qui utilise les fichiers modifiés pour que l'update soit effective. Vu qu'il n'y a pas de moyen sur et simple pour automatiquement redémarrer tous les softs affectés, la pratique est de redémarrer les systèmes. Et c'est encore plus vrai vu la fréquence des updates de sécurité du noyau.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2 (+1/-2).
Bon alors pour info, une mise à jour de sécurité sur une bibliothèque partagée, c'est fait pour ne casser ni l'API, ni l'ABI. Donc pas de problème pour avoir un client et un serveur qui tournent avec deux versions différentes.
Ensuite, s'il y a du client-serveur là-dedans, l'interface entre les deux, c'est un protocole qui devrait être clairement défini, et certainement pas « le truc implémenté par la bibliothèque partagée ». Si l'interface entre deux composants découplés était définie par la bibliothèque dans sa version du moment, je ne m'attendrais effectivement à de beaux bugs à l'occasion.
Mais bref, on parle de quoi comme service en fait ? CUPS ? Entre le serveur CUPS et les clients CUPS, c'est une API qui est en fait une extension d'IPP et qui est définie. Pas de problème de version de bibliothèque là-dedans, d'ailleurs les clients CUPS sont conçus pour être utilisables avec un serveur distant, c'est dire si c'est indépendant de la version de la bibliothèque utilisée.
X11 ? Ah non, là si tu relances le serveur, tu relances forcément le client.
NetworkManager ? Le lien entre le client et le serveur est, il me semble, une API DBUS documentée, qui ne changera certainement pas avec la mise à jour de sécurité d'une bibliothèque.
Sur mon système, je trouve encore bluetoothd, qui pourrait éventuellement poser problème, et encore, j'en doute.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2 (+1/-2).
Et accessoirement, au-delà de toute ma théorie, j'ai surtout une vingtaine d'années de pratique, à faire régulièrement des mises à jour et à redémarrer les services concernés sans le moindre problème.
Je ne dis pas que je n'ai jamais eu de problèmes en général, mais des problèmes liés à des mise à jour de sécurité de services sans redémarrer mon ordinateur, jamais.
Des problèmes lors d'une mise à jour pour changement de version du système d'exploitation, parfois. Et pour ce genre de mise à jour, je redémarre effectivement, ça me semble une évidence, d'autant que ça inclut toujours une mise à jour du noyau.
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 3 (+3/-1).
Mais bien sur que si tu es un nerd et que tu fais cela depuis 20 ans, tu comprends tous ces détails, tu fais bien attention, au final tu peux, mais quand tu es Windows et tu as 1 milliard d'utilisateurs dont la plupart n'ont pas les connaissances, c'est un modèle ridicule qui ne sert à rien.
Idem en entreprise, quand tu as 1000 machines voire bien plus à gèrer, oû les machines ont des OS de versions diffèrentes, font tourner des softs diffèrents, ce modèle ne sert strictement à rien, c'est impossible à gèrer.
Bref, c'est un gimmick, en pratique pour un OS grand public c'est effectivement inutile.
[^] # Re: Atomique ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Pas besoin d’être nerd, en tout cas avec les versions actuelles des distributions GNU/Linux : avec l’interface graphique tu vois clairement que c’est tel programme que tu es en train d’utiliser qui va être mis à jour et dans tous les cas tu as un message invitant à redémarrer (l’appli hein).
Les usagers de Windows connaissent cette expérience aussi quand l’application leur offre la possibilité de se mettre à jour depuis le menu ou un bouton : on est invité à relancer l’appli pour finaliser ou alors c’est fait automatiquement quand on valide la mise à jour. Pas besoin de relancer tout le système …sauf avec les applis genre ms office…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 4 (+3/-0).
Non.
Cela te montre quel soft doit redémarrer pour recharger une librairie parce qu'il regarde quel processus à chargé quelle librairie. Il ne va pas te montrer quel soft relancer pour qu'il recharge des changements de configuration par exemple, qui pourraient faire partie du patch de sécurité. Il ne te dit pas quels softs doivent aussi redémarrer parce qu'ils ont une dépendance non-manifeste à un soft que tu dois redémarrer à cause du patch.
C'est pas pour rien que je dis que ces trucs sont des gimmicks. J'ai quand même passé 13 ans dans le groupe qui faisait toutes les updates de Windows, c'est une problématique très compliquée, avec plein de cas à gérer.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+1/-1).
Que les mises à jour de Windows soient quelque chose de très compliqué, je n'en doute pas en effet. Je soupçonne que la gestion des mises à jour de Debian, Ubuntu, Fedora ou tout ce que vous voulez soit légèrement plus simple.
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
C'est un soupçon, pas forçément basé sur grand chose je te dirais.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
Ça ne sert certainement pas à rien, et le fait d'imposer un redémarrage pour toute mise à jour du système est connu comme étant une vraie plaie. Ça a même inspiré des points de scénarios de films je crois.
Il faut dire que c'est aggravé par le fait que le système de mise à jour de Windows est particulièrement mal fichu, vu de l'extérieur. Un ordinateur resté à l'arrêt pendant six mois peut facilement demander trois redémarrages et un temps d'application total de l'ordre de l'heure pour fournir enfin un système Windows à jour et utilisable. Alors forcément, le ressenti est mauvais.
(C'est une expérience personnelle, ayant rallumé un ordinateur pro sous Windows après plusieurs mois. Trois redémarrages et une heure et demie d'indisponibilité pour Windows. Quinze minutes de mises à jour sans aucune indisponibilité et un unique redémarrage pour Ubuntu. Ç'aurait été pareil pour Debian mais mon employeur me demande d'utiliser Ubuntu.)
[^] # Re: Atomique ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Vu récemment : Mac prend un peu plus de temps (une bonne demie heure) mais un seul redémarrage et tout est bon.
Expérience perso avec un Windows du boulot au retour de quelques semaines de vacances : pareil, plus d’une heure et trois redémarrages. Mais quand c’eut été fini, je vais vérifier s’il y a encore des mises à jour et c’était le cas : pourquoi n’avoir pas tout fait est un mystère pour moi et ce n’est pas la première fois (c’est parce que j’ai déjà eu le coup que j’ai pensé à aller vérifier.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 25 avril 2025 à 14:12.
Dans le même situation que moi, à savoir mettre à jour un Windows après quelques mois sans utilisation, j'ai un collègue qui, en suivant des instructions contradictoires fournies par l'outil de mise à jour, a carrément pété le système d'exploitation.
Concrètement, à un moment ça lui a indiqué quelque chose comme ça :
Et lui, en lisant surtout le titre et en voyant en bas un bouton redémarrer, eh bien il a cliqué dessus. Sauf qu'en fait il ne fallait pas, surtout pas, ça a tout pété. :-D
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 0 (+0/-1).
Je bosse depuis maintenant plus de 10 ans dans une boite qui est quasi exclusivement du Linux en tant que serveur, qui a sa propre distrib, des pontes de Linux employés içi, qui fait ses propres CPUs, etc… Bref, Linux, il n'y a pas grand monde sur cette planète qui le connait mieux qu'eux.
Tu crois qu'ils font quoi en ce qui concerne les updates ? Qu'ils s'amusent à aller regarder sur chaque machine quel processus arrèter et redémarrer et sont convaincu que cela marche sans problème ? On parle juste de quelque millions de systèmes hein, pas grand chose.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Si les conditions d'utilisation de ces ordinateurs permettent cette pratique, c'est le plus simple et le plus sûr, en effet.
Pour autant, le fait qu'un système d'exploitation :
n'est pas inutile. Si on ne veut pas se poser de questions, on peut juste redémarrer. Si on fait tourner un service qui supporte assez peu d'interruption, on peut se contenter de redémarrer juste ce qu'il faut, en sachant ce qu'on fait.
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Mais là on est loin de la critique de NixOS.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
Pour atteindre l'objectif que tu cites il y a plusieurs méthodes, par exemple le hotpatching, qui est la méthode choisie par MS : https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates
Avec cela, plutôt que redémarrer chaque mois, c'est 4 fois par an. Avec le hotpatching tu ne te casse pas la tète à devoir redémarrer un processus, à devoir gèrer les processus dépendent de ce processus que tu redémarres, etc…
Bref, de nouveau, la méthode que tu cites n'est pas essentielle, il y a d'autres approches qui ont aussi leurs avantages.
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
Tu assumes ici que l'interface entre le serveur et le client est publique, hors si ces 2 sont toujours sur la même machine et ont pour but simplement de permettre la communication avec le service central il n'y a aucune raison d'avoir une ABI-API documentée, publique, … Avoir cela implique tout un effort de compatibilité ascendantes, support de vieilles versions, etc… qui est douloureux.
Je ne sais pas pour ta machine, mais sur Windows il est extrêmement commun de trouver un service en arrière plan et un client dans chaque compte utilisateur qui communiquent avec le service par named pipe ou autre. Le service n'a pas de connection réseau hors de la machine, la seule connectivité est pour ces clients locaux et l'application est un tout.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+1/-1).
Oui eh bien si ces services utilisent une interface non documentée susceptible de casser à l'occasion de simples mises à jour de sécurité, forcément ça risque de poser des problèmes si on ne redémarre pas le client et le serveur en même temps.
Je comprends bien le problème, seulement c'est un problème spécifique à Windows ça. C'est sûr que quand on conçoit un système en partant du principe qu'il faut le redémarrer à chaque mise à jour, on se retrouve avec des problèmes spécifiques qui rendent cette pratique indispensable.
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 2 (+1/-0).
Mais tu rèves, cela n'a rien de spécifique à Windows. C'est une architecture standard pour des applications desktops qui ont un service en arrière plan. Le client est fait spécifiquement pour tourner avec ce service et rien d'autre, sur une machine et c'est tout. Plein d'éditeurs ne se cassent pas les couilles à maintenir une ABI pour ce qui est au final 2 composants liés de manière très proche et qui ne concerne que eux et aucun autre client.
Ton idée que ces 2 doivent pouvoir être modifiés séparement est un dogme, qui ne repose sur pas grand chose de concrèt, tu ne prends pas du tout en compte les coûts de faire cela en comparaison du bénéfice que tu as en retour.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7 (+4/-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é à 3 (+1/-0).
L'utilisation de Btrfs est justement la particularité des systèmes atomiques d'OpenSuse.
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 0 (+2/-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é à 7 (+4/-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é à 3 (+1/-1).
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 pasBill pasGates . Évalué à 2 (+3/-2).
Il y a plusieurs updates installées chaque mois, fréquemment une du noyau. Qui à part un nerd comme toi va aller regarder les détails de chaque update, aller voir et vérifier 3 fois quels sont les softs à arréter, relancer, etc… et le faire à la mano ?
Personne, c'est douloureux, manuel, avec risque de se brouter, juste pour éviter un redémarrage. Bref, c'est un gimmick.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+1/-1).
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2 (+0/-1).
Merci, ça fait toujours plaisir.
Je confirme, personne. Pas même moi.
Manuel en effet, avec tous les problèmes que ça implique. C'est typiquement le genre de truc à automatiser, et il se trouve que ça s'automatise très bien.
C'est assez futé comme approche en fait : Linux expose les fichiers mappés en mémoire par chaque processus dans
/proc/PID/mapset dans/proc/PID/map_files. Or l'exécutable lui-même, ainsi que les bibliothèques qu'il a chargé, est justement mappé en mémoire. Lorsque le fichier mappé en mémoire n'existe plus, ou plus précisément, n'existe plus sous le nom qu'il avait lors de son chargement, ça se voit dans cette liste.Or, avoir un fichier mappé en mémoire qui n'a plus son nom d'origine, et éventuellement qui n'a plus aucun nom, c'est typique d'une bibliothèque mise à jour.
Quoi qu'il en soit,
needrestartest un outil très utile, que je recommande vivement à tous les utilisateurs de Debian et dérivées.[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Arrête ton char c’est toi qui a commencé le thread avec condescendance et qui continue par exemple juste un peu plus haut à tenter de faire autorité, moi j’ai 20 ans d’XP, comme si ce n’était pas le cas de tes interlocuteurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 3 (+2/-0).
Mais du tout non, parce que needrestart ne fait pas la moitié du boulot. Par exemple il ne prend pas en compte les patchs de sécurité qui ne correspondent qu'à une update d'une valeur de configuration et oû il faut redémarrer le soft pour que ce soit pris en compte.
Faut trouver ensuite l'ordre dans lequel redémarrer les softs, quels softs peuvent être arrété et quand, etc…
Ton petit cas particulier fait à la mano est impossible à généraliser au niveau d'un OS grand public avec des softs venant de plein d'horizons diffèrents.
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
D'accord sur ce point, merci de m'en avoir fait prendre conscience. Needrestart ne suffit effectivement pas. Mais accessoirement, ça peut être pris en charge par le système de paquets. Après tout, si une mise à jour de
ntpdapporte une configuration corrigée, le paquet qu'on vient de mettre à jour sait parfaitement quel est le service à redémarrer pour appliquer ce changement.Pour l'ordre de redémarrage, systemd fait ça très bien avec une belle gestion des dépendances.
Mais bref, pour en revenir au sujet, je maintiens que c'est vraiment dommage d'imposer un redémarrage pour tout type de mise à jour. Avec Windows, ça se comprend puisque le système d'exploitation a un défaut intrinsèque qui empêche de mettre à jour un fichier utilisé par un processus en cours d'exécution. Et outre cela, avec un système de mise à jour conçu avec cette nécessité de redémarrer, des problèmes spécifiques se sont certainement créés qui ancrent davantage cette nécessité.
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 2 (+1/-0).
Tu connais tous les softs qui lisent cette configuration ? Non, tu fais une supposition ici qui est dangereuse.
Il est beau ton monde ou tous les softs utilisent systemd, mais c'est un monde imaginaire.
Mais ce n'est pas le cas… Tu peux faire tourner Windows et faire des updates sans redémarrer sous Windows sans problème : https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Disons qu'on peut facilement déterminer une liste majorant celle de ceux qui le lisent effectivement. Si
/etc/truc.confest fourni par le paquettruc, les logiciels qui utilisent aussi ce fichier de configuration auront ce paquet dans leurs dépendances pures ou dans leurs recommandations ou suggestions.Peu importe, la solution existe et fonctionne très bien sur les systèmes qui l'utilisent. Il y a aussi des équivalents, de toute façon c'est un autre aspect du problème de l'ordre de démarrage des services en général, qui est déjà solutionné. Pas besoin de considérer ça comme un obstacle donc.
Intéressante cette approche de modifier le code binaire en mémoire.
Aurais-tu des détails techniques sur l'implémentation, en particulier le lien avec les fichiers sur le support de stockage qui doivent bien être modifiés aussi ?
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
C'est une belle théorie de croire que tous les softs vont avoir le format de package que tu désires et que leur manifeste va correctement inclure ce fichier, surtout si il est toujours présent sur les machines.
Si c'est un obstacle. Parce que l'objectif est d'avoir un système d'update qui met effectivement ta machine à jour et la protège plutôt qu'un système qui fait les choses à moitié.
https://techcommunity.microsoft.com/blog/windowsosplatform/hotpatching-on-windows/2959541
[^] # Re: Atomique ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Bon, alors il faut déjà mettre une chose au clair : je parle de systèmes bien conçus et de logiciels bien intégrés. Genre des distributions avec des vrais paquets de qualité amateur.
Maintenant c'est sûr que si on parle de systèmes dépendant fortement de logiciels propriétaires de qualité professionnelle, on n'a aucun moyen d'être sûr de quoi que ce soit et le plus sûr est évidemment de redémarrer au moindre changement.
Un système qui est capable de démarrer des services pour obtenir un système qui fonctionne, est aussi capable de les redémarrer après une mise à jour. Ou du moins, peut l'être s'il a été conçu avec cette préoccupation. Bref, dire que redémarrer simplement les services concernés après une mise à jour, ce n'est pas fiable parce qu'on ne sait pas dans quel ordre les arrêter et les démarrer, c'est faux de manière générale. Je ne dis pas qu'il n'existe pas des systèmes d'exploitation incapables de le faire, mais simplement que ce problème a déjà été solutionné sur au moins un système, ce qui montre que c'est faisable, c'est tout.
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 0 (+0/-1).
Il est chouette ton dogme, mais quand tu es une boite de plusieurs milliers de postes utilisant les softs dont tu as besoin plutôt que uniquement les softs satisfaisant ta vision dogmatique, ben ta solution part à la poubelle.
Ah ben oui, parce que les logiciels open source on le sait bien, ce n'est jamais de la merde en boite…
Toi tu as du mal à comprendre que cela n'a rien à voir avec quel OS il s'agit, parce que Windows et Linux les 2 savent en théorie gérer les dépendences entre services, mais que plein de services installé à travers des applications venant de 235 sources diffèrentes ne vont pas forcèment suivre les règles, et que cela te plaise ou non ce cas doit être gèré.
[^] # Re: Atomique ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Remarque : needrestart est génial, mais il ne résout pas tous les problèmes de mises à jour non plus. Et redémarrer une machine non plus d'ailleurs : si tu gères une grappe de serveurs pour une base données ou un Kubernetes ou tout autre cas où il faut x machines actives pour que ça marche, alors tu ne peux pas redémarrer des services ou une machine entière quand tu veux sans aucun ordonnancement ou sans procédure particulière (genre cordon/uncordon, attente de fin des connexions en cours, etc.).
Et puis bon quand tu redémarres le service docker/lxc/…, ça a un effet sur tout ce qui est porté par docker/lxc/…
Et puis il y a les cas où needrestart ne veut pas prendre le risque (en tout cas comme choix par défaut) de redémarrer le service et donc diffère le redémarrage dudit service.
[^] # Re: Atomique ?
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
C’est ce qui se fait de plus en plus. Ça a l’énorme intérêt de te faire te rendre compte de ce qu’il se passera quand la machine disparaîtra pour des raisons que tu ne connaît pas.
La gestion très fine des connexions pour ne jamais casser de connexion c’est rare et compliqué, vraiment compliqué. Même des logiciels fait pour comme haproxy ont vraiment du mal avec ça.
Pour lxc je sais pas pour docker non. Tout comme tu peut redémarrer systemd sans redémarrer tes services.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Atomique ?
Posté par pasBill pasGates . Évalué à 1 (+0/-0).
Non effectivement. Mais quand tu as un système de composants (genre COM our Corba) ou ton gestionnaire de fichiers se retrouve à être utilisé à travers RPC par plein d'autres softs ben cela devient soudainement compliqué de savoir quoi fermer et tu peux facilement te retrouver à devoir … tout fermer.
C'est pas pour rien que je te dis que c'est une problématique non trivial, il y a plein de cas à prendre en compte
[^] # 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é à 5 (+3/-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é à 5 (+3/-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é à 6 (+6/-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é à -1 (+6/-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é à 9 (+8/-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 Stéphane Ascoët (site web personnel) . Évalué à 1 (+0/-0).
Je n'ai bien sûr pas d'éléments précis et j'espère bien sûr que la diversité restera (mais comment pourrait-elle l'être au même niveau alors que les forces disponibles sont en quantité limitées?) mais d'une façon générale, je suis allergique à ce genre d'argument. On pourrait prendre presque tous les exemples de la vie quotidiennes pour le démonter… par exemple les idiotphones: en théorie rien ne t'oblige à en avoir un… sauf que la vie, en 2025, devient infiniment galère si tu n'en as pas… un autre: la diffusion de musique dématérialisée… on pouvait entendre à l'époque "il restera toujours des clients pour les supports physiques, c'est juste une possibilité en plus"… 25 ans plus tard, bonjour la galère pour trouver l'équipement hi-fi (et le faire entretenir) et les sources de contenu si tu veux rester en 100% support physique (hors microsillon, mode que je trouve ridicule)…
Les implications peuvent être énormes: par exemple, les médias publics, en particulier, se reposent sur le fait que, ceux qui le souhaitent, peuvent trouver des contenus critiques envers le système en ligne… pour droitiser à fond leurs grilles de programmes… sauf qu'on pouvait tomber par hasard sur les seconds et être surpris, alors qu'avec les premiers, chacun n'écoute/ne regarde que ce qui le maintien grosso-modo dans les idées qu'il a déjà…
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Mais on peut retourner cette logique contre toi dans le sens où sous prétexte d'un changement possible, on ne fait plus rien car on n'a aucune garantie que cela n'ira pas dans un sens qui ne te plaît pas.
Être prudent c'est bien, mais si c'est basé sur rien de bien concret finalement ça n'avance pas à grand chose et n'est pas forcément pertinent.
Il y a de toute façon plein de distros différentes dont plein qui finalement réinventent la roue. Ces ressources pourraient être utilisées pour maintenir des modèles de distributions différentes justement. Si du moins assez de personnes sont convaincues que cela en vaut la peine évidemment.
Pour l'instant il y a bien plus de gens qui ne croient pas au système atomique comme système universel que l'inverse. Aucune distribution majeure n'a encore un plan pour en faire des systèmes principaux et n'a annoncé l'abandon de l'ancien modèle. La plus avancée sur ce terrain là, à savoir Fedora, en est encore loin de ce stade en fait.
Et si tout le monde bascule un jour aux versions atomiques, c'est que les contributeurs auront tous été convaincus de l'intérêt de la chose. Dans ce cas, où est le problème ? Tu veux faire quoi pour les en empêcher ? Les punir, les attacher ? On ne peut pas, et ces contributeurs ne nous doivent en fait rien.
Le code est libre, cela ne signifie pas que quelqu'un doit nécessairement faire le sale boulot pour nous faire plaisir. Si personne ne veut maintenir une distro à l'ancienne (ce qui est à ce jour très hypothétique, perso je n'y crois pas vraiment), ainsi soit-il. S'il y a assez de gens convaincus par l'intérêt de la chose, cela continuera quitte à devoir financer des gens pour cela.
Je ne vois pas pourquoi on devrait râler car des gens tentent des choses en fait. C'est l'essence même du libre de pondre du code pour ses propres besoin, et si les développeurs veulent faire ça, qui est-on pour les en empêcher ? Avec quel prétexte ? Même si le résultat ne te plaît pas, c'est leur doit aussi.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par rewind (Mastodon) . Évalué à 4 (+3/-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é à 6 (+3/-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é à 5 (+3/-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é à 6 (+4/-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é à -1 (+1/-4).
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é à 7 (+5/-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é à 5 (+3/-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é à 2 (+2/-3). Dernière modification le 25 avril 2025 à 17:17.
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é à 5 (+5/-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é à 4 (+3/-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é à 6 (+3/-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é à 2 (+1/-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é à 5 (+3/-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.
[^] # Re: Questions
Posté par Mildred (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 25 avril 2025 à 20:02.
Et est-ce que tu peut faire tourner un logiciel obscur qui a besoin du ttyUSB0 et a besoin de règles udev pour marcher ?
J'ai utilisé Silverblue a un moment et ce genre de truc m'avait vraiment posé problème.
[^] # Re: Questions
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
C'est peut-être là que systemd-nspawn peut être utile, comme l'évoquait gnumdk sous la dépêche consacrée à Fedora 42.
# 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é à 4 (+2/-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é à 6 (+3/-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).
# intéressant
Posté par tkr . Évalué à 2 (+1/-1). Dernière modification le 25 avril 2025 à 14:36.
bonjour,
je découvre à l'instant l'article, que j'ai parcouru jusqu'au milieu
chapeau bas pour le travail effectué
je vais donc certaineemnt répondre au fur & à mesure, en plus de réponses aux commentaires, dans les jours à venir (c'est limite si c'est une thèse résumée)
# fragmentation
Posté par tkr . Évalué à 1 (+0/-1).
Je ne sais pas s'il n'y a que moi que ça étonne, mais ce passage :
ne vous parait pas spécifiquement révélateur de la fragmentation des distributions linux, quitte à ce que l'embarras du choix perde un peu l'utilisateur néophyte?
[^] # Re: fragmentation
Posté par saltimbanque (site web personnel) . Évalué à 3 (+1/-0).
Pratiquement tous les atomic veulent que les applis graphiques soient installées via flatpak. In fine c'est beaucoup moins de fragmentation qu'auparavant, à condition bien sûr qu'il n'y ait pas à maintenir en plus les anciens paquets. Aujourd'hui la transition peut être vue comme douloureuse : anciens paquets deb/rpm, snap, flatpak, appimage… Mais je crois que la fragmentation à travers certaines standardisation va tout de même en diminuant.
# une distro "référence"
Posté par tkr . Évalué à 2 (+1/-1).
ce qui m'étonne :
pourquoi j'ai l'impression qu'avec leurs projets de linux "immuables" il veulent réinventer la roue?
pourquoi ne pas juste prendre une variante de redhat, ou un type debian, et adapter les logiciels nécessaires, par une sorte de tar.gz (juste exécuter le binaire quoi) en complément du gestionnaire de paquets, pour l'ordinateur, comme un debian classique aujourd'hui?
certains lieu publics en ont : j'ai vu que al médiathèque de lyon utilise debian sur ses ordi, la gendarmerie est passée à ubuntu depuis vingt ans.. c'est à ma connaissance plus un problème du politique et de ses décision qu'un problème technique, pour moi le "bureau linux" est largement prêt depuis plus de dix ans… N'oublions pas qu'à la fin des années 90, début 2000, mandrakesoft était en concurrence au brésil contre microsoft pour remporter le marché des écoles.. Les distros étaient déjà prêtes !
la chine et la russie commencent aussi à basculer certains de leurs ordi du service public sur du linux (la corée également) pour garantir une certaine indépendance aux gafam
pour moi c'est largement davantage un problème de décideur et non de fonctionnel technique : suffit de faire tourner les applis métier dans du web par ex, ce qu'a très bien fait la gendarmerie..
[^] # Re: une distro "référence"
Posté par saltimbanque (site web personnel) . Évalué à 3 (+1/-0).
Le billet "Prosthetics" mentionne essentiellement une question de gouvernance, pas vraiment la notion de Atomic.
Mais Thibault cite https://blogs.gnome.org/adrianvovk/2024/10/25/a-desktop-for-all/ qui argumente sur le pourquoi du atomic, notamment
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.