URL: https://linuxfr.org/users/emeric_/journaux/mais-pourquoi-flatpak Title: Mais pourquoi flatpak ? Authors: FluffyHamster Date: 2019年07月12日T19:29:51+02:00 License: CC By-SA Tags: flatpak, appimage et linux_mint Score: 63 Commençons par le problème : on veut des applications. Quand bien même une application existe, avec son joli dépôt git hub/lab ou son site Internet, il nous faut encore un moyen de l'installer sur notre machine. Plusieurs possibilités s’offrent à nous maintenant, mais regardons d’abord comment la concurrence résout ce problème. # La concurrence # ## Android ## 1. On va sur le store. On clique. C'est installé. 2. On peut diffuser des apk par nos propres moyens. On les signent avec une clé ce qui empêchera un autre paquet d'usurper le nôtre par la suite. Oui mais voilà, c’est maintenant [caché derrière une option](https://www.androidauthority.com/how-to-install-apks-31494/) désactivée par défaut. L’avenir nous dira comment cette situation va évolué... **Techniquement :** - Les applis sont indépendantes les unes des autres, et en grande partie du système. Chaque appli embarque les dépendances dont elle a besoin. - Les updates passent par un store. - Tout est [sandboxé](https://developer.android.com/training/articles/security-tips) par défaut. C’est solide... Autant que les autres systèmes de sandbox quoi... - Chaque appli dispose d’un espace de stockage isolé pour stocker ses propres fichiers. Ensuite, si l’application veut des permissions (accéder à la caméra, à la carte mémoire...) elle doit demander explicitement la permission à l’utilisateur (avant, il suffisait de lister les permissions dans un manifeste et elles étaient inconditionnellement accepté). - La rétro compatibilité est facile à gérer. On link avec un SDK Android "minimum" (encore aujourd'hui on peut choisir la 4.3 qui est vraiment vieille) et un SDK "visé" (en général on met le dernier, ça évite des problèmes). - A noter que maintenant, Android privilégie les ["app bundle"](https://developer.android.com/platform/technology/app-bundle) au lieu des "apk". C'est à peu près la même chose, mais par exemple on a un seul paquet pour toutes les architectures visées. C'est très bien pour les applis java (on économise de la place), ça oblige à faire des paquets X fois plus gros (car on multiplie tout sauf les ressources) si on fait une appli C++ (jeux vidéos, Qt, tout ça...) ## macOS ## 1. Pareil... store, clique, installé. 2. On peut diffuser des app par nos propres moyens. Mais si on veut qu’elles s’installent, ils faut qu’elles soient signées avec une clé... à [100€ par an](https://developer.apple.com/). Sinon, un peu comme le play store, il y a une option ([bien mieux cachée](https://www.macg.co/os-x/2016/10/macos-sierra-contourner-gatekeeper-pour-lancer-un-logiciel-non-signe-95905)) pour permettre l'exécution de chaque application non signée. 3. Ceci étant dit, on reste sur un système unix assez classique, il y a des binaires (ni signés ni sandboxés) plein le /usr/bin et on peut [y mettre les nôtres](https://brew.sh/index_fr) **Techniquement :** - Les applis embarquent également toute leurs dépendances et empaquettent tout ça dans un très joli format exécutable. On drag and drop dans le bon dossier, on double clique, et quand on en veut plus on déplace le fichier dans la corbeille. Dur de faire plus facile vraiment... - On peut [sandboxer](https://developer.apple.com/app-sandboxing/) les applications. Celles distribuées sur l’app store le sont. - Les .app peuvent se mettre à jour toute seule (avec ou sans le store). - La rétro compatibilité est la encore facile. Comme sur Android, on spécifie une version minimum et visé du SDK mac. En général, on prend dernière version, moins 2 ou 3. Si vous voulez supporter un mac OS vieux de 5 ans, c’est possible. Mais les mises à jour de macOS sont gratuites et efficaces donc ce n’est pas vraiment un problème de viser assez haut. ## Windows ## 1. On compile, on réunit les dépendances dans un dossier, on zip ou créer un installeur avec tout ça. On n’oublie pas de livrer et/ou installer les redists de Visual Studio, sinon... ça marchera moins bien. **Techniquement :** - Les vieilles applis restent compatibles avec les derniers Windows, c’est la grande force de la plateforme. - Les nouvelles applis visent de moins en moins autres choses que Windows 10 (nouvelles APIs et limitations des anciennes suivant ce que vous faites), même si il vous est possible de garder la compatibilité Windows XP si ça vous branche. - Une appli peut avertir l’utilisateur d’une mise à jour, télécharger et démarrer un installeur, c’est entièrement manuel donc on fait bien ce qu’on veut après tout. - Pas de sandboxing ni rien. ## iOS et le store Windows ## Je connais pas assez. # Et chez nous alors ? # ## Linux ## On se vante souvent de la supériorité technique de nos distributions et de leurs gestionnaires de paquets. Après tout ils nous permettent d’installer des logiciels très facilement, gèrent leurs mises à jour, dépendances (et leurs mises à jour). Ils assurent la cohérence et la sécurité des systèmes. Oui mais voilà. Quand un logiciel n’est pas dans un dépôt (ou que le dépôt contient une vieille version), et bien... c’est fini. Toi lecteur (et toi seulement) tu sortira peut être ton compilateur et ton couteau. Mais les autres, ils vont partir sur Internet à la recherche d’un fichier à double cliquer. Seulement, ça ne marche pas comme ça. Les logiciels de nos gestionnaires de paquets sont fortement couplés entre eux. Très fortement même. Si une nouvelle version d’un logiciel demande une nouvelle version d’une dépendance, en règle général, la distribution va attendre 6 mois et sa prochaine version avant de faire les mises à jour, plutôt que de risquer de casser quelque chose. Ce couplage est rarement un problème car vu que l’écosystème entier est libre, et qu’on a les sources de tous les participants, et on peut compiler et recompiler à la volé pour parer aux problèmes d’ABI et patcher les problèmes d’API. Certaines distributions comme Gentoo ou Arch font d’ailleurs tout ça en live. On n’a qu’une seule version de chacun des logiciels, et c’est la dernière. Pas de problème. Point barre. Il y a ceux qui pensent que ça ne marche pas, que ce n’est pas stable, que c’est plus de boulot qu’une réinstallation tout les 6 mois. Et il y a ceux qui utilisent ces distributions (on est vendredi ou pas ?). ## Le problème ## **Le problème, c’est que c’est chaque distribution pour soit alors ?** C’est pas faux. Pour diffuser un logiciel, chaque distribution doit l'empaqueter sinon ca coince (et tant qu’a faire, à la bonne version...). Et un développeur qui développe un petit logiciel n’aura pas le support des distributions et devra le faire lui même. C’est du boulot. **Donc le problème, c’est que sur linux, on ne peut pas compiler un logiciel, le packager, et le diffuser pour tout le monde alors ?** Mais justement. On peut. On prends une vieille distrib (lire, avec une vieille libc pour rester rétrocompatible) on compile ses dépendances, on met tout ça dans un zip, et c’est partit. Si on veut distribuer un logiciel propriétaire d’ailleurs, et bien on peut faire comme ca. Un zip avec tout dedans. Et on clique sur le lancermonlogiciel.sh Par ce qu’a vrai dire, on fait comme ça sur Windows. On met tout dans le même répertoire et on fais un raccourci. On peut même mettre tout ça dans un installeur. Loki en avait un à l’époque (pour les portages de jeux proprios) Qt en à un maintenant (avec mise à jour et désinstallation intégré). **Alors le problème, c’est que c’est pas franchement efficace ?** Pas super efficace non, on ne réutilise rien de la distrib hôte. C’est aussi pour ça qu’on est compatible avec tout le monde. Par contre, bien souvent, vous trouverez la dernière version de Qt (ou autre) dans votre logiciel proprio, bien plus récente que celle de votre distrib. Le monde à l’envers ? Ho que oui. **Alors le problème, c’est que c’est pas franchement pratique ?** Quelques personnes se sont dis ça aussi, et ils ont créé le format AppImage. il y a loooongtemps. En 2004. On encapsule tout ce dont l’appli a besoin (binaire, dépendances, ressources) dans un seul fichier exécutable. C’est excessivement facile d’usage. On peut en générer avec une seule commande. Pas besoin du logiciel AppImage pour lancer un AppImage, ce sont des binaires comme les autres ! On le télécharge (ou le distribus) à partir de la ou on veut, on l'exécute de la ou on veut. Il encapsule les metadatas comme la description, screenshots, icône, formats de fichiers gérés, et s’intègre donc tout seul dans le système (lire, le fichier desktop intégré se retrouve pris en compte par votre système). Certains se mettent à jours tout seul aussi. Ça vous fait penser aux applications macOS ? C’est normal. C’est beau. Ça fait bizarre la première fois, car on ne s’y attend pas. A ce que ça marche... Linus a testé pour son logiciel subsurface et en a chanté les louanges il y a bien longtemps. Mais qu’est ce qu’il y connait Linus à Linux ? **Mais alors, vraiment, c’est quoi le problème ?** Je sais plus. **C’est pas sécurisé.** HO MON DIEU. Pas plus que le reste. Alors arrêtons tout ?! Le problème, il reste donc vague. On sait que distribuer des paquets sous forme "tout compris" ça va de pas si compliqué à franchement facile. C’est comme ça que font les autres (ceux qui ont des parts de marché...) mais nous, on sait qu’on en veut pas. On sait que la plus grande force des gestionnaires de paquets (couplage logiciels/libs et mises à jours centralisées) fait finalement leur plus grande faiblesse. Et qu’il y en a beaucoup, ce qui complexifie encore la situation. Est ce qu’on veut que nos app soit facilement à distribuables et installables ? Est ce qu’on veut que nos app restent compatibles entre toute les distribs (et dans les vieilles autant que celles qui ne soient pas encore sorties) Est ce qu’on reste attaché à l’efficacité de nos systèmes, qui nous rends si fière ? ## Snap ## Je connais pas, je vais pas en parler non plus. ## Flatpak ## Mais maintenant, on a flatpak. C’est cool. C’est l’avenir. Mais on veut résoudre quoi au juste ??? **- La facilité d'installation pour les utilisateurs ?** Un flatpak install XXX est il plus accessible qu'un apt-get install XXX ? Aller ajouter des "repos" à la main avec "flatpak remote-add" est il mieux que d'aller ajouter des dépôts avec "add-apt-repository" ? Aller cliquer dans Gnome Software est il plus facile que d’aller cliquer dans synaptic (ou celui que vous voulez) ? Mieux qu’un double clique sur un AppImage ? Et on ne peux toujours pas télécharger un flatpak et le stocker sur une clée usb pour l’utiliser ou le partager hors ligne. Par ce que les novices ils vont toujours avoir le reflex. Et pour cliquer sur "installer ce flatpak" et bien ils ont intéret d’avoir une distrib compatible. C’est so 2009 de télécharger et d'exécuter son logiciel. Maintenant on à un store, comme les grands. **La facilité de packaging pour les développeurs libres ?** Un flatpak n’est pas plus simple à produire qu'un paquet lamba. Ok peut être plus simple que de produire X paquets pour X distribs. Après les outils progresseront sans doute, peut être qu’un jour on pourra faire "cmake && make && make flatpak". En attendant, accrochez vous à la doc... Par contre moi en plus de faire ubuntu, fedora, mint, gentoo, je dois faire un flatpak en plus. Naaan jdéconne. Je fais qu’un AppImage de toute manière. **La facilité de packaging pour les développeurs de logiciels non libres ?** Ceux qui jouent le jeu font habituellement un .deb, un .rpm et un .tar.gz. Ceux qui jouent pas le jeu vont subitement se mettre a flatpak. Merci flatpak. Maintenant qui fait vraiment du flatpak dans les éditeurs proprio ? Sur Gnome Software j'ai trouvé Steam et Skype. Et pas mal de "wrapper" fait par la communauté. Super. **Est ce que c'est la sécurité des paquets ?** Pour la mise à jour des runtimes... on à toujours notre distribution qui fait la même chose, non ? Mieux même, car on ne duplique rien. **Est ce que c'est la sécurité des paquets logiciels non libres alors ?** Pour la mise à jour des runtimes... Ok. Soit. Si on pense que les problèmes de sécurités viennent principalement des dépendances (libres) des logiciels (propriétaires) alors il y a là un progrès. Mais qui pensent ça ? Franchement ? Vous allez maintenant faire confiance à Skype par ce que sa version de curl est à jour ??? Qui a pensé que la communauté allait régler le problème des gens et sociétés qui refusent de mettre à jour leur applis ? **Mais l’efficacité ?** C’est surtout la que je suis choqué. L’efficacité on peut oublier, c’était avant, maintenant on est dans le futur. On peut aborder ce problème de pas mal de manière. Je pourrai vous dire que installer une seul application de 5Mo avec flatpak prends maintenant 5 Mo + 1 Go de runtimes. Je pourrai vous dire qu’avec 10 applications, vous avez potentiellement 10 Go de runtimes. Par ce qu’il y à plusieurs, et que votre paquet à linké avec telle version de telle runtime. Je pourrai aussi vous dire que j’ai fais une app Qt (qui pèse 5 Mo d’ailleurs, 38 en AppImage) et qu’on m’a dit "utilise le runtime KDE". Par ce que Qt, c’est KDE. Non ? Je pourrai vous dire que de toute manière, il manquait des dépendances dans les runtimes et qu’il est marqué "Flatpak makes it easy to bundle your own libraries as part of your app". Que du coup j’ai vraiment pas compris. Et que maintenant mon app elle pèse 1 Go. Et si on met à jour une lib dans le runtime... J’espère que vous avez la fibre. Steam utilise un système similaire d’overlay. Sauf qu’il n’y en a qu’une seul version, et que si il manque une librairie, on ajoute... une librairie. Allez c’est même pas vrai, depuis 2013 ils ont ajouté une deuxième version. Ils ont donc seulement 800 Mo d’overlay, pour faire fonctionner des milliers de jeux vidéos. Depuis 2013. **Sandboxing** Ouai. C’est plutôt cool. C’est bien de limiter l’accès à quelques trucs, genre les fichiers de configs et temporaires des applis d'à coté. C’est bien de limiter l’accès à la webcam dans un éditeur de texte (vu qu’il tourne probablement sur electron dans un chrome, c’est même vraiment important). Après si l’histoire nous à appris quelque chose avec Android (qui sandbox très bien, liste ses permissions et les demandes mêmes explicitement aux utilisateurs maintenant) c’est que... le mec va cliquer sur oui. Toi même tu sais. Et puis le sandboxing ça s’arrête la ou les fonctionnalités commencent. Si tu fais un logiciel qui à besoin de l’accès aux fichiers (quelques logiciels font ça) ben ton sandboxing il va en prendre un coup... Chrome est sandboxé depuis très longtemps, Android aussi. Si ça à empêcher quelques personnes de faire du mal, la littérature est maintenant abondante sur les limites de ces mécanismes. C'est pas magique. Du tout. Si un logiciel ne mérite pas votre confiance, sandboxing ou non, il ne devrait pas tourner. N’essayons pas de résoudre un problème social avec la technologie. # Conclusion # _La question est donc de savoir si l’on souhaite ou non démocratiser l’utilisation de GNU/Linux auprès du grand public._ Et si c’était le cas, on aurait pu réfléchir à rationaliser un peu ce bordel de distributions, on aurait pu réfléchir à ce qui bloque les vieux et les jeunes qui sont lâchés devant un Linux, on aurait pu s’atteler à boucher les trous béant à l’usage dans nos environnements de bureaux, on aurait pu capitaliser sur ce qui fait la force de notre plateforme et ce qui fait que se sont pourtant les autres qui sont utilisées. Mais à la place, on a fait un nouveau gestionnaire de paquet. Bon vendredi à tous.

AltStyle によって変換されたページ (->オリジナル) /