Connexion Premium

Linux : la méfiance autour d’Ubuntu et de ses Snap reste vive

Maître en sa demeure

Linux : la méfiance autour d’Ubuntu et de ses Snap reste vive

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.

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.

Cadenas en colère - Contenu premium

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

Commentaires (33)

votre avatar
C'est fou alors que même M$ se dit qu'il faut augmenter les perf et réduire l'empreinte mémoire. Ubuntu Continue avec ces snap de m... Heureusement il est encore possible de le désactiver mais c'est pénible.
votre avatar
Je n'avais à la base pas plus d'à priori que ça sur Snap.

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. :non:
votre avatar
Je suis convaincu par Flatpak personnellement, je ne jure que par ça. Il y a beaucoup d'intérêts techniques (permissions à la Android/iOS, sandboxing, codecs nécessaires inclus sans installation supplémentaire, versions récentes même sur les distros sous freeze, etc.) qui, dans mon cas d'usage, supplantent largement les défauts (temps de démarrage un peu supérieur - mais sur matériel moderne ça se compte en dixième de secondes, plus d'espace disque utilisé).

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.
votre avatar
Pour le coup Flatpak est complètement inutilisable sur des machines qui ont peu de stockage. Ça bouffe rapidement des dizaines de Go même si tu installes quelques pauvres utilitaires.
votre avatar
Pour le coup Flatpak est complètement inutilisable sur des machines qui ont peu de stockage. Ça bouffe rapidement des dizaines de Go même si tu installes quelques pauvres utilitaires.
C'est effectivement leur très gros défaut, ça tanke le /var comme un rien...

Sur Steam OS, les applications sont toutes installées comme ça vu que c'est un OS immutable, d'ailleurs.
votre avatar
Ah au contraire, je trouve que ça va. De ce que j'avais vu, en gros c'est +30% à +40% par rapport aux paquets de la distro dès qu'on commence à avoir plusieurs applications, vu que les runtimes sont lourdes mais partagées. Évidemment Flatpak prends beaucoup plus de place (relativement aux applis) quand on installe juste Bloc-notes et Calculatrice que quand on installe aussi Steam, Discord, etc. sur la même runtime.

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.
votre avatar
Bah perso j'ai bouffé la moitié du stockage de mon steam deck 64Go avec quelques utilitaires et émulateurs qui unitairement prennent quelques dizaines/centaines de mo. Et comme tu peux pas bouger ça sur la carte SD, bah c'est galère.
votre avatar
Le problème de Snap c'est qu'en réalité il ne règle aucun problème.

-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...
votre avatar
Du mal à comprendre...


  • Non, si je sandboxe l'application et ne l'autorise qu'à toucher à /run/[pid]/, elle ne pourra toucher qu'à ça, pas d'accès filesystem complet. Elle pourra pas lire mes dossiers personnels sauf si je lui donne un accès (ce qui créé une copie virtuelle dans le /run/[pid])

  • Et ? C'est comme dire que Docker n'empêche pas la contamination amont des images, c'est pas le but. Son but est d'empecher une image contaminée d'infecter le système. Donc oui, la capote protège pas contre les crampes. D'ailleurs APT/DNF/pacman non plus n'empêchent pas la contamination amont, mais si le dépôt est compromis, c'est direct accès root sur les machines (le cas récent de l'AUR est un super exemple).

  • Il y a des systèmes en place pour limiter ça, on utilise des plateformes de base mutualisées. Par exemple, plusieurs applications peuvent dépendre de org.gnome.Platform:45 et 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
votre avatar
A - C'est pas ça. Si tu prends ton Firefox en mode sandboxé (expression générique hein, dans le sens de plus ou moins cloisonné). Qu'il te prenne l'idée de sauvegarder une page quelconque. Tu donneras bien accès au système de fichier. Et si tu ne le pouvais pas, c'est juste stupide; on sera d'accord je suppose. Pareil pour Gimp, etc. Dans un usage de logiciel desktop, il y a bien un moment ou il faut sauvegarder ses créations. Si le soft/lib/snap est corrompu...

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.
votre avatar
A - Non, tu as un portal pour ça. Firefox va stocker le fichier dans son dossier /run/[pid] et il sera par la suite copié au bon emplacement. Et dans le sens inverse, quand tu fais "ouvrir avec" ça utilise le portal de l'environnement de bureau (ça ouvre la fenêtre de sélection de fichier de GNOME/KDE) pour donner accès uniquement au fichier sélectionné.

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.
Tu vas dire "oui mais org.gnome.Platform:45"... Bon alors : org.gnome.Platform branch 45 is end-of-life.
C'est un exemple que j'ai pris de tête, osef.
Pourquoi rajouter une couche alors que l'original fonctionne bien; pour peu qu'on lance APT
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).
votre avatar
Firefox va stocker le fichier dans son dossier /run/[pid] et il sera par la suite copié au bon emplacement.
A - Avec une page qui charge un joli petit script ??

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 / autoremove puisse 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.
votre avatar
J'évite Snap parce que de mon expérience il reste beaucoup de problème (et les autres commentaires semble aussi aller dans ce sens) et plus globalement parce que c'est géré par Canonical.

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).
votre avatar
Comme d'hab, je ne vais pas rater une occasion de cracher sur SNAP.
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é...
votre avatar
Je n'étais jusqu'ici pas favorable à Snap, Flatpak ou tout autre solution de containers qui à mon sens alourdi considérablement le fonctionnement d'une machine.
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.
votre avatar
Quand Snap est sorti j’ai grincé des dents.
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.
votre avatar
Que Ubuntu pousse son Snap pour tout et n"importe quoi, je n'y vois aucun grief.

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.
votre avatar
J'ai aussi abandonné Ubuntu à cause de Snap. Désormais tout ce qui a besoin d'un environnement stable est sous Debian, et au pire si je n'ai ni dépôt ni paquets disponibles pour quelque chose dont j'ai besoin, je demande à un LLM installé localement (GLM ou Qwen-code) de me concocter un script pour créer un paquet DEB de telle ou telle app quand c'est nécessaire, histoire de gratter du temps. (Que je passe en revue, rapidement)
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é.
votre avatar
Je conseillerai Checkinstall : https://doc.ubuntu-fr.org/checkinstall

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.
votre avatar
Je me demande dans combien de temps Linux Mint passera définitivement sur LMDE.
votre avatar
Ca ne m'étonnerait vraiment pas que d'ici qques années (avant 2030) ca se fasse.
votre avatar
le souci que je peux voir avec LMDE pour les users basiques, c'est qu'il manque le gestionnaire de pilotes pour gérer les firmwares intel et la purge nommée nvidia...
votre avatar
Ils pourront ptete le récupérer et l’adapter ?
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
votre avatar
Tuxedo c'est du matos pas dégueux, yabon :love:

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 :transpi:
votre avatar
Pour moi qui oscille entre Mac et Linux, je dois dire que la gestion de l'installation logiciel sur ce dernier est un point noir: on comprend vite qu'on ne pourra pas avoir une seule solution, certaines sont plus simples, d'autres plus sûres, d'autres mieux intégrées; mais au final il y a souvent des problèmes!
Franchement c'est incompréhensible pour moi; je voudrais faire juste comme sur mac avec homebrew :)
votre avatar
Franchement c'est incompréhensible pour moi; je voudrais faire juste comme sur mac avec homebrew :)
Un peu contradictoire, car homebrew n'est pas un package manager natif MacOS et donc une solution alternative. Le package manager natif, c'est l'AppStore (en plus de l'installation unitaire).

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...).
votre avatar
Je vois ce que tu veux dire mais je trouve ça juste dommage que la plupart si ce n'est toutes les apps que j'utilise sur Linux soient dispo sur Homebrew de manière simple et centralisée alors que ce n'est pas le cas sur Linux...
votre avatar
Oui je comprend mieux l'idée.

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).
votre avatar
Certes... ce n'est pas tant qu'il soit tout seul que le fait que le Mac soit une seule distribution avec un hardware homogène :)
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.
votre avatar
Ben homebrew est disponible sous linux si ça te plait tant que ça il suffit de s'en servir dessus, non ?
votre avatar
Sur Linux on ne peut pas télécharger de casks malheureusement!
votre avatar
Petit retour d'un utilisateur d'un portable de Tuxedo: produit agréable mais j'étais très surpris de pas pouvoir installé la distribution que je voulais après mon achat. Le wifi fonctionnait mais pas le port ethernet. 😡
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.
votre avatar
J'ai lu et immédiatement compris : ils reproduisent Manjaro avec ubuntu et ils vont répliquer avec debian