Je ne comprend pas bien quelle est la proposition. Est-ce que c'est de dire à Debian, Ubuntu, Arch, etc d'abandonner leurs formats de paquets et de compiler leurs propres Flatpaks? Auquel cas ça ne résoud pas vraiment les problèmes soulevés: on pourra toujours avoir la mauvaise version d'une lib, un exécutable qui a le même nom qu'un autre, etc.
Ou bien est-ce que l'idée c'est de laisser les développeurs d'applications faire leur packaging et de retirer les applis du dépôt des distributions? Auquel cas, qui va s'occuper des mises à jour de sécurité et du support LTS? Bon l'auteur parle de Arch donc je suppose que le support LTS avec une version fixe de tout les paquets et seulement des mises à jour de sécurité ne l'intéresse pas.
Si j'avais été un troll, j'aurais dit : Traditional packaging is not suitable for non-Green IT applications.
La plupart des applications qui supportent mal le système traditionnel de paquets sont des trucs basés sur Electron, Node.js, et dans une certaine mesure, Python. Donc des trucs fabriqués avec des briques logicielles qui évoluent tellement vite (Y a une nouvelle version majeure de NodeJS par an) qui rendent l'écosystème forcément fragmenté.
L'exemple de OBS avec FFMpeg est cependant intéressant.
Mais pour avoir observé le comportement de Flatpak et de Nix, ben je préfère le deuxième. Mais c'est une préférence personnelle…
Most, if not all, distributions that heavily practice traditional packaging share this common problem: none of them leverage containers or other convenient methods to separate dependencies.
A quoi bon gérer les dépendances si chaque appli vient avec son propre jeu de dépendances?
Le problème fondamental est plutôt l'explosion du nombre de dépendances qui ne gèrent pas la rétrocompatibilité.
Pour résoudre ce problème, il ne faut pas de nouveaux gestionnaires de dépendances (au contraire il y en a trop), mais un travail de fond:
côté dépendances (frameworks, libs, runtimes…) pour se stabiliser ;
côté applications pour se limiter à un faible nombre de dépendances stables ;
côté distributions pour adopter le même gestionnaire de dépendance.
Bon lien.
J'ajouterais pour ma part ce lien qui cause de comment faire un binaire vraiment standalone sous *nix: "you'll need on retainer a UNIX graybeard".
Posté par Yth (Mastodon) .
Évalué à 10.
Dernière modification le 11 septembre 2022 à 19:03.
J'ai mis comme titre une citation du texte : « Unless the packager works around that ». Parlant de différents logiciels ayant besoin de différentes versions d'une dépendance.
On peut donc résumer à ça :
Dans l'enfer actuel des dépendances bordéliques de certaines applications graphiques modernes, le boulot du packager peut devenir compliqué, alors tout ce qui existait avant (le système de package traditionnel) c'est de la merde, faut gicler et utiliser flatpack (ou Nix, soyons ouverts d'esprits) !
Bon, sinon, historiquement, avoir plusieurs versions d'une même dépendance, ça a rarement été un gros problème.
Par exemple :
libpng.so -> libpng16.so
libpng14.so.14 -> libpng14.so.14.22.0
libpng14.so.14.22.0
libpng16.so -> libpng16.so.16.37.0
libpng16.so.16 -> libpng16.so.16.37.0
libpng16.so.16.37.0
Voilà, problème résolu.
Ou encore, les passages de qt4 à qt5 puis qt6, c'est toujours bien transparent, avec plusieurs versions installées en même temps, et chaque logiciel qui sait de laquelle il a besoin.
J'ai quand même envie de dire : « avant » les gens qui faisaient des bibliothèques (ou dépendances, appelez ça comme vous voulez), se foulaient à essayer de faire que ça marche, et qu'on puisse avoir assez facilement en parallèle deux versions différentes lors d'une rupture assez forte de l'api/abi. Ce qui n'a pas toujours été fait de façon propre, et qui a parfois été fait de façon tellement propre qu'on en a voulu aux auteurs de faire chier avec deux versions majeures d'un outil…
Aujourd'hui :
* On laisse faire le gestionnaire de spaghettis, qui tire les dépendances automagiquement, sans se poser de question, et puis comme ça marche pas, on invente des systèmes pour cloisonner tout ça parce que c'est devenu le bordel.
* Alors comme on met du bordel dans des petites boîtes, on se dit qu'un système composé de petites boîte, c'est propre et bien rangé.
* Et on a bien caché le bordel derrière les petites boîtes.
* Et on va considérer que la façon plus propre de faire d'« avant » c'est has-been, faut aller de l'avant et accepter d'avoir de la merde bien rangée.
En tant que vieux con, j'aime bien la sobriété d'avant : se faire chier à inventer des systèmes de bibliothèques partagées, chargées au lancement du programme si elles n'ont pas déjà été chargée par ailleurs, partager l'espace disque, et la mémoire système aussi, pour éviter d'avoir douze fois exactement la même chose, et donc de gaspiller des ressources pour rien.
Mais clairement ce n'est pas à la mode, et il faudrait tout conteneuriser, pour que chaque élément de notre OS embarque dans sa petite boîte l'intégralité de ses dépendances.
Et sous prétexte que ce mode de fonctionnement permettrait d'isoler les différents outils les uns des autres, jusqu'au très bas niveau de l'OS, ça devrait améliorer la sécurité globale du système.
Franchement, je comprends l'argument pour un serveur sur lequel n'importe qui va essayer de faire tourner n'importe quoi n'importe comment.
Mais pour un poste de travail ?
Parce que l'exemple c'est un conflit de nom d'exécutable sur un logiciel pas terriblement libre d'édition de code !
Sous Slackware on a trois paquets dosbox différents, qui naturellement ont tous le même binaire dosbox.
Et ça fonctionne très bien : dosbox est la version stable officielle, dosbox-dev la version de développement à partir des sources (ça a été très utile il y a quelques années quand la dernière version stable avait plus de 8 ans), et dosbox-x, un fork avec des fonctionnalités différentes.
Franchement, le taf du packageur n'est pas mortel hein, renommer les binaires, ya plus complexe…
J'ai quand même envie de lui répondre : « tu te fous de la gueule de qui ? Sérieux ? ».
Mais en vrai, je crois qu'on ne parle pas tous de la même chose. Pas exactement en fait.
Parce qu'il faut bien comprendre à quoi sert une distribution, pourquoi il y en a plusieurs, pourquoi il y en a autant.
Une distribution : c'est une série de choix.
Voilà, c'est tout.
Une distribution ce n'est pas la possibilité de tout faire en toutes circonstances, selon tous les choix possibles et imaginable : elle fait des choix pour toi ta distribution.
Pas tous : tu peux largement la paramétrer, comme la langue, parfois l'environnement graphique (si tu choisis kubuntu c'est pour avoir KDE par exemple, pas pour utiliser Enlightenment).
La majorité des distribs ne te laissent pas le choix du système d'init (quel qu'il soit), ou du serveur audio. C'est pas si souvent qu'on peut basculer facilement entre X.org et Wayland, en général soit une distrib est restée sous X.org, soit elle est passée sous Wayland.
Des choix, que des choix fait pour toi, pour te simplifier la vie.
Un système via conteneurs type flatpak, ou mieux Nix, c'est s'affranchir de la distribution, c'est vouloir fonctionner partout en dehors de toute distribution, c'est faire des choix à la place de la distribution, et donc au final à ta place, puisque ces choix seront fait quelle que soit ta propre distribution.
C'est une logique hégémonique et uniformisante en réalité.
Et ça ne révolutionne strictement rien, il est toujours possible pour un logiciel d'embarquer ses propres versions de certaines bibliothèques, sans soucis, sans flatpak, le système de bibliothèque partagée a résolu ce problème depuis des décennies (cf LD_LIBRARY_PATH), et c'est un peu pour ça que des jeux proprios binaires assez vieux tournent encore, et sans flatpack ou conteneurs…
Bref, encore un type qui chouine sur la non uniformité de l'écosystème Linux, mais sans dire directement « à quoi ça sert d'avoir autant de distrib ? ».
Yth, ça sert à ce que je m'en fous de ton avis, j'utilise mon PC comme je veux, et ça te regarde exactement autant que ce qu'il se passe dans mon assiette, dans ma douche, ou dans mon lit.
Posté par Yth (Mastodon) .
Évalué à 4.
Dernière modification le 13 septembre 2022 à 08:55.
flatpack a une logique uniformisante : un gestionnaire de paquet unique en toutes circonstances, non ?
La logique hégémonique vient des gens qui disent qu'on devrait tout virer pour mettre ça à la place.
L'un sans l'autre, à la rigueur, je m'en fous, les deux c'est un brin agressif, hautain genre vous êtes tous has-been.
flatpack a une logique uniformisante : un gestionnaire de paquet unique en toutes circonstances, non ?
Le gestionnaire de paquet qui indique ne s'adresser qu'aux logiciels graphiques ? En quoi ? Parce qu'il est disponible quelque soit la distribution comme nix ou pkg-src par exemple ?
La logique hégémonique vient des gens qui disent qu'on devrait tout virer pour mettre ça à la place.
Plus que la LSB qui dit que la norme c'est rpm ? Qu'est-ce qui différencie une volonté d'hégémonie (tout à fait présentée comme négative) et une volonté de standardisation ? La discussion ? C'est ce qu'on a ici et dont fait parti cet article, la discussion n'empêche pas d'avoir un avis.
Monter sur ses grands chevaux comme ça en sortant des grands principes je trouve ça ridicule. Ça fait 20 ans que la discussion existe (oui ça existait avant l'arrivée de flatpack). On peut resté détendu je pense et éviter de prêter à ceux qui ne sont pas du même avis des adjectifs tout à fait superfétatoires.
Il y a une différence entre un « standard » ou une « bonne pratique » et dire « jetez vos trucs has-been et passez à ce truc top-moumoute moderne qui résout… un problème… peut-être ».
LSB n'a jamais été qu'un guide de bonne pratiques qui a été suivi jusqu'à un certain point par les gens qui voulaient bien le suivre.
Alors le monsieur il fait un billet d'humeur, bah je fais une réponse d'humeur, et parfois les mots sont un poil hyberboliques.
Et alors ?
Je n'essaie de convaincre personne, même pas l'auteur.
# Mouais
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
Je ne comprend pas bien quelle est la proposition. Est-ce que c'est de dire à Debian, Ubuntu, Arch, etc d'abandonner leurs formats de paquets et de compiler leurs propres Flatpaks? Auquel cas ça ne résoud pas vraiment les problèmes soulevés: on pourra toujours avoir la mauvaise version d'une lib, un exécutable qui a le même nom qu'un autre, etc.
Ou bien est-ce que l'idée c'est de laisser les développeurs d'applications faire leur packaging et de retirer les applis du dépôt des distributions? Auquel cas, qui va s'occuper des mises à jour de sécurité et du support LTS? Bon l'auteur parle de Arch donc je suppose que le support LTS avec une version fixe de tout les paquets et seulement des mises à jour de sécurité ne l'intéresse pas.
# Green IT
Posté par Glandos . Évalué à 10.
Si j'avais été un troll, j'aurais dit : Traditional packaging is not suitable for non-Green IT applications.
La plupart des applications qui supportent mal le système traditionnel de paquets sont des trucs basés sur Electron, Node.js, et dans une certaine mesure, Python. Donc des trucs fabriqués avec des briques logicielles qui évoluent tellement vite (Y a une nouvelle version majeure de NodeJS par an) qui rendent l'écosystème forcément fragmenté.
L'exemple de OBS avec FFMpeg est cependant intéressant.
Mais pour avoir observé le comportement de Flatpak et de Nix, ben je préfère le deuxième. Mais c'est une préférence personnelle…
# Problème dans le fondement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 12 septembre 2022 à 08:35.
A quoi bon gérer les dépendances si chaque appli vient avec son propre jeu de dépendances?
Le problème fondamental est plutôt l'explosion du nombre de dépendances qui ne gèrent pas la rétrocompatibilité.
Pour résoudre ce problème, il ne faut pas de nouveaux gestionnaires de dépendances (au contraire il y en a trop), mais un travail de fond:
Bonne chance pour y arriver. En attendant : https://notes.volution.ro/v1/2022/01/notes/fbf3f06c/#a-possible-worse-is-better-solution
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Problème dans le fondement ?
Posté par freem . Évalué à 2.
Bon lien.
J'ajouterais pour ma part ce lien qui cause de comment faire un binaire vraiment standalone sous *nix: "you'll need on retainer a UNIX graybeard".
# Unless the packager works around that
Posté par Yth (Mastodon) . Évalué à 10. Dernière modification le 11 septembre 2022 à 19:03.
J'ai mis comme titre une citation du texte : « Unless the packager works around that ». Parlant de différents logiciels ayant besoin de différentes versions d'une dépendance.
On peut donc résumer à ça :
Dans l'enfer actuel des dépendances bordéliques de certaines applications graphiques modernes, le boulot du packager peut devenir compliqué, alors tout ce qui existait avant (le système de package traditionnel) c'est de la merde, faut gicler et utiliser flatpack (ou Nix, soyons ouverts d'esprits) !
Bon, sinon, historiquement, avoir plusieurs versions d'une même dépendance, ça a rarement été un gros problème.
Par exemple :
libpng.so -> libpng16.so
libpng14.so.14 -> libpng14.so.14.22.0
libpng14.so.14.22.0
libpng16.so -> libpng16.so.16.37.0
libpng16.so.16 -> libpng16.so.16.37.0
libpng16.so.16.37.0
Voilà, problème résolu.
Ou encore, les passages de qt4 à qt5 puis qt6, c'est toujours bien transparent, avec plusieurs versions installées en même temps, et chaque logiciel qui sait de laquelle il a besoin.
J'ai quand même envie de dire : « avant » les gens qui faisaient des bibliothèques (ou dépendances, appelez ça comme vous voulez), se foulaient à essayer de faire que ça marche, et qu'on puisse avoir assez facilement en parallèle deux versions différentes lors d'une rupture assez forte de l'api/abi. Ce qui n'a pas toujours été fait de façon propre, et qui a parfois été fait de façon tellement propre qu'on en a voulu aux auteurs de faire chier avec deux versions majeures d'un outil…
Aujourd'hui :
* On laisse faire le gestionnaire de spaghettis, qui tire les dépendances automagiquement, sans se poser de question, et puis comme ça marche pas, on invente des systèmes pour cloisonner tout ça parce que c'est devenu le bordel.
* Alors comme on met du bordel dans des petites boîtes, on se dit qu'un système composé de petites boîte, c'est propre et bien rangé.
* Et on a bien caché le bordel derrière les petites boîtes.
* Et on va considérer que la façon plus propre de faire d'« avant » c'est has-been, faut aller de l'avant et accepter d'avoir de la merde bien rangée.
En tant que vieux con, j'aime bien la sobriété d'avant : se faire chier à inventer des systèmes de bibliothèques partagées, chargées au lancement du programme si elles n'ont pas déjà été chargée par ailleurs, partager l'espace disque, et la mémoire système aussi, pour éviter d'avoir douze fois exactement la même chose, et donc de gaspiller des ressources pour rien.
Mais clairement ce n'est pas à la mode, et il faudrait tout conteneuriser, pour que chaque élément de notre OS embarque dans sa petite boîte l'intégralité de ses dépendances.
Et sous prétexte que ce mode de fonctionnement permettrait d'isoler les différents outils les uns des autres, jusqu'au très bas niveau de l'OS, ça devrait améliorer la sécurité globale du système.
Franchement, je comprends l'argument pour un serveur sur lequel n'importe qui va essayer de faire tourner n'importe quoi n'importe comment.
Mais pour un poste de travail ?
Parce que l'exemple c'est un conflit de nom d'exécutable sur un logiciel pas terriblement libre d'édition de code !
Sous Slackware on a trois paquets dosbox différents, qui naturellement ont tous le même binaire dosbox.
Et ça fonctionne très bien : dosbox est la version stable officielle, dosbox-dev la version de développement à partir des sources (ça a été très utile il y a quelques années quand la dernière version stable avait plus de 8 ans), et dosbox-x, un fork avec des fonctionnalités différentes.
Franchement, le taf du packageur n'est pas mortel hein, renommer les binaires, ya plus complexe…
J'ai quand même envie de lui répondre : « tu te fous de la gueule de qui ? Sérieux ? ».
Mais en vrai, je crois qu'on ne parle pas tous de la même chose. Pas exactement en fait.
Parce qu'il faut bien comprendre à quoi sert une distribution, pourquoi il y en a plusieurs, pourquoi il y en a autant.
Une distribution : c'est une série de choix.
Voilà, c'est tout.
Une distribution ce n'est pas la possibilité de tout faire en toutes circonstances, selon tous les choix possibles et imaginable : elle fait des choix pour toi ta distribution.
Pas tous : tu peux largement la paramétrer, comme la langue, parfois l'environnement graphique (si tu choisis kubuntu c'est pour avoir KDE par exemple, pas pour utiliser Enlightenment).
La majorité des distribs ne te laissent pas le choix du système d'init (quel qu'il soit), ou du serveur audio. C'est pas si souvent qu'on peut basculer facilement entre X.org et Wayland, en général soit une distrib est restée sous X.org, soit elle est passée sous Wayland.
Des choix, que des choix fait pour toi, pour te simplifier la vie.
Un système via conteneurs type flatpak, ou mieux Nix, c'est s'affranchir de la distribution, c'est vouloir fonctionner partout en dehors de toute distribution, c'est faire des choix à la place de la distribution, et donc au final à ta place, puisque ces choix seront fait quelle que soit ta propre distribution.
C'est une logique hégémonique et uniformisante en réalité.
Et ça ne révolutionne strictement rien, il est toujours possible pour un logiciel d'embarquer ses propres versions de certaines bibliothèques, sans soucis, sans flatpak, le système de bibliothèque partagée a résolu ce problème depuis des décennies (cf LD_LIBRARY_PATH), et c'est un peu pour ça que des jeux proprios binaires assez vieux tournent encore, et sans flatpack ou conteneurs…
Bref, encore un type qui chouine sur la non uniformité de l'écosystème Linux, mais sans dire directement « à quoi ça sert d'avoir autant de distrib ? ».
[^] # Re: Unless the packager works around that
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Dans ton lit, tu préfères gérer les paquets à la main ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Unless the packager works around that
Posté par Yth (Mastodon) . Évalué à 2.
Je dirais juste que ça fait longtemps qu'il n'y a plus eu de Core Dumped.
[^] # Re: Unless the packager works around that
Posté par barmic 🦦 . Évalué à 0.
Ça manque d'exagération à mon avis. Ils tuent pas des bébés chats aussi ? Ça marche bien sur internet
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Unless the packager works around that
Posté par Yth (Mastodon) . Évalué à 4. Dernière modification le 13 septembre 2022 à 08:55.
flatpack a une logique uniformisante : un gestionnaire de paquet unique en toutes circonstances, non ?
La logique hégémonique vient des gens qui disent qu'on devrait tout virer pour mettre ça à la place.
L'un sans l'autre, à la rigueur, je m'en fous, les deux c'est un brin agressif, hautain genre vous êtes tous has-been.
[^] # Re: Unless the packager works around that
Posté par barmic 🦦 . Évalué à 2.
Le gestionnaire de paquet qui indique ne s'adresser qu'aux logiciels graphiques ? En quoi ? Parce qu'il est disponible quelque soit la distribution comme nix ou pkg-src par exemple ?
Plus que la LSB qui dit que la norme c'est rpm ? Qu'est-ce qui différencie une volonté d'hégémonie (tout à fait présentée comme négative) et une volonté de standardisation ? La discussion ? C'est ce qu'on a ici et dont fait parti cet article, la discussion n'empêche pas d'avoir un avis.
Monter sur ses grands chevaux comme ça en sortant des grands principes je trouve ça ridicule. Ça fait 20 ans que la discussion existe (oui ça existait avant l'arrivée de flatpack). On peut resté détendu je pense et éviter de prêter à ceux qui ne sont pas du même avis des adjectifs tout à fait superfétatoires.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Unless the packager works around that
Posté par Yth (Mastodon) . Évalué à 5.
Il y a une différence entre un « standard » ou une « bonne pratique » et dire « jetez vos trucs has-been et passez à ce truc top-moumoute moderne qui résout… un problème… peut-être ».
LSB n'a jamais été qu'un guide de bonne pratiques qui a été suivi jusqu'à un certain point par les gens qui voulaient bien le suivre.
Alors le monsieur il fait un billet d'humeur, bah je fais une réponse d'humeur, et parfois les mots sont un poil hyberboliques.
Et alors ?
Je n'essaie de convaincre personne, même pas l'auteur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.