Sans surprise, la prochaine version majeure de Linux Mint, estampillée 20, sera exclusivement 64 bits. Conséquence logique du choix de Canonical, Mint étant basée sur Ubuntu.
Selon Clément Lefèbvre, fondateur de Mint, la plupart des développeurs sont satisfaits de la décision. Il note que Canonical a répondu aux inquiétudes autour des cas Steam, Wine et autres, de manière a priori satisfaisante. La question reste importante pour Mint, qui continuera à surveiller la situation.
La situation est toutefois moins problématique pour les utilisateurs de Mint. Toutes les versions de la distribution sont supportées cinq ans, Mint n’utilisant que des moutures LTS d’Ubuntu comme socle. Mint 20 sera ainsi basée sur Ubuntu 20.04.
Sur une note différente, Clément Lefèbvre s’inquiète de Snap et du pouvoir que prend la solution de conteneurs logiciels de Canonical. Il remarque notamment que la promesse qu’il ne remplacerait pas Apt est en train d’être brisée.
Ubuntu envisage en effet de remplacer le paquet classique de Chromium par une « boite vide » qui renverrait alors vers le snap correspondant. Pour les distributions basées sur Ubuntu et utilisant donc Apt, cela signifie une dépendance au client Snap qui n’était pas prévue. Les développeurs de Mint espèrent pouvoir s’entretenir bientôt avec Canonical sur le sujet.
Commentaires (20)
#1
Je partage l’inquiétude autour de Snap.
L’idée de départ était bonne et facilitait le travail des développeurs, le temps de pouvoir sortir des paquets dédiés aux différentes distrib.
Mais là son usage, qui plus est étendu par Canonical qui le met particulièrement en avant, est de plus en plus fourvoyé et pousse les développeurs à ne faire aucun effort sous prétexte de faire du multi-distrib…
Surtout qu’un snap reste largement plus consommateur de ressources et d’espace qu’un paquet dédié, (plus ou moins) optimisé pour la distribution sur laquelle il va tourner. Aucun système de dépendance etc.
Ça n’a aucun sens d’en promouvoir l’usage pour remplacer les paquets.
Ça me fait penser à tous ces outils (npm, etc) que l’on a en dev web et qui font que les sites/appli font ensuite un poids considérable, donc qui consomment toujours plus de ressources, sous prétexte de faciliter la vie du dev… Alors que le job d’un dev c’est aussi d’optimiser son code et faire en sorte qu’il consomme le moins possible.
Cette dérive est inquiétante je trouve (et illustre une perte de compétences quelques part). Surtout à une époque où l’on devrait réduire la consommation du code à des fins environnementales/énergétiques.
#2
Mème constat.
#3
Si je conçois bien le snap pour des logiciels “isolés” (jeux vidéos par exemple, qui sont dans la très grande majorité autonomes et “autistes”), j’ai du mal à comprendre le snap pour des navigateurs, pour des outils comme blender qui sont parfois des dépendances d’autres logiciels (openshot)
Ca marche bien ça?
Par ailleurs, dans le cas d’une faille openssh, il faudra maintenant mettre à jour les snaps de tous les logiciels l’utilisant? (Chrome, Firefox, Libreoffice, …)
On se retrouve avec les mêmes travers infernaux des téléphones mobiles (mises à jour permanentes, sauvages, sans réelle utilité)…
#4
#5
ou tu utilises une autre distribution
#6
C’est gentil de me dire ce que je dois faire, merci.
" />
Je parle d’en général, Ubuntu est un exemple parmi d’autres.
Le bazar toussaaa c’est chouette, on innove, on fork, on créé des tas de choses, par contre pour maintenir il n’y a plus personne, c’est ça le soucis.
Et accessoirement quand on veut de la pérennité on n’utilise pas Ubuntu.
Tout à fait d’accord avec
brice.wernet , on vit une époque de gaspillage sans consolider les bases. Pendant très longtemps le recyclage d’ordinausores était viable, aujourd’hui je vois mal recycler un cpu < 2 cœurs pour usage navigation web, c’est un fait, ça patine dans la semoule. Dernier exemple en date le raspbery pi est un monstre miniature, mais pour naviguer sur le web il a du mal.
#7
#8
#9
Pas compris ta réaction (oui je ne sais pas le sens de l’image) :)
Sans parler d’obsolescence, on est surtout dans une fuite en avant technologique. On a du matériel avec des capacités énormes mais le code, lui, devient de plus en plus crade et non-optimisé.
Quand je vois ce que l’on arrivait à faire il y a 20 ans avec du matériel limité, ou encore ceux que peuvent faire certains (comme le scène démo), je me dis qu’il y a là des questions à se poser sur comment on conçoit les logiciels à notre époque et les contraintes que l’on impose aux développeurs.
Je le vois tous au quotidien dans le développement web. Et dès que j’essaie de le faire comprendre autour de moi on me répond “on verra plus tard” ou encore “ça fonctionne ? Laisse alors. Si c’est pour gagner quelques ms/ko ça sert à rien” (sauf que “quelques” part ci par là, au final…).
Il faut aller toujours plus vite, donc on sort des outils qui permettent cela, et tant pis si la consommation en ressources augmente exponentiellement par manque d’optimisation du code, et donc augmente in fine l’impact énergétique/écologique.
#10
#11
#12
La discussion sur le glissement vers snap du lieu de deb sur le forum de développement d’Ubuntu
https://community.ubuntu.com/t/please-do-not-use-snap-into-ubuntu-its-too-early/…
#13
#14
#15
#16
#17
#18
#19
#20
Il n’y a pas que des pisseurs de code, il y a aussi les « artistes ». Enfin ceux qui croient l’être en écrivant du code “joli à regarder”.
Et ce code “joli à regarder”, ça peut être une batterie de boucles sans aucun break et autres conditions qui permettrait pourtant d’en sortir le plus vite possible. Il vaut mieux que ça tienne sur le moins de lignes possibles car c’est plus agréable à l’oeil… mais terriblement inefficace, évidemment.