Linux : la méfiance autour d’Ubuntu et de ses Snap reste vive
Maître en sa demeure
Le 09 juillet à 11h21
L’équipe de développement de Tuxedo OS a annoncé qu’elle abandonnait Ubuntu pour Debian comme base pour sa propre distribution. Parmi les raisons citées, des difficultés à adapter le code vieillissant (LTS), une feuille de route IA jugée « opaque » et surtout l’omniprésence des paquets Snap. Ce n’est pas la première fois que le système de Canonical crispe la scène de l’open source.
Linux : la méfiance autour d’Ubuntu et de ses Snap reste vive
Maître en sa demeure
L’équipe de développement de Tuxedo OS a annoncé qu’elle abandonnait Ubuntu pour Debian comme base pour sa propre distribution. Parmi les raisons citées, des difficultés à adapter le code vieillissant (LTS), une feuille de route IA jugée « opaque » et surtout l’omniprésence des paquets Snap. Ce n’est pas la première fois que le système de Canonical crispe la scène de l’open source.
Logiciel
Logiciel
10 min
Tuxedo est une société allemande commercialisant des ordinateurs. À l’instar de System76 avec Pop!_OS aux États-Unis, l’entreprise a fini par créer sa propre distribution, baptisée Tuxedo OS. Elle est basée sur la branche LTS (Long Term Support) d’Ubuntu, à laquelle elle apporte des personnalisations, notamment pour s’assurer que le matériel de ses ordinateurs est correctement pris en charge. Comme pour System76 toutefois, la distribution est librement téléchargeable depuis le site officiel.
Et voilà que dans un communiqué daté du 7 juillet, l’entreprise annonce qu’elle n’utilisera plus Ubuntu LTS. Plutôt que de passer sur la branche classique de la distribution de Canonical, Tuxedo prend un virage plus radical : elle se basera désormais sur Debian Testing, avec une bêta prévue pour « bientôt ». Les raisons données et le choix dans la bascule ont provoqué de nouveaux débats.
Les raisons de Tuxedo
Dans son billet officiel, l’éditeur évoque son modèle hybride : base Ubuntu LTS stable et composants comme le noyau, les navigateurs, la pile graphique et KDE Plasma mis à jour en continu. Or, cette approche devient intenable à mesure qu’une version LTS vieillit : le rétroportage de logiciels modernes devient de plus en plus difficile, les dépendances plus récentes étant souvent indisponibles ou fournies uniquement dans des versions obsolètes. Tuxedo OS suit un modèle de publication hybride qui combine, selon l’entreprise, les points forts des versions continues et des versions ponctuelles.
La société allemande cite cependant trois autres facteurs, propres à la stratégie de Canonical. D’une part, la difficulté croissante à tenir le système de paquets Snap à l’écart du système, Canonical distribuant de plus en plus d’applications au format Snap exclusivement, tout en reléguant progressivement les paquets DEB traditionnels au second plan.
D’autre part, la feuille de route IA annoncée par Mark Shuttleworth lors du dernier Ubuntu Summit, dont la mise en œuvre concrète reste insuffisamment transparente. Enfin, des mises à jour de sécurité qui, selon Tuxedo, mettent parfois plus de temps que nécessaire à atteindre les utilisateurs.
L’entreprise a donc fait le choix de Debian dans sa branche Testing en continu. Ce qui veut dire qu’à la sortie de la version stable de Debian 14, Tuxedo OS restera sur la branche testing, Debian ayant une approche conservatrice des paquets. Outre la modernisation inhérente aux paquets plus récents, cette bascule permet à Tuxedo OS de récupérer des fonctions qui lui faisaient défaut selon elle, notamment le système de fichiers Btrfs – qui sera utilisé par défaut – et Snapper. L’un et l’autre permettront la création automatique d’instantanés (snapshots) et la restauration simplifiée du système. Ces fonctions ne seront disponibles qu’avec Btrfs.
Tuxedo indique dans son billet que le passage de la version actuelle à la prochaine basée sur Debian ne sera pas possible « pour des raisons techniques ». Elle précise cependant qu’un guide complet de migration sera fourni « bien avant la publication finale » du nouveau système, pour expliquer notamment comment transférer les données personnelles. En revanche, un chemin de migration existera vers Kubuntu 26.04. Lui aussi sera publié plus tard.
Les paquets Snap encore dans la ligne de mire
Hors de la stratégie propre à Canonical sur les versions LTS, les critiques de Tuxedo tournent essentiellement sur les paquets Snap et la feuille de route sur l’IA. Même si Mark Shuttleworth, CEO de Canonical, n’a pas été « assez clair » sur cette feuille lors de la conférence Ubuntu Summit, plusieurs points ont été éclaircis depuis. On sait par exemple que Canonical utilisera des modèles locaux pour renforcer certaines capacités « implicites », comme l’amélioration de l’image de la webcam ou la normalisation du son pour le microphone. L’accessibilité sera également aux premières loges, avec notamment une reconnaissance vocale pour tous les champs de saisie présents à l’écran.
Il reste 66% de l'article à découvrir.
Déjà abonné ou lecteur ? Se connecter
Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.
Accédez en illimité aux articles
Profitez d'un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
expert et sans pub.
Commentaires (33)
Le 9 juillet à 11h33
Le 9 juillet à 11h41
APT, Flatpak, Snap, j'étais en mode "ni pour ni contre bien au contraire".
Et puis semaine dernière, Steam qui était installé en Snap ne se lance plus. Problème de sécurité, de droits liés à armorapp, etc.
Eh bien IMPOSSIBLE à remettre d'aplomb! J'y ai passé un temps parfaitement déraisonnable. En vain. Un enfer!
Bon ben ça a fini en désinstallation de Steam en Snap, et réinstallation en APT.
Et tout a refonctionné, direct. Normal.
Bon ben du coup, mon avis est maintenant fait sur Snap. Je le garde éventuellement en tant que groupe sympa pionnier de l'eurodance mais certainement pas en système de gestion d'installation des applis.
Modifié le 9 juillet à 13h32
Et de plus en plus d'applis sont officiellement supportées sur Flatpak, parfois exclusivement (je pense à Discord qui n'a pas de .rpm mais a un Flatpak officiel, ou OBS qui n'a qu'un Flatpak - le paquet dans les dépôts Fedora n'est pas officiel).
Je pense que ça dépends des cas d'usage, sur les très vieilles machines ou quand on est contraint sur le disque ça peut être trop lourd. Ça peut limiter un peu aussi la bidouille.
Le 9 juillet à 15h11
Le 9 juillet à 18h51
Sur Steam OS, les applications sont toutes installées comme ça vu que c'est un OS immutable, d'ailleurs.
Le 9 juillet à 20h48
Là en ce moment j'ai 136 paquets qui prennent 51 Go, en comptant uniquement les applications (hors runtime) j'en ai 91 pour 22Go. J'ai beaucoup de runtimes surtout pour Steam, Bouteilles et GNOME Builder, qui collectionnent les versions de Mesa, Proton et autres environnements de développement. J'ai aussi des apps KDE type KDEnlive d'installées qui prennent pas mal (mais qui prendraient aussi beaucoup de place même hors Flatpak vu qu'elles dépendent de KDE même sur une machine GNOME).
Globalement je trouve que franchement c'est pas délirant vu la taille des applications (j'ai absolument tout sur Flatpak : Steam, Discord, LibreOffice, Firefox, Blender, OBS, Chrome, Lutris, VSCode avec environnement LaTeX, GNOME Builder, etc.) et prendre 1/5 d'un disque de 256Go pour les applicatifs ça me parait pas absurde vu mon usage.
Le 9 juillet à 21h12
Le 9 juillet à 11h45
-T'aura beau sandboxer la chose que dès que tu sauvegarde ton travail... bin c'est un accès au système de fichier...
-Cela n'empêche pas la contamination d'une application (ou d'une lib accompagnante) en amont.
-Même si la concurrence des versions des programmes d'un système reste plus ou moins un problème entier aujourd'hui, faire des gros pâtés n'arrange rien en réalité. A l'heure ou le stockage et la RAM sont devenu des luxes...
Modifié le 9 juillet à 13h48
org.gnome.Platform:45et cette runtime ne sera installée qu'une fois. Il y a un overhead certain, mais on ne fais pas de "gros pâtés", on reste bien en dessous du doublement de taille des logiciels installés (+30% dans mon cas quand j'avais comparé).Snap a énormément de soucis - et je ne l'utilise pas pour ces raisons - mais là t'es juste à côté de la plaque
Le 9 juillet à 16h08
B - Bah oui, ça ne fait pas mieux que le reste. C'est juste pour dire que le problème n'est pas là. Il est notamment dans les détournements de paquets (ou autre). Peut être que de prendre le problème par ce bout là sera porteur de sens. Petit clin d’œil à NPM et le reste des fines équipes (pas de jaloux)...
C - Ton +30% c'est toujours plus que 0%. A titre d'exemple le paquet Debian de Firefox, c'est 70Mo et occupe +250Mo sur disque...
Je le prend comme exemple car un navigateur se trimbale un certain nombre de dépendances. 70Mo +30%, soit... 250Mo+30% je tique un peu. Pas parce que je n'aurai pas la place. Mais parce cela perpétue l'éternelle débauche d'espace de stockage supplémentaire pour une utilité par forcément démontrée.
Tu vas dire "oui mais org.gnome.Platform:45"... Bon alors :
org.gnome.Platform branch 45 is end-of-life.C'est pas une vanne c'est juste pour dire que tu te retrouve à gérer ça comme on le ferait pour les librairies standard... Upgraaaaade.
Pourquoi rajouter une couche alors que l'original fonctionne bien; pour peu qu'on lance APT ??? On penserai même à mettre Snap dans la catégorie bloat software.
Alors ce sont des choix entrepreneuriaux. Il y a les gouts et les couleurs, etc. Maintenant de voir les éditeurs de la chose scander que cela règle les problèmes sur leur site/page dédiées... Juste : Nope.
Le 9 juillet à 20h21
B - Du coup j'ai du mal à voir en quoi c'est un argument contre Flatpak/Snap qu'ils ne protègent pas contre les détournements de paquets upstream (comme tous les autres gestionnaires de paquets). Tu aurais pu mettre "Snap ne fais pas le café" ça aurait le même poids : aucun concurrent ne le fais, ça n'a donc pas vraiment sa place.
C - Le Flatpak de Firefox fait 117Mo en téléchargement et 310Mo sur disque (le Snapstore indique pas la taille et j'ai pas d'Ubuntu pour tester). Il faut rajouter la runtime (600Mo) si c'est le premier Flatpak ou Snap qui l'utilise, sinon c'est partagé. D'où le +30% en gros quand tu commences à avoir une dizaine d'applis.
C'est un exemple que j'ai pris de tête, osef.
Pourquoi utiliser Snap/Flatpak alors qu'on peut utiliser APT ? Parce qu'il y a des intérêts supplémentaires (sécurité, compatibilité, vie privée, etc.).
Pourquoi utiliser APT alors qu'on peut compiler soit-même son paquet ? Parce qu'il y a des intérêts supplémentaires (rapidité, simplicité, etc.).
Je trouve que les avantages passent clairement outre les défauts sur une machine un peu moderne (on est plus au demi-giga près quand les disques font 256Go+ sur la quasi-totalité des machines même bas de gamme) et le simple fait de pouvoir installer KDEnlive sur mon Fedora GNOME sans que ça essaie d'installer KDE, c'est pas mal.
Évidemment tu conseilles pas forcément Flatpak/Snap sur les machines particulièrement anciennes ou aux ressources particulièrement restreintes (type Chromebook convertis à Linux).
Le 9 juillet à 23h45
Prenons l'exemple d'un pack LibreOffice qui soit contaminé. Admettons. Son principe est l'ajout d'un VB sur les fichiers enregistrés que l'utilisateur ouvre ou crée. La sauvegarde même si elle passe par X ou Y fini au bon endroit. Et nous voila avec une compromission. Le principe de protection ne réside pas seulement dans la gestion des processus et de la mémoire (cloisonnement processus, cryptage) mais aussi dans le bon vieux fichier vérolé. A l'ancienne. Et à vrai dire il n'y a même pas besoin d'un paquet compromis. Seul le fichier est nécessaire dans ce cas.
C'est pareil pour tous les systèmes diras-tu. Sauf que cela n'apporte rien de construire un château fortifié supplémentaire quand tout s'écroule dès que le roi fait n'importe quoi.
B - Les ressources et bonnes volontés seraient peut-être plus utiles en amont. Voire même d'améliorer APT et les logiciels / OS dans ce sens.
C - Des Mégas des gigas... C'est le piège. "Toujours plus" finit avec "y'en a plus assez". Ces packs, c'est le même produit mais en plus gros et parfois bien plus lent. Il est plus judicieux de conserver les capacités par l'économie.
Les intérêts supplémentaire que tu cites ne sont pas vraiment là à mes yeux. Si encore c'était sur un machine partagée entre plusieurs personnes... pourquoi pas. Quoique ce n'est pas vraiment l'apanage des geeks (socialement parlant). Ce serait plutôt le fait de l'entreprise. Mais là encore ce serait des cas tordus avec dette technique... Pas une bonne chose.
D'autres solutions existent comme la virtualisation soit pour séparer ses propres activités. Ex : Plusieurs environnement de dev. Ou tout simplement par gout de séparer les choses. Vie privée incluse quand on crypte ses VMs.
Tester un truc sans pourrir ton système ? Pas de problèmes, fait une MV en dupliquant celle que tu as probablement appelé 'base'. Défonces la comme un pitbull mâchouille son jouet en plastique avec toutes les installations que tu peux imaginer. Même de vieux systèmes en sont largement capable avec tous ces "core" qu'on a mis dans les CPUs.
Embarquer l'ensemble des dépendances avec le Snap revient à négliger son système. Je ne pense pas que de faire un
APT update / upgrade / autoremovepuisse casser le bras de quelqu'un. Il est quand même rare de voir des conflits entre les paquets qui force l'usage de chose spécialisés comme celle-ci.Le 9 juillet à 13h42
Ceci étant j'utilise pas mal Flatpak et une fois qu'on à un peu fait le deuil des ressources nécessaires (stockage en particulier), ça reste quand même très pratique pour faire tourner des applications hors de tout problème de dépendance et sans "dégrader" son système (si une dépendance est foireuse je préfère largement qu'elle soit dans une app containérisé que dans le système).
Ceci dit effectivement c'est dommage que la gestion des versions ne soit pas plus facile (surtout que techniquement ça ne pose aucun problème) et pour le coté autorisation même si c'est complet et efficace (facile de restreindre l'accès au périphérique, au réseau, limiter les fichier...) il faut quand même que l'utilisateur se donne le mal de gérer tout ça (et la tentation est grande de juste tout accepter parce qu'on veut juste accéder rapidement a son app).
Modifié le 9 juillet à 12h01
J'en ai marre de perdre du temps avec ça.
Qu'ils arrêtent de nous installer du snap quand on fait un apt install mesgenoux !!!
On ne sais plus si tel truc est en snap ou pas.
Et quand sa déconne, si on oublie qu'il y a une possibilité que ce soit un snap et pas un deb d'installé, c'est la cata... On s'embarque dans des long moment de debug qui seront de toute facon infructueux...
Dernier piege en date pour moi Chromium qui ne voulais pas me présenter le serial USB... Que j'ai été con de pas penser "snap de merde" dès le départ, je me suis acharné pendant des heures avant d'avoir l'eclair de lucidité... Snap viré, Deb installé en 5 minutes mon probleme était réglé...
Le 9 juillet à 13h18
Mais je viens de passer de Kubuntu à Bazzite avec Plasma (équivalent à Fedora Kinoite) avec conception immuable / mises à jour atomiques et donc tout se gère en Flatpak :je ne penses pas revenir en arrière de sitôt.
Le 9 juillet à 13h38
Quand Firefox est devenu Snap Only, j’ai quitté Ubuntu pour Manjaro.
Quand Manjaro a fait de la merde (c’est à dire une a deux fois par ans environ), j’ai migré sur Arch Linux.
Depuis plus aucune envie de changer de distribution.
Cependant pour mon entourage c’est du Linux Mint Debian Edition, je ne suis pas suicidaire.
Le 9 juillet à 13h45
Mais encore faut-il que le choix soit laissé à l'utilisateur.
Par exemple pour avoir la version DEB de Firefox plutôt que la version Snap, il est nécessaire de réaliser plusieurs manipulations non triviales.
Certains rétorqueront que finalement, on "peut" choisir via ces manipulations.
Ce à quoi je répondrais que savonner la planche ne peut constituer un choix valable.
Et cela gâche tout l'intérêt d'une distribution grand public comme Ubuntu.
Bref, Snap est l'une des raisons suffisantes qui m'ont poussé à préférer Mint.
Le 9 juillet à 13h47
Gare au piège de demander au LLM de faire directement les paquets, le temps passé à trouver/fixer tout proprement sera perdu à chaque génération, mieux vaut générer des outils/script qu'un résultat final, et pour chaque nouveau programme lui proposer d'aller vérifier le script le plus récemment généré.
Le 9 juillet à 16h10
C'est un outil qui permet de créer un DEB à partir des sources.
Je l'ai utilisé, fut un temps, et cela fonctionnait plutôt bien.
Le 9 juillet à 15h11
Le 9 juillet à 17h47
Le 9 juillet à 18h27
Lundi à 11h51
Mais ouais c’est pour cette raison que sur des pc avec nvidia comme gpu j’ai mis le mint normal. Sinon je pars sur du debian ou LMDE
Le 9 juillet à 18h49
Deux machines achetées chez eux : réparables comme un rien (ajout de RAM, changement de la batterie et de la pile CMOS sur mon PC pro), et un SAV au top.
Le seul défaut de mon Pulse Gen 1 actuel (qui a bientôt 7 ans et tourne comme un charme), c'est son clavier qui est vraiment médiocre comparé aux standards du marché. J'ose espérer que leurs modèles plus récents font mieux, les photos que je vois évoquent une inspiration MacBook qui n'est pas pour me déplaire.
Par contre, je ne pourrai rien dire sur Tuxedo OS, puisque les deux machines sont sous Manjaro
Le 9 juillet à 22h58
Franchement c'est incompréhensible pour moi; je voudrais faire juste comme sur mac avec homebrew :)
Le 10 juillet à 08h14
Flatpak est donc à Homebrew ce que l'AppStore est au package manager de la distrib (pacman, apt, dnf, etc., selon les variantes). À noter que d'un point de vue UX, les environnements de bureaux masquent cette variété avec leur application de gestion des logiciels qui s'occupent de gérer les différentes sources (ex : dépôts officiels, secondaires, flathub...).
Le 10 juillet à 14h33
Le 10 juillet à 14h47
En soit c'est "juste" que Homebrew a la "chance" d'être seul sur son terrain (enfin, je ne lui connais pas d'alternative). M'est avis que MacOS attire moins les bidouilleurs que Linux et sa diversité de distributions et d'environnements de bureau.
Pour le coup, Flathub a aussi ce côté universel vu qu'il est plus ou moins agnostique de la distrib.
Mais l'un comme l'autre, t'as pas la garantie de tout avoir dedans. Perso si je gère sur MacOS une bonne partie de mes outils avec Homebrew, y'en a que je dois installer à la main parce qu'absents, voire retirés (cas de Texstudio par exemple, considéré "à risque" à cause de l'absence de certificat dev du mainteneur, qui a été retiré).
Côté famille Arch, c'est aussi la même histoire où tu auras la majorité des outils dispo dans les repositories officiels, et une partie du reste dans AUR (en plus des Flatpak).
Lundi à 14h03
Passé la première phase de découverte de Linux, je me rends compte que les deux modèles ont du pour et du contre haha.
Lundi à 11h02
Lundi à 14h01
Le 10 juillet à 07h58
Dommage, au lieu LMDE j'ai installé ubuntu.
Si Tuxedos bascule sur Debian, j'espère qu'ils penseront bien à remonté les pilotes dans les projets upstream.
Le 10 juillet à 18h26
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?