Flatpak - pour quoi faire ?

J’ai beau être plutôt sceptique face à ces nouveaux formats qui ressemblent à un retour au binaire statique, j’ai du mal à comprendre les critiques au sujet de Ubuntu.

Se reposer sur une base système stable et robuste, gérée par apt, pour faire tourner des logiciels utilisateurs suivant les dernières mises-à-jour, ceux-ci gérés par snap, je trouve que c’est une manière très intelligente de construire une distribution. En particulier une distribution qui se veut grand public et généraliste, comme Ubuntu.

Je vais rester sur Debian et continuer à n’utiliser que apt, sans surprise, mais je vais suivre de près ce qui se passe chez Ubuntu parce que j’aime ce genre de prise de risque qui peut ensuite faire bouger les choses au niveau des autres distributions. J’espère franchement qu’ils vont continuer sur ce système « à deux vitesses » qui devrait apporter un compromis intéressant entre la robustesse de la base Debian et le suivi rapide des mises-à-jour upstream des logiciels de bureau.

2 J'aime

Ça me semble très douteux, et basé sur pas grand chose. Canonical a été particulièrement clair ces dernières années sur leur volonté de se financer par les offres côté serveur, or les snaps ne vont pas y être utilisés aussi largement que sur le bureau.

Et vu la part de marché de Ubuntu sur les machines de bureau, tablettes et autres mobiles, espérer financer quoi que ce soit en faisant payer la distribution d’applications dans ce contexte me semble impensable.

1 J'aime

C’est vrai que l’exemple de la téléphonie n’existe pas :slight_smile:

1 J'aime

Ces conversations face à la nouveauté me rappellent les discussions au sujet de systemd: bilan de systemd, hormis les réfractaires à tout qui représentent 0.01% de la pop le reste est très content avec

edit: en tout cas 2 choses - primo bravo aux concepteurs de leur site et deuzio flatpack existe depuis 2015…il serait temps de raler sur quelque chose qui je suppose a du faire ses preuves.

1 J'aime

C’est une chose de tenter de vendre un service de distribution d’applications pour téléphone mobile quand on a le marché captif d’un Apple ou d’un Google… Mais la clientèle potentielle de Canonical de ce côté me semble tellement ridiculement faible qu’ils n’ont juste aucune chance que ça fonctionne.

1 J'aime

En passant, Flatpak mis à jour ce matin , il y a ceux qui causent et ceux qui utilisent :joy: :rofl:

Les paquets suivants seront mis à jour :
  flatpak libjdom1-java libx11-6 libx11-6:i386 libx11-data libx11-xcb1
  libx11-xcb1:i386 openjdk-11-jre openjdk-11-jre-headless
9 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 41,1 Mo dans les archives.
Après cette opération, 328 ko d'espace disque supplémentaires seront utilisés.
Réception de :1 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 flatpak amd64 1.10.2-3 [1 281 kB]
Réception de :2 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 libjdom1-java all 1.1.3-2.1 [156 kB]
Réception de :3 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 libx11-data all 2:1.7.2-1 [311 kB]
Réception de :4 https://cdn-aws.deb.debian.org/debian bullseye/main i386 libx11-6 i386 2:1.7.2-1 [794 kB]
Réception de :5 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 libx11-6 amd64 2:1.7.2-1 [772 kB]
Réception de :6 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 libx11-xcb1 amd64 2:1.7.2-1 [203 kB]
Réception de :7 https://cdn-aws.deb.debian.org/debian bullseye/main i386 libx11-xcb1 i386 2:1.7.2-1 [203 kB]
Réception de :8 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 openjdk-11-jre amd64 11.0.12+7-2 [176 kB]
Réception de :9 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 openjdk-11-jre-headless amd64 11.0.12+7-2 [37,3 MB]

1 J'aime

Ah bah c’est clair que pour ma part je ne suis pas prêt de passer dans le groupe de ceux qui utilisent Flatpak :stuck_out_tongue:

Je n’utilise que deux méthodes pour installer un logiciel :

  • un paquet .deb, installé via apt (soit fourni par Debian, soit construit localement)
  • une compilation locale des sources
4 J'aime

Pour ma part ça me sert a des applications qui sont pas dans les dépôts ou en version plus évolué, comme : WARPINATOR, ONLYOFFICE,PCSX2, RETROARCH, FS-UAE Amiga Emulator par exemple. Ca me permet aussi d’avoir une version de KSNIP fonctionnel en flatpak alors que la version du dépôt Debian bug chez moi.

J’ai utilisé AppsImage dans un cadre professionnel pour faire tourner une version plus récente d’un logiciel (Xcas, Scilab par exemple mais aussi Hopper à titre personnel), ou une vieille version (Maple 14 pour un collègue) sur debian. Les binaires sont sur un système squashfs donc prennent en général moins de place. Le script de fabrication de l’appsimage est assez buggué et doit être modifié si on veut utiliser une libc ou même une version de Qt plus récente. Cela se fait assez bien. La fabrication de l’appsimage se fait à partir des paquets debian ou des paquets ubuntu, ou bien à partir de binaires perso. C’est à la fois assez astucieux et assez artisannal mais gloabalement ça fonctionne bien. J’avoue que à l’usage ça c’est avéré très pratique. Décortiquer une appsimage est très simple, il y a dedans un système squashfs qu’il suffit de déplier. Dedans se trouve tout ce qui a été installé et la plupart du temps l’origine. Je n’ai pas essayé Snap ni Flatpak, les services rendus par appsimage et la simplicité du procédé m’ont suffit.
PS: Xcas est en 1.4.9 sur debian et 1.6 en réalité, Scilab est buggué, Hopper ne tournait plus sur la stable, Maple nécessitait un environnement particulier, …

2 J'aime