…c’est une comparaison dos à dos entre un système qui utilise les paquets locaux vs. Un système à base de flatpack, dans une config standard - donc un navigateur web, libreoffice et 2/3 outils classiques type VLC, GIMP et Krita.
On fait « vivre » ça pendant 2 mois - aucune activité utilisateur, juste les mises à jour.
Et à échéance on regarde :
- l’espace disque utilisé
- où est-ce qu’il est consommé - si c’est dans le cache et nettoyable, ou ailleurs ?
- la vitesse du système et surtout de démarrage du PC et des applications principales
Et arrivé là je me rends bien compte que j’ai ni le temps ni l’énergie pour faire un truc pareil. Je vais donc rester sur mon hypothèse de base qui est que les paquets natifs, c’est mieux et que le reste ça craint.
Tout le monde est d'accord avec ça. Mais les paquets natifs ont un seul inconvénient : c'est une plaie à maintenir. D'où le snap/flatpak, surtout pour les applis qui bougent le plus (le browser est un excellent exemple).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
En contrepartie, les paquets natifs ont leurs dépendances à jour.
C'est bien pour ça que des alternatives comme systemd-run peuvent être pertinentes: namespace séparé, restrictions sur les accès disques et réseau, mais réutilisation des libs du système.
C'est dommage que ça ne soit pas plus répandu, comme option.
Dans certains cas, pas de sandbox c'est mieux !
Je maintiens une appli dont l'aide utilisateur est un fichier html statique local. Quand l'utilisateur appelle l'aide, l'appli envoie ce fichier à son navigateur. Ça a marché comme ça depuis le début des années 2000, et jusqu'à Firefox snap. Parce que le snap sandboxé n'a pas accès au fichier local. Résultat, dans un premier temps j'ai du renvoyer les utilisateurs vers l'aide en ligne.
Envoyer un utilisateur sur le web parce qu'il ne peut pas lire un html statique en local… si c'est pour améliorer la sécurité je pense que (dans ce cas précis) ça loupe bien l'objectif ! Sans parler des cas où l'utilisateur n'est pas connecté.
Et du coup j'ai dû me farcir d'inclure un navigateur (rudimentaire) dans mon appli. Lourd, lourd.
Tout le monde est d'accord avec ça. Mais les paquets natifs ont un seul inconvénient : c'est une plaie à maintenir. D'où le snap/flatpak, surtout pour les applis qui bougent le plus (le browser est un excellent exemple).
Je ne dirais pas qu'ils n'ont qu'un seul inconvénient, il y en a un peu plus que cela quand même.
Le fait d'isoler les processus c'est un plus niveau sécurité / confidentialité ce que peu de paquets natifs offrent car il n'y a pas de solutions génériques pour le mettre en place en standard proprement, ou encore la flexibilité pour installer le paquet de son choix. Un Flatpak peut être installé dans ton système peu importe ta distribution et tu peux installer la version du Flatpak de ton choix facilement. Sans Flatpak tu es tributaire de la présence du paquet dans la distro et dans la version qu'elle propose ce qui peut être un problème.
Ce sont vraiment deux visions différents du systèmes avec plusieurs avantages et inconvénients. Mais petit bonus, rien n'empêche de mixer les deux selon les besoins aussi.
Moi je crois qu'on voit le problème dans le mauvais sens. Le problème du sandboxing ne devrait pas être résolu avec flatpak ou snap mais directement avec l'intégration du système. On déplace le problème au mauvais endroit.
Je verrais bien par exemple qu'un binaire simple localisé directement dans l'arborescence, admettons /bin/ls une fois exécuté par le shell est placé dans un mécanisme d'isolement spécifique à Linux (avec vos technologies préférées).
La par contre je vois pas le cas d'usage. Tu as un exemple ? Il y a aucune application me concernant où j'ai besoin d'avoir deux versions, je serai ravi d'avoir un cas d'usage pertinent.
Moi je crois qu'on voit le problème dans le mauvais sens. Le problème du sandboxing ne devrait pas être résolu avec flatpak ou snap mais directement avec l'intégration du système. On déplace le problème au mauvais endroit.
Je verrais la chose autrement en fait.
Déjà, quoiqu'on en dise, vues les polémiques autour de systemd, PolicyKit, PAM, etc. je ne doute pas un seul instant que si une distro traditionnelle faisait du sandboxing au niveau système comme tu dis, ça râlerait quand même avec des arguments souvent assez mauvais.
Ensuite, il faut voir aussi que ce n'est pas une tâche triviale. Beaucoup d'applications ne sont pas conçues pour fonctionner dans ces conditions, pour d'autres il faut avoir la capacité d'avoir des autorisations à la volée et non permanentes, c'est difficile de dire "on fait un système complet sandboxer" plutôt que d'apporter une technologie indépendante qui évolue à son propre rythme, permet de pousser la réflexion et de faire l'implémentation.
On peut aussi se poser la question dans le cas d'un système dit immuable comme Fedora Silverblue où les paquets Flatpak sont la référence et non l'exception, en quoi ces applications ne font pas partis du système en fait ? On peut considérer que d'inclure Flatpak pour en gérer toutes les applications de l'ordinateur comme pas très différent que d'utiliser n'importe quel système de bac à sable "intégré au système" comme le fait par exemple un Android. Finalement ça revient au même et rien n'empêche de reprendre les APIs et concepts pour fournir une alternative au besoin.
Pourquoi les paquets natifs seraient ils plus pénibles à maintenir ?
Mon sentiment est que la partie difficile du packaging, c'est le système de build, c'est à dire partir des sources et des ressources et les mettre dans une arborescence qui sera ensuite intégrée dans le paquet, et ce que ce soit pour un paquet natif ou pour un snap ou un flatpak.
Ça c'est pour les logiciels qui fournissent leurs propres paquets.
Mais là on parle de logiciels inclus par la distrib: Firefox, GIMP, etc. Ces logiciels n'ont pas d'effort particulier à fournir de leur côté, c'est le mainteneur qui s'en occupe.
D'ailleurs, Mozilla ne fourni pas de snap pour Firefox: l'effort de packaging reste donc là. C'est sûr que c'est plus simple car on compile et exécute dans un environnement isolé, mais bon c'est quand même l'intérêt d'une distrib à la base d'avoir cette intégration…
Mais là on parle de logiciels inclus par la distrib: Firefox, GIMP, etc. Ces logiciels n'ont pas d'effort particulier à fournir de leur côté, c'est le mainteneur qui s'en occupe.
Et chaque distribution doit avoir son propre mainteneur, ça duplique l'effort.
D'ailleurs, Mozilla ne fourni pas de snap pour Firefox: l'effort de packaging reste donc là. C'est sûr que c'est plus simple car on compile et exécute dans un environnement isolé, mais bon c'est quand même l'intérêt d'une distrib à la base d'avoir cette intégration…
Il y a des difficultés propres à chaque distribution dont il faut tenir compte. Cela peut être l'arborescence des systèmes de fichiers systèmes qui varient même si c'est moins le cas aujourd'hui, ou le fait que certaines bibliothèques ou utilitaires sont présents dans une version commune à tout le monde sauf que le logiciel n'a pas tenu compte de cette contrainte : tel paquet ne compile pas avec la dernière version de GCC, utiliser une version plus récente ou ancienne d'une bibliothèque introduit des bogues, ou la distribution active des options de compilations pour tout le système pour des raisons de performances ou de sécurité et cela ne fonctionne pas bien avec certains paquets, etc.
Toutes ces difficultés sont propres à chaque distributions et n'existent que parce que les distributions mutualisent un maximum de choses. Cela a des aspects bénéfiques bien connus mais l'effort en maintenance est réelle et n'a rien à voir avec l'effort de faire un Flatpak unique correspondant pour un logiciel donné.
Et maintenant avec les paquets non natifs, il en faut un pour flatpak, un pour snap, un pour appimage, un pour pkgsrc, un pour nix… Et chaque système a ses us et coutumes, mais c'est pas pareil !
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
Pour être mainteneur de Alpine je dirais que c'est pas aussi simple de répondre par oui ou par non.
Déjà faut prendre en compte l'environnement, on prend un paquet le plus simple possible qui consiste à faire juste un cp d'un .sh vers /bin/superscript. Avec un APKBUILD ou un PKGBUILD c'est vraiment peanuts sur ces distributions. Alors déjà là je dirais qu'on a une plaie en moins. Quand on fait un .deb ou un .ebuild, je peux comprendre déjà l'aversion à être mainteneur tant cela est compliqué. Surtout quand tu rajoutes le parcours du combattant pour soumettre une simple update à la distribution, chez debian c'est une compétition de complexité (bon, fedora et redhat je dirais que c'est pareil).
Ensuite, il y a le paquet en lui même. Maintenir un firefox ou rust c'est effectivement la plaie. Et souvent ce sont les mêmes mainteneurs qui restent du début jusqu'à la fin tellement c'est parfois difficile. Mais de ce côté là, je vois pas ce que flatpak ni snap viennent apporter une plus-value. Parce que non seulement c'est plus le mainteneur de la distribution qui doit s'en occuper mais carrément le développeur de l'application originale. Et ce développeur il en a « à mon sens » rien à faire de comment sont architecturée les distributions et leur spécifités unique (musl, lib ou lib64, systemd ou pas). Alors je crois que ça reste toujours la meilleure option que ce soit un mainteneur qui s'occupe de l'intégration totale d'un paquet pour qu'il prenne en compte toute la partie technique de la distribution plutôt que d'avoir des flatpak complètement éclatés d'incohérence.
Bien sûr j'exagère un peu mais quand je vois les outils proprio comment ils sont fourni sous Linux, je suis content d'utiliser que du libre.
# Ce qui serait vraiment intéressant…
Posté par Dring . Évalué à 6 (+4/-0).
…c’est une comparaison dos à dos entre un système qui utilise les paquets locaux vs. Un système à base de flatpack, dans une config standard - donc un navigateur web, libreoffice et 2/3 outils classiques type VLC, GIMP et Krita.
On fait « vivre » ça pendant 2 mois - aucune activité utilisateur, juste les mises à jour.
Et à échéance on regarde :
- l’espace disque utilisé
- où est-ce qu’il est consommé - si c’est dans le cache et nettoyable, ou ailleurs ?
- la vitesse du système et surtout de démarrage du PC et des applications principales
Et arrivé là je me rends bien compte que j’ai ni le temps ni l’énergie pour faire un truc pareil. Je vais donc rester sur mon hypothèse de base qui est que les paquets natifs, c’est mieux et que le reste ça craint.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Tout le monde est d'accord avec ça. Mais les paquets natifs ont un seul inconvénient : c'est une plaie à maintenir. D'où le snap/flatpak, surtout pour les applis qui bougent le plus (le browser est un excellent exemple).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par ff9097 . Évalué à 6 (+6/-2).
Les paquets natifs n'ont pas de sandbox
[^] # Re: Ce qui serait vraiment intéressant…
Posté par Christophe . Évalué à 8 (+6/-0).
En contrepartie, les paquets natifs ont leurs dépendances à jour.
C'est bien pour ça que des alternatives comme systemd-run peuvent être pertinentes: namespace séparé, restrictions sur les accès disques et réseau, mais réutilisation des libs du système.
C'est dommage que ça ne soit pas plus répandu, comme option.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par ff9097 . Évalué à 4 (+2/-0).
Vu que tu n'as pas de sandbox, c'est indispensable d'avoir tes dépendances à jour.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par guiv42 . Évalué à 10 (+12/-0).
Dans certains cas, pas de sandbox c'est mieux !
Je maintiens une appli dont l'aide utilisateur est un fichier html statique local. Quand l'utilisateur appelle l'aide, l'appli envoie ce fichier à son navigateur. Ça a marché comme ça depuis le début des années 2000, et jusqu'à Firefox snap. Parce que le snap sandboxé n'a pas accès au fichier local. Résultat, dans un premier temps j'ai du renvoyer les utilisateurs vers l'aide en ligne.
Envoyer un utilisateur sur le web parce qu'il ne peut pas lire un html statique en local… si c'est pour améliorer la sécurité je pense que (dans ce cas précis) ça loupe bien l'objectif ! Sans parler des cas où l'utilisateur n'est pas connecté.
Et du coup j'ai dû me farcir d'inclure un navigateur (rudimentaire) dans mon appli. Lourd, lourd.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par ff9097 . Évalué à 5 (+4/-1). Dernière modification le 28 septembre 2026 à 10:50.
snap c'est assez moisi
[^] # Re: Ce qui serait vraiment intéressant…
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
ou dans le cas qui te concerne, l'accès à
/usr/share/doc/ce serait déjà pas mal ;-)[^] # Re: Ce qui serait vraiment intéressant…
Posté par Renault (site web personnel) . Évalué à 6 (+3/-0).
Je ne dirais pas qu'ils n'ont qu'un seul inconvénient, il y en a un peu plus que cela quand même.
Le fait d'isoler les processus c'est un plus niveau sécurité / confidentialité ce que peu de paquets natifs offrent car il n'y a pas de solutions génériques pour le mettre en place en standard proprement, ou encore la flexibilité pour installer le paquet de son choix. Un Flatpak peut être installé dans ton système peu importe ta distribution et tu peux installer la version du Flatpak de ton choix facilement. Sans Flatpak tu es tributaire de la présence du paquet dans la distro et dans la version qu'elle propose ce qui peut être un problème.
Ce sont vraiment deux visions différents du systèmes avec plusieurs avantages et inconvénients. Mais petit bonus, rien n'empêche de mixer les deux selon les besoins aussi.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par David Demelier (site web personnel) . Évalué à 5 (+3/-0).
Moi je crois qu'on voit le problème dans le mauvais sens. Le problème du sandboxing ne devrait pas être résolu avec flatpak ou snap mais directement avec l'intégration du système. On déplace le problème au mauvais endroit.
Je verrais bien par exemple qu'un binaire simple localisé directement dans l'arborescence, admettons
/bin/lsune fois exécuté par le shell est placé dans un mécanisme d'isolement spécifique à Linux (avec vos technologies préférées).AI is a mental disorder
[^] # Re: Ce qui serait vraiment intéressant…
Posté par ff9097 . Évalué à 1 (+0/-1).
Ça ne résout pas l'autre avantage de flatpak qui est l'installation multiples en parallèle
[^] # Re: Ce qui serait vraiment intéressant…
Posté par David Demelier (site web personnel) . Évalué à 2 (+0/-0).
La par contre je vois pas le cas d'usage. Tu as un exemple ? Il y a aucune application me concernant où j'ai besoin d'avoir deux versions, je serai ravi d'avoir un cas d'usage pertinent.
Pour les bibliothèques, je suis d'accord.
AI is a mental disorder
[^] # Re: Ce qui serait vraiment intéressant…
Posté par ff9097 . Évalué à 2 (+0/-0).
Tester une version de développement par exemple
[^] # Re: Ce qui serait vraiment intéressant…
Posté par Renault (site web personnel) . Évalué à 3 (+0/-0).
Je verrais la chose autrement en fait.
Déjà, quoiqu'on en dise, vues les polémiques autour de systemd, PolicyKit, PAM, etc. je ne doute pas un seul instant que si une distro traditionnelle faisait du sandboxing au niveau système comme tu dis, ça râlerait quand même avec des arguments souvent assez mauvais.
Ensuite, il faut voir aussi que ce n'est pas une tâche triviale. Beaucoup d'applications ne sont pas conçues pour fonctionner dans ces conditions, pour d'autres il faut avoir la capacité d'avoir des autorisations à la volée et non permanentes, c'est difficile de dire "on fait un système complet sandboxer" plutôt que d'apporter une technologie indépendante qui évolue à son propre rythme, permet de pousser la réflexion et de faire l'implémentation.
On peut aussi se poser la question dans le cas d'un système dit immuable comme Fedora Silverblue où les paquets Flatpak sont la référence et non l'exception, en quoi ces applications ne font pas partis du système en fait ? On peut considérer que d'inclure Flatpak pour en gérer toutes les applications de l'ordinateur comme pas très différent que d'utiliser n'importe quel système de bac à sable "intégré au système" comme le fait par exemple un Android. Finalement ça revient au même et rien n'empêche de reprendre les APIs et concepts pour fournir une alternative au besoin.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par Barnabé . Évalué à 3 (+2/-0).
Pourquoi les paquets natifs seraient ils plus pénibles à maintenir ?
Mon sentiment est que la partie difficile du packaging, c'est le système de build, c'est à dire partir des sources et des ressources et les mettre dans une arborescence qui sera ensuite intégrée dans le paquet, et ce que ce soit pour un paquet natif ou pour un snap ou un flatpak.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par gUI (Mastodon) . Évalué à 8 (+7/-2).
Parce qu'il en faut un pour Debian, un pour Fedora, un pour Arch… Chaque distrib a ses us et coutumes etc.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par Christophe . Évalué à 5 (+3/-0).
Ça c'est pour les logiciels qui fournissent leurs propres paquets.
Mais là on parle de logiciels inclus par la distrib: Firefox, GIMP, etc. Ces logiciels n'ont pas d'effort particulier à fournir de leur côté, c'est le mainteneur qui s'en occupe.
D'ailleurs, Mozilla ne fourni pas de snap pour Firefox: l'effort de packaging reste donc là. C'est sûr que c'est plus simple car on compile et exécute dans un environnement isolé, mais bon c'est quand même l'intérêt d'une distrib à la base d'avoir cette intégration…
[^] # Re: Ce qui serait vraiment intéressant…
Posté par Renault (site web personnel) . Évalué à 5 (+3/-1).
Et chaque distribution doit avoir son propre mainteneur, ça duplique l'effort.
Il y a des difficultés propres à chaque distribution dont il faut tenir compte. Cela peut être l'arborescence des systèmes de fichiers systèmes qui varient même si c'est moins le cas aujourd'hui, ou le fait que certaines bibliothèques ou utilitaires sont présents dans une version commune à tout le monde sauf que le logiciel n'a pas tenu compte de cette contrainte : tel paquet ne compile pas avec la dernière version de GCC, utiliser une version plus récente ou ancienne d'une bibliothèque introduit des bogues, ou la distribution active des options de compilations pour tout le système pour des raisons de performances ou de sécurité et cela ne fonctionne pas bien avec certains paquets, etc.
Toutes ces difficultés sont propres à chaque distributions et n'existent que parce que les distributions mutualisent un maximum de choses. Cela a des aspects bénéfiques bien connus mais l'effort en maintenance est réelle et n'a rien à voir avec l'effort de faire un Flatpak unique correspondant pour un logiciel donné.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+18/-0).
Et maintenant avec les paquets non natifs, il en faut un pour flatpak, un pour snap, un pour appimage, un pour pkgsrc, un pour nix… Et chaque système a ses us et coutumes, mais c'est pas pareil !
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Ce qui serait vraiment intéressant…
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0).
c'pas faux ^^
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ce qui serait vraiment intéressant…
Posté par David Demelier (site web personnel) . Évalué à 10 (+8/-0).
Pour être mainteneur de Alpine je dirais que c'est pas aussi simple de répondre par oui ou par non.
Déjà faut prendre en compte l'environnement, on prend un paquet le plus simple possible qui consiste à faire juste un cp d'un .sh vers /bin/superscript. Avec un APKBUILD ou un PKGBUILD c'est vraiment peanuts sur ces distributions. Alors déjà là je dirais qu'on a une plaie en moins. Quand on fait un .deb ou un .ebuild, je peux comprendre déjà l'aversion à être mainteneur tant cela est compliqué. Surtout quand tu rajoutes le parcours du combattant pour soumettre une simple update à la distribution, chez debian c'est une compétition de complexité (bon, fedora et redhat je dirais que c'est pareil).
Ensuite, il y a le paquet en lui même. Maintenir un firefox ou rust c'est effectivement la plaie. Et souvent ce sont les mêmes mainteneurs qui restent du début jusqu'à la fin tellement c'est parfois difficile. Mais de ce côté là, je vois pas ce que flatpak ni snap viennent apporter une plus-value. Parce que non seulement c'est plus le mainteneur de la distribution qui doit s'en occuper mais carrément le développeur de l'application originale. Et ce développeur il en a « à mon sens » rien à faire de comment sont architecturée les distributions et leur spécifités unique (musl, lib ou lib64, systemd ou pas). Alors je crois que ça reste toujours la meilleure option que ce soit un mainteneur qui s'occupe de l'intégration totale d'un paquet pour qu'il prenne en compte toute la partie technique de la distribution plutôt que d'avoir des flatpak complètement éclatés d'incohérence.
Bien sûr j'exagère un peu mais quand je vois les outils proprio comment ils sont fourni sous Linux, je suis content d'utiliser que du libre.
AI is a mental disorder
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.