Plus sérieusement, j'ai l'impression qu'on arrive à la croisée des chemins. J'avais vu par le passé des devs se plaindre ça et là de la façon dont certaines distros empaquetaient leurs applis, mais à présent, les Linux atomiques (Bazzite en tête) me semblent bien parties pour devenir le paradigme dominant des Linux pour le bureau, et dans ce paradigme, les paquets, c'est Flathub, Homebrew, ou rien. Ou, dans le cas des Fedora, les Flatpaks de chez eux qui sont sélectionnés par défaut dans la boutique d'applis et qui cassent les pieds à tout le monde. KDE et GNOME ambitionnent de sortir chacun leur propre OS sans gestionnaire de paquets, juste le système de base, et Flatpak. Les utilisateurs feront-ils encore la différence ?
Posté par Jean Gabes (site web personnel) .
Évalué à 2 (+0/-0).
Dernière modification le 18 février 2025 à 07:53.
Pour avoir été à la tête d'un éditeur de logiciel pour Linux dans le passé: oui, avoir un standard n'est pas, mais alors vraiment pas une mauvaise chose quand tu dois gérer plusieurs distributions.
Et avoir un standard ne t’empêche en rien de le distribuer autrement si tu as envie et que tu as la force de frappe derrière pour gérer les innombrables soucis que ça apporte.
Tant que tu as toujours le choix, en quoi tu leur interdirais d'avoir leur app store d'applis? Si tu n'es pas content, tu pourras monter le tiens et tenter d'attirer des utilisateurs mécontents du premier.
Mais j'ai comme dans l'idée que les utilisateurs ne suivront pas en masse, linuxiens ou pas.
comme tout le monde… faire un .deb nécessite un doctorat. un trillion de commandes différente (dh, deb, dpkg) et un trillions de fichiers de syntaxe différente. pour l'utilisateur apt, apt-*, aptitude. j'ai jamais compris l'engouement pour ce gestionnaire de paquet.
même si je suis pas fan du RPM, c'est un .spec et on en parle plus.
vive apk.
git is great because linus did it, mercurial is better because he didn't
Posté par Psychofox (Mastodon) .
Évalué à 7 (+5/-1).
Dernière modification le 15 février 2025 à 16:40.
C'est que le flathub est un bordel sans nom mélangeant des paquets officiellement préparé par les développeurs des applis et des paquets fournis par des tiers.
Ce que tu décris c'est un problème réel mais différent de celui du lien. Ici, on parle de Flatpaks fournis par Fedora qui sont présélectionnés par défaut dans les applis d'installation de Fedora (Logiciels ou Discover) au détriment des Flatpaks de Flathub. Et en général, il s'avère que les Flatpaks de Fedora sont moins bons que ceux de Flathub, au point où les devs upstream se plaignent qu'on leur remonte des problèmes qu'ils n'ont pas causé et qu'ils ne peuvent pas résoudre.
Ceci dit, on pourrait imaginer qu'il se passe la même chose avec des Flatpaks non officiels sur Flathub qui seraient de mauvaise qualité. Mais il me semble que c'est moins pernicieux dans ce cas de figure — en tout cas, je n'irai pas jusqu'à dire que c'est "un bordel sans nom" (par exemple, les paquets non officiels sont bien signalés comme tel par une pastille jaune sur leur page Flathub).
On arrive sur des problématiques classiques de périmètres non ?
Si l'upstream a une "équipe expérimentée" elle voudra gérer son empaquetage et ne pas être gênée par la ou les distributions et des rapports de bug inutiles.
Si la distribution a une "équipe expérimentée" elle voudra gérer son empaquetage et ne pas être gênée par l'upstream et sa gestion des dépendances et ses ruptures d'API et de comportement pour cause de support long.
Si l'upstream n'a pas/plus trop d'"équipe expérimentée", les personnes utilisatrices veulent que la distribution gère, et que ça soit harmonieux, cohérent et pas trop gourmand.
Si les personnes utilisatrices sont expérimentées, elles veulent des paquets récents et donc plutôt de l'upstream (sans parler des paquets hors distrib et empaquetage upstream si c'est des dév qui voudront du cargo/pip/npm/docker/CPAN/…)
Si l'équipe upstream et/ou l'équipe distribution et/ou les personnes utilisatrices ont des opinions fortes ou un relationnel sous-optimal alors des désaccords et des tensions apparaissent.
Si l'équipe sécurité s'en mêle… bon ok on n'installe rien ça règle la question.
(c'est un peu comme le mythique périmètre de l'équipe DevSecOpsArchFinIT)
Ce que tu ne comprends pas c'est que le repo fedora est une réponse directe à ce problème pour que ses utilisateurs de silverblue puissent avoir accès aux mėmes applis que sur Fedora standard sans l'innondation d'applis proprios et de paquets non sûrs.
Par contre je trouve la communication de l'équipe obs assez hypocrite. les flatpacks de fedora sont faits à partir des rpms et ils n'ont jamais râlés sur l'existence de obs studio dans les rpms ni dans les paquet des autres distribs. Du coup pour quoi faire des menaces pour une version identique, mais juste fournie via un repo flatpak au lieu de rpm?
Ce que tu ne comprends pas c'est que le repo fedora est une réponse directe à ce problème pour que ses utilisateurs de silverblue puissent avoir accès aux mėmes applis que sur Fedora standard sans l'innondation d'applis proprios et de paquets non sûrs.
Si flathub splittait ses repo en free from upstream, free fron third parry, non-free from upstream, non-free from third party les distros comme Fedora n'auraient pas à gérer une duplication des applis libres dans leur propre repo et les utilisateurs pourraient facilement prioriser les applis libres ou pas libres de source upstream.
Par contre je trouve la communication de l'équipe obs assez hypocrite. les flatpacks de fedora sont faits à partir des rpms et ils n'ont jamais râlés sur l'existence de obs studio dans les rpms ni dans les paquet des autres distribs. Du coup pour quoi faire des menaces pour une version identique, mais juste fourni via un repo flatpak?
Si flathub splittait ses repo en free from upstream, free fron third parry, non-free from upstream, non-free from third party les distros comme Fedora n'auraient pas à gérer une duplication des applis libres dans leur propre repo et les utilisateurs pourraient facilement prioriser les applis libres ou pas libres de source upstream.
Mais c'est déjà le cas non ? Le site Flathub (sur sa page recherche, mais ça discute de généraliser le filtrage) et Logiciels de GNOME (là aussi ils en parlent) permettent tous deux de n'afficher que les applis libres et/ou vérifiées. Les utilisateurs peuvent prioriser avec ça.
Pour moi, la raison pour laquelle Fedora a son propre repo Flatpak, c'est avant tout parce qu'elle considère que c'est la raison d'être d'une distro que de proposer ses propres repos. Et tout le débat linké dans un des liens de l'article porte sur cette raison d'être, à l'heure où Flathub prend de l'importance, comme l'explique Benoît plus haut.
Du coup pour quoi faire des menaces pour une version identique, mais juste fourni via un repo flatpak?
Est-elle identique ? De ce que j'en ai lu, les problèmes du Flatpak Fedora d'OBS viennent de la version du runtime dont il dépend et des permissions liées au sandboxing, qui sont deux aspects spécifiques à Flatpak qui ne concernent pas les RPM. Accessoirement, quand tu utilises un Linux atomique, l'idée c'est aussi de se passer au maximum des RPM.
Posté par Psychofox (Mastodon) .
Évalué à 4 (+2/-1).
Dernière modification le 18 février 2025 à 08:02.
Mais c'est déjà le cas non ? Le site Flathub (sur sa page recherche, mais ça discute de généraliser le filtrage) et Logiciels de GNOME (là aussi ils en parlent) permettent tous deux de n'afficher que les applis libres et/ou vérifiées. Les utilisateurs peuvent prioriser avec ça.
permettent / peuvent. Là est la clé. Je te parles de dépôts séparés, tu me parles de clients. Tous les spins de Fedora n'utilisent pas Gnome Software.
Fedora ne veut proposer que du logiciel libre par défaut. L'utilisateur doit sciemment activer des repos s'il veut du non-libre. Là avec flathub qui propose tout en un repo, les utilisateurs peuvent installer du non-libre ou du malware par erreur en 1 click.
Est-elle identique ? De ce que j'en ai lu, les problèmes du Flatpak Fedora d'OBS viennent de la version du runtime dont il dépend et des permissions liées au sandboxing, qui sont deux aspects spécifiques à Flatpak qui ne concernent pas les RPM.
Le problème réel c'est que des utilisateurs se plaignent de leur problème sur les canaux d'aides et de communication d'OBS au lieu d'utiliser celui de Fedora quand ils rencontrent un problème. Si ce sont de simple problèmes de permissions ils peuvent être résolus facilement par Fedora s'ils ont un rapport de bug. Comment améliorer ça? Je ne sais pas. C'est naturel d'aller voir du côté de l'upstream mais c'est aussi à l'upstream de savoir dire: si t'as un problème avec le flatpak de Fedora que tu ne peux pas reproduire avec notre flatpak, gueule chez Fedora.
Mais on pourrait aussi critiquer le flatpak upstream de OBS. Si le principe des paquets maintenus par les distribution existe, c'est parce que les développeurs sont parfois incapable de faire les choses proprement et prennent les pires raccourcis dès qu'ils rencontrent un problème (les fameux chmod 777 partout par grosse flemme). Du coup ben si tu regardes le flatpak d'OBS tu vois qu'il donne permission à tous les filesystems (au lieu de choisir le homedir ou un sous-ensemble du homedir) sans exception. Je ne vois pas bien pourquoi, dans un système proposant un encapsulage des applications et de leurs permissions, on donnerait à un logiciel de streaming accès à tout ton filesystem. Alors le problème sous-jacent, c'est que flathub et l'encapsulage, ça reste un peu trop tout ou rien et la meilleure solution serait d'avoir un système comme android qui peut de manière interactive permettre à l'utilisateur de choisir à quel espace disque il donne l'accès à une application. Mais clairement, les devs d'OBS ont choisi la voie de la facilité et ont font les gros cochons avec leur flatpak pour avoir moins de support à gérer.
# flatpak c'est nul?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+12/-4).
Flatpak ne devrait pas pousser son propre système de paquet et utiliser deb comme tout le monde.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: flatpak c'est nul?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 1 (+2/-3). Dernière modification le 15 février 2025 à 11:10.
Ça commence à bien faire la diffamation !
Plus sérieusement, j'ai l'impression qu'on arrive à la croisée des chemins. J'avais vu par le passé des devs se plaindre ça et là de la façon dont certaines distros empaquetaient leurs applis, mais à présent, les Linux atomiques (Bazzite en tête) me semblent bien parties pour devenir le paradigme dominant des Linux pour le bureau, et dans ce paradigme, les paquets, c'est Flathub, Homebrew, ou rien. Ou, dans le cas des Fedora, les Flatpaks de chez eux qui sont sélectionnés par défaut dans la boutique d'applis et qui cassent les pieds à tout le monde. KDE et GNOME ambitionnent de sortir chacun leur propre OS sans gestionnaire de paquets, juste le système de base, et Flatpak. Les utilisateurs feront-ils encore la différence ?
[^] # Re: flatpak c'est nul?
Posté par 桃白白 . Évalué à 8 (+7/-0).
Riche idée, laissons un seul service distribuer toutes les applications Linux. Ça marche tellement bien sous mobile.
Sur le site de Flathub:
䨻
[^] # Re: flatpak c'est nul?
Posté par Jean Gabes (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 18 février 2025 à 07:53.
Pour avoir été à la tête d'un éditeur de logiciel pour Linux dans le passé: oui, avoir un standard n'est pas, mais alors vraiment pas une mauvaise chose quand tu dois gérer plusieurs distributions.
Et avoir un standard ne t’empêche en rien de le distribuer autrement si tu as envie et que tu as la force de frappe derrière pour gérer les innombrables soucis que ça apporte.
Tant que tu as toujours le choix, en quoi tu leur interdirais d'avoir leur app store d'applis? Si tu n'es pas content, tu pourras monter le tiens et tenter d'attirer des utilisateurs mécontents du premier.
Mais j'ai comme dans l'idée que les utilisateurs ne suivront pas en masse, linuxiens ou pas.
[^] # Re: flatpak c'est nul?
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Ben c’est ce que fait Fedora et c’est d’autres personnes qui se plaignent qu’ils le font.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: flatpak c'est nul?
Posté par 桃白白 . Évalué à 2 (+1/-0).
Sans aucun doute. Mais ce n'était pas le propos de mon commentaire qui visait le service "Flathub".
Je le craint en effet.
䨻
[^] # Re: flatpak c'est nul?
Posté par David Demelier (site web personnel) . Évalué à 0 (+0/-2).
comme tout le monde… faire un .deb nécessite un doctorat. un trillion de commandes différente (dh, deb, dpkg) et un trillions de fichiers de syntaxe différente. pour l'utilisateur
apt,apt-*,aptitude. j'ai jamais compris l'engouement pour ce gestionnaire de paquet.même si je suis pas fan du RPM, c'est un .spec et on en parle plus.
vive apk.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: flatpak c'est nul?
Posté par ff9097 . Évalué à 2 (+0/-0). Dernière modification le 24 février 2025 à 11:32.
rpm ?
# Le problème
Posté par Psychofox (Mastodon) . Évalué à 7 (+5/-1). Dernière modification le 15 février 2025 à 16:40.
C'est que le flathub est un bordel sans nom mélangeant des paquets officiellement préparé par les développeurs des applis et des paquets fournis par des tiers.
[^] # Re: Le problème
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 15 février 2025 à 18:15.
Ce que tu décris c'est un problème réel mais différent de celui du lien. Ici, on parle de Flatpaks fournis par Fedora qui sont présélectionnés par défaut dans les applis d'installation de Fedora (Logiciels ou Discover) au détriment des Flatpaks de Flathub. Et en général, il s'avère que les Flatpaks de Fedora sont moins bons que ceux de Flathub, au point où les devs upstream se plaignent qu'on leur remonte des problèmes qu'ils n'ont pas causé et qu'ils ne peuvent pas résoudre.
Ceci dit, on pourrait imaginer qu'il se passe la même chose avec des Flatpaks non officiels sur Flathub qui seraient de mauvaise qualité. Mais il me semble que c'est moins pernicieux dans ce cas de figure — en tout cas, je n'irai pas jusqu'à dire que c'est "un bordel sans nom" (par exemple, les paquets non officiels sont bien signalés comme tel par une pastille jaune sur leur page Flathub).
[^] # Re: Le problème
Posté par Benoît Sibaud (site web personnel) . Évalué à 9 (+6/-0). Dernière modification le 15 février 2025 à 20:31.
On arrive sur des problématiques classiques de périmètres non ?
Si l'upstream a une "équipe expérimentée" elle voudra gérer son empaquetage et ne pas être gênée par la ou les distributions et des rapports de bug inutiles.
Si la distribution a une "équipe expérimentée" elle voudra gérer son empaquetage et ne pas être gênée par l'upstream et sa gestion des dépendances et ses ruptures d'API et de comportement pour cause de support long.
Si l'upstream n'a pas/plus trop d'"équipe expérimentée", les personnes utilisatrices veulent que la distribution gère, et que ça soit harmonieux, cohérent et pas trop gourmand.
Si les personnes utilisatrices sont expérimentées, elles veulent des paquets récents et donc plutôt de l'upstream (sans parler des paquets hors distrib et empaquetage upstream si c'est des dév qui voudront du cargo/pip/npm/docker/CPAN/…)
Si l'équipe upstream et/ou l'équipe distribution et/ou les personnes utilisatrices ont des opinions fortes ou un relationnel sous-optimal alors des désaccords et des tensions apparaissent.
Si l'équipe sécurité s'en mêle… bon ok on n'installe rien ça règle la question.
(c'est un peu comme le mythique périmètre de l'équipe DevSecOpsArchFinIT)
[^] # Re: Le problème
Posté par Psychofox (Mastodon) . Évalué à 4 (+2/-1).
Ce que tu ne comprends pas c'est que le repo fedora est une réponse directe à ce problème pour que ses utilisateurs de silverblue puissent avoir accès aux mėmes applis que sur Fedora standard sans l'innondation d'applis proprios et de paquets non sûrs.
Par contre je trouve la communication de l'équipe obs assez hypocrite. les flatpacks de fedora sont faits à partir des rpms et ils n'ont jamais râlés sur l'existence de obs studio dans les rpms ni dans les paquet des autres distribs. Du coup pour quoi faire des menaces pour une version identique, mais juste fournie via un repo flatpak au lieu de rpm?
[^] # Re: Le problème
Posté par Psychofox (Mastodon) . Évalué à 3 (+1/-1).
Ce que tu ne comprends pas c'est que le repo fedora est une réponse directe à ce problème pour que ses utilisateurs de silverblue puissent avoir accès aux mėmes applis que sur Fedora standard sans l'innondation d'applis proprios et de paquets non sûrs.
Si flathub splittait ses repo en free from upstream, free fron third parry, non-free from upstream, non-free from third party les distros comme Fedora n'auraient pas à gérer une duplication des applis libres dans leur propre repo et les utilisateurs pourraient facilement prioriser les applis libres ou pas libres de source upstream.
Par contre je trouve la communication de l'équipe obs assez hypocrite. les flatpacks de fedora sont faits à partir des rpms et ils n'ont jamais râlés sur l'existence de obs studio dans les rpms ni dans les paquet des autres distribs. Du coup pour quoi faire des menaces pour une version identique, mais juste fourni via un repo flatpak?
[^] # Re: Le problème
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 16 février 2025 à 20:48.
Mais c'est déjà le cas non ? Le site Flathub (sur sa page recherche, mais ça discute de généraliser le filtrage) et Logiciels de GNOME (là aussi ils en parlent) permettent tous deux de n'afficher que les applis libres et/ou vérifiées. Les utilisateurs peuvent prioriser avec ça.
Pour moi, la raison pour laquelle Fedora a son propre repo Flatpak, c'est avant tout parce qu'elle considère que c'est la raison d'être d'une distro que de proposer ses propres repos. Et tout le débat linké dans un des liens de l'article porte sur cette raison d'être, à l'heure où Flathub prend de l'importance, comme l'explique Benoît plus haut.
Est-elle identique ? De ce que j'en ai lu, les problèmes du Flatpak Fedora d'OBS viennent de la version du runtime dont il dépend et des permissions liées au sandboxing, qui sont deux aspects spécifiques à Flatpak qui ne concernent pas les RPM. Accessoirement, quand tu utilises un Linux atomique, l'idée c'est aussi de se passer au maximum des RPM.
[^] # Re: Le problème
Posté par Psychofox (Mastodon) . Évalué à 4 (+2/-1). Dernière modification le 18 février 2025 à 08:02.
permettent / peuvent. Là est la clé. Je te parles de dépôts séparés, tu me parles de clients. Tous les spins de Fedora n'utilisent pas Gnome Software.
Fedora ne veut proposer que du logiciel libre par défaut. L'utilisateur doit sciemment activer des repos s'il veut du non-libre. Là avec flathub qui propose tout en un repo, les utilisateurs peuvent installer du non-libre ou du malware par erreur en 1 click.
Le problème réel c'est que des utilisateurs se plaignent de leur problème sur les canaux d'aides et de communication d'OBS au lieu d'utiliser celui de Fedora quand ils rencontrent un problème. Si ce sont de simple problèmes de permissions ils peuvent être résolus facilement par Fedora s'ils ont un rapport de bug. Comment améliorer ça? Je ne sais pas. C'est naturel d'aller voir du côté de l'upstream mais c'est aussi à l'upstream de savoir dire: si t'as un problème avec le flatpak de Fedora que tu ne peux pas reproduire avec notre flatpak, gueule chez Fedora.
Mais on pourrait aussi critiquer le flatpak upstream de OBS. Si le principe des paquets maintenus par les distribution existe, c'est parce que les développeurs sont parfois incapable de faire les choses proprement et prennent les pires raccourcis dès qu'ils rencontrent un problème (les fameux chmod 777 partout par grosse flemme). Du coup ben si tu regardes le flatpak d'OBS tu vois qu'il donne permission à tous les filesystems (au lieu de choisir le homedir ou un sous-ensemble du homedir) sans exception. Je ne vois pas bien pourquoi, dans un système proposant un encapsulage des applications et de leurs permissions, on donnerait à un logiciel de streaming accès à tout ton filesystem. Alors le problème sous-jacent, c'est que flathub et l'encapsulage, ça reste un peu trop tout ou rien et la meilleure solution serait d'avoir un système comme android qui peut de manière interactive permettre à l'utilisateur de choisir à quel espace disque il donne l'accès à une application. Mais clairement, les devs d'OBS ont choisi la voie de la facilité et ont font les gros cochons avec leur flatpak pour avoir moins de support à gérer.
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.