Flatpak sous Debian vos avis?

Critère :package: Paquet Debian (.deb) :orange_circle: Snap :green_circle: Flatpak :large_blue_circle: AppImage
Principe Paquet natif de la distribution Application empaquetée avec ses dépendances Application isolée avec ses dépendances/runtime Application autonome dans un seul fichier
Installation apt install / gestionnaire de paquets snap install flatpak install Télécharger → rendre exécutable → lancer
Désinstallation Très propre via apt remove Facile via snap remove Facile via flatpak uninstall Supprimer le fichier
Mises à jour Via apt upgrade Automatiques par défaut Gérées par Flatpak Généralement manuelles
Dépendances Partagées avec le système Embarquées en grande partie Runtime partagé Généralement embarquées
Taille disque :star::star::star::star::star: Très efficace :star::star: Plus élevée :star::star::star: Moyenne :star::star: Souvent élevée
Temps d’installation :star::star::star::star::star: Rapide :star::star::star: :star::star::star: :star::star::star::star::star:
Démarrage :star::star::star::star::star: Excellent :star::star::star: Peut être plus lent :star::star::star::star: Généralement bon :star::star::star::star: Généralement bon
Isolation / sandbox :x: Faible par défaut :white_check_mark: Forte :white_check_mark: Très forte :x: Faible par défaut
Sécurité :star::star::star: Dépend du paquet et du système :star::star::star::star: :star::star::star::star::star: :star::star:
Portabilité :x: Faible :star::star::star: :star::star::star::star: :star::star::star::star::star:
Version récente des logiciels :star::star: Dépend de la distribution :star::star::star::star::star: :star::star::star::star::star: :star::star::star::star::star:
Intégration au système :star::star::star::star::star: Excellente :star::star::star::star: :star::star::star::star: :star::star::star:
Accès aux périphériques :star::star::star::star::star: Simple :star::star::star: Peut nécessiter des permissions :star::star::star: Peut nécessiter des permissions :star::star::star::star:
Gestion centralisée :white_check_mark: Excellente :white_check_mark: Excellente :white_check_mark: Excellente :x: Faible
Besoin d’un dépôt Oui Oui Oui, généralement Flathub Non
Fonctionne sur plusieurs distributions :x: Principalement Debian/Ubuntu et dérivées :white_check_mark: Oui :white_check_mark: Oui :white_check_mark: Oui
Mise à jour automatique :x: Via gestionnaire système :white_check_mark: Oui :white_check_mark: Possible :x: Généralement non
Rollback :star::star: Limité :star::star::star::star::star: Excellent :star::star::star::star: :x:
Pertinent pour serveur :star::star::star::star::star: :star::star: :star: :star:
Pertinent pour desktop :star::star::star::star::star: :star::star::star: :star::star::star::star::star: :star::star::star::star:

Allez petit résumé généré par un chat à la con (je taff sur du llm en ce moment ça me défoule donc de digresser avec le bouzin).

Pour ce qui est de l’intérêt des un et des autres j’avouer avoir mon cœur qui balance vers snap pour l’intégration poussé et la facilité le maintient à jour (et franchement le côté canonical nananana m’en contre fou du moment que ça marche sur ma machine de travail).
Maintenant de toute les solutions les flatpak sont sans doute les moins liés à une entreprise et proposant une gestion facile du maintient à jour.

4 J'aime

Joli tableau. mais je ne suis pas d’accord pour la sécurité, en particulier pour les snap et appimage.
Quand à une mise à jour par défaut pour les snap, en terme de sécurité c’est une mauvaise pratique.

1 J'aime

Si tu installes un snap tu sais déjà à quoi tu te confronte si la source est pourri ? idem avec un flatpak ou une app image, sans vouloir t’offenser tu est peut-être trop rigide sans expliquer pourquoi :wink:

Donc pour faire plaisir à Zargos une appimage, un flatpak ou un snap est fourni habituellement par une source, s’assurer que la source est sûr est parfois compliqué (sachant que flathub ne garantit absolument rien) et comment dire les gens pensent se qu’ils veulent de Canonical pour la sureté du dépôt et des paquets.

Donc oui le sandboxing n’est pas parfait et impossible à contourner mais cela reste hors de portée pour beaucoup de problème de sécurité si la machine est saine et à jour.

en fait je refuse les trois notamment parce que coté sécurité ce n’est pas fiable :slight_smile:

Que ce soit par le fait que containérisé, il y a possibilité de contourner des mesures existantes de sécurité de l’hôte, qu’une mise à jour automatique ne laisse pas le temps de valider hors production et comme tu le dis très bien, les sources snap, appimage ont une sûreté difficile à assurer/valider.
Pour Canonical, je n’utilise pas Ubuntu entre autre pour le merdier que ça implique chez eux. :slight_smile:

c’est une fausse idée :slight_smile:

1 J'aime

Les AppsImage sont facile à faire. Je l’avais fait. En gros on indique la distribution et version voulue (les dépots en clair), on fournit un script de lacement éventuel, un .desktop, une icone et roule! (Mais ça fait 2-3 ans que je n’en ai plus fait, ça a peut être changé).
C’est idéal pour des conflits de version.

Si c’est avéré, c’est grave en effet. Qui est le fautif pour ceci ? Le noyau ? La distro hôte?

le contrainer et donc le package

je l’utilise et voici les raisons pour lesquelles j’apprécie flatpak:

-isolation sandbox

application

runtime Flatpak

ses bibliothèques compatibles

sandbox

Debian

explication: certaine applications récentes fonctionnent mal sur debian stable et un des gros avantages de Flatpak :
l’application apporte avec elle un environnement logiciel cohérent, sans pour autant embarquer nécessairement toutes les bibliothèques à l’intérieur de chaque application.

Je garde donc mon Debian propre, et mes applications graphiques ont leur propre environnement.
runtime partagé + sandbox, c’est probablement l’un des aspects les plus intéressants de Flatpak.

Un exemple pour fabriquer une appsimage. Ici c’est autopsy de ubuntu jammy. Vous récupérez pkg2appimage par exemple sur [https://github.com/AppImage/pkg2appimage/releases](https://ce lien)
Puis il faut faire un fichier autopsy .yml

app: autopsy
  union: true
#  binpatch: true

ingredients:
  packages: autopsy
  dist: jammy
  sources:
    - deb http://ftp.archive.ubuntu.com/ubuntu jammy main universe
  debs:
    - /home/francois/AppsImage/autopsy/*.deb
  script:
    - mkdir -p autopsy.AppDir
    - cp ../autopsy*.png autopsy.AppDir
    - mkdir -p autopsy.AppDir/usr/bin
    - cp ../autopsy.desktop autopsy.AppDir/
    - mkdir -p autopsy.AppDir/usr/share/pixmaps
    - cp ../autopsy.png  autopsy.AppDir/usr/share/pixmaps
    - pwd
    - find . -type f

post_script:
    - cp ../../autopsy.desktop .
    - add-apt-repository ppa:gift/stable
    - apt update
    - apt install -y libbfio1
    - mkdir usr/share/pixmaps
    - cp ../../autopsy.png  usr/share/pixmaps
    - (cd usr/bin ; ln -sf ../../bin/bash   ; ln -sf ../../lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ;cd ../..)

On fait ensuite

pkg2appimage  autopsy.yml

La syntaxe du fichier est assez claire, on fait les ajustements au fur et à mesure des erreurs du script. Le fichier AppsImage est dans out/

  1. On sort de windows avec un site à vérifier par programme pour faire une debian avec un site à vérifier par programme et le proprio peut changer avec le temps !?!
  2. la sortie du bac de sable de l’ai de chatgpt montre qu’un bac à sable ce n’est pas une prison
  3. la multiplicité des versions installables du même programme est incompréhensible pour les gens normaux que l’on veut amener sur debian ( voir mint )
  4. l’absence des sources me semble se généraliser sur snap et flatpak et appimages

Je reste sur une version Debian et dans la mesure du possible pour des versions plus recentes, je vais privilégier une appImage. Ca marche ou pas, mais je sais que ca va pas aller polluer la configuration.

Ben en fait non, ca pollue en fait. Mieux vaut encore un flatpak qu’un appimage.
Toute configuration de sécurité se verra contourné avec un appimage où il n’y a pas de contrôle qualité; flatpak, même si ce n’est pas la panacée, il y a un minimum de contrôle il me semble.

Il y a une bonne raison si les entreprise et administration n’utilisent pas appimage ou snap. Aucune boite iso27001 ne vas utiliser ces trucs.

J’utilise principalement les .deb
normalement plus facile à gérer. je ne connais pas trop les commandes flatpak.

.deb c’est généralement apt search / show / install / purge

je l’utilise parfois pour les logiciels qui manque dans les .deb.
si je tappe dans mon terminal « flatpak search screenshot »
la commande flatpak reste en suspend. je passe donc par le navigateur pour trouver des infos sur des logiciels qui pourraient m’intéresser
si je fais apt search screenshot, je vais trouver une panoplie d’info
j’ai aucun doute que flatpak est bien, je suis juste moins habitué. j’aime aussi que les .deb soit un minimum approuvé par debian.

je préfères généralement flatpak aux appimages. un logiciel, un fichier, ça me rend un peu craintif. j’ai toujours l’impression qu’il va avoir un bug. mais c’est basé sur rien, juste une impression.

quand mon vieille ordinateur fonctionnait je m’amusais avec sway.
je cherchais un logiciel pour faire des captures d’écran assez sophistiqué. J’ai essayé flameshot.
J’ai essayé le .deb, le flatpak, et le appimage. J’ai beaucoup essayé, mais j’ai seulement réussi sur appimage.

Meme sur les sites officiels du logiciel ?

Pas si tu fabriques l’AppsImage, là tu controles tout, non?

je ne parle pas de ce contrôle là, un incompétent en sécu peut faire un appimage qu’il contrôle mais sur lequel il n’y a pas de contrôle qualité

Hello,

Pas mieux.
Il faut être root pour installer ces trucs ?
( je ne vois pas l’intérêt d’avoir 2 ( ou plus ) systèmes de paquets sur Debian

1 J'aime

Quand les dit paquet n’existe pas dans un dépôt, c’est bien pratique :wink:

1 J'aime

OK, c est vrai.
ça n 'est pas encore arrivé, de ne pas trouver ce que je voulais dans les dépots.

Pas plus tard qu’hier JAMI :