J'aime pas les AppImage

De nos jours, pas mal de logiciels sous Linux sont distribués sous la forme de binaires AppImage. C’est un moyen qui dispose de nombreux avantages que ce soit pour l’utilisateur ou le développeur… Mais qui introduit aussi d’autres soucis qui ont tendance à m’irriter lorsque je me retrouve confronté à ceux-ci.

Ce billet exposera mon point de vue sur ce type de distribution.

Qu’est-ce les AppImage

Un peu d’histoire

AppImage ne date pas d’hier, le projet est né en 2004 sous le nom “Klik”. Klik devait s’intégrer aux navigateurs Web et fournir une interface permettant de récupérer les prérequis pour un logiciel et les assembler sous la forme d’un fichier unique .cmg. L’utilisateur se contentait de télécharger une “recette” que Klik déroulait. De manière très simplifiée, c’est la même approche que le dépôt AUR de Arch Linux où les utilisateurs proposent des fichiers PKBUILD prêts à l’emploi que Pacman peut exécuter pour compiler une application. La grande différence se situe dans le fait que le résultat produit n’est pas un ensemble de binaires et de bibliothèques, mais un fichier binaire unique autonome.

Le projet fut succédé par PortableLinuxApps qui reprit une bonne partie de la philosophie de Klik. Enfin, en 2013, le projet fut de nouveau renommé en AppImage, qui correspond au nom du format produit par l’AppImageKit, l’outil permettant de les générer.

Le principe

Un binaire AppImage n’installe pas à proprement parler d’application. Il n’altère aucunement le système hôte car il suffit de télécharger le fichier, le rendre exécutable, et le lancer. L’application se situe dans une sorte de conteneur dans lequel se trouve toutes les dépendances dont elle a besoin pour fonctionner. Au lancement, le fichier binaire est monté comme un système de fichiers avec FUSE depuis lequel l’application est exécutée. De ce fait, l’application ne requiert aucun droit d’administrateur pour être installée ou lancée car tout se produit dans le user space.

Les avantages d’AppImage

L’une des forces de l’écosystème Linux est aussi l’une de ses plus grandes faiblesses : sa diversité. Le nombre de distributions Linux est hallucinant et cela créé autant de complexité qu’il y a de distributions sur le marché. De ce fait, la construction de paquets applicatifs peut s’avérer fastidieuse car il y a un risque de tomber dans l’enfer des dépendances, des versions différentes entre les distributions, de la méthode de livraison qui peut varier, devoir se plier aux exigences du gestionnaire de paquets du système, les composants utilisés par la distribution, etc.

Le premier problème auquel s’adresse AppImage, c’est justement cette diversité. En fournissant un paquet entièrement autonome et portable, la base OS ne fait plus de différence et le même binaire peut être exécuté sur la quasi totalité des distributions.

Pas besoin de droits admin, installation simplifiée : Un AppImage se télécharge, se rend exécutable, et se lance. C’est tout.

Pas besoin d’installer de dépendances ou de compléments, un binaire AppImage est entièrement autonome. Il peut même être déposé sur un LiveUSB ou encore utilisé par plusieurs distributions en dual-boot.

Quelques fonctionnalités supplémentaires : on peut monter l’image pour explorer son contenu comme n’importe quel autre système de fichier, extraire le contenu, etc.

Attends un peu … Les AppImage n’ont pour ainsi dire que des avantages, c’est quoi ton problème sale vieux ronchon ?

– L’autre type dans ma tête

Pourquoi je ne les aime pas ?

Espace disque utilisé plus élevé

Le premier point qui me vient en tête, c’est la taille des images. Comme elles doivent contenir tout le nécessaire pour fonctionner, avec leurs environnements d’exécution, cela prend de la place. De ce fait, le moindre logiciel prend plusieurs dizaines de méga octet sur le disque. Vous allez me dire qu’avec les disques de 1TB devenus le standard ça n’a plus d’importance, mais il me paraît important de penser qu’une utilisation efficiente des ressources devrait rester une nécessité.

Cela ne peut m’empêcher justement de faire une comparaison avec les applications Desktop basées sur Electron. Electron est un environnement d’exécution pour les logiciels développés en techno Web sur un environnement de bureau. Ce n’est ni plus ni moins que le moteur Javascript de Chromium. qui permet de faire le rendu… Résultant que la moindre application embarque 150MB de runtime. Multiplié par le nombre d’applications basées dessus puisque chacune vient avec son environnement.

Revenons sur AppImage avec comme exemple le client de synchronisation Nextcloud proposé aussi bien sous forme de paquet RPM que de AppImage.

102M Nextcloud-3.3.5-x86_64.AppImage
2,3M nextcloud-client-3.3.5-1.fc34.x86_64.rpm

La raison ? Le binaire AppImage contient l’ensemble des bibliothèques sur lesquelles le client Nextcloud repose. Le RPM ne contient que les binaires et quelques bibliothèques spécifiques. Evidemment, cette comparaison est un peu biaisée car le RPM va tirer les bibliothèques dont il a besoin en dépendance. Mais celles-ci seront partagées avec d’autres applications, donc elles seront potentiellement déjà présentes ou réutilisées.

## Contenu du RPM
16K	./lib
2,9M	./bin
8,0M	./share
11M	.

## Contenu du AppImage
6,1M	./bin
208M	./lib
10K	./libexec
2,7M	./plugins
9,0M	./qml
21M	./resources
8,2M	./share
18M	./translations
272M	.

Les mises à jour sont fastidieuses

Quand on est un habitué d’un système Linux, on passe la majorité du temps à installer ses logiciels via le gestionnaire de paquets. Cet outil pilote l’ensemble des composants installés sur le système et s’assure de les mettre à jour à la demande (ou automatiquement si l’utilisateur le choisi). De ce fait, les bibliothèques et logiciels sont toujours à la version la plus récente proposée par la distribution Linux en question.

Alors oui, un des travers auquel AppImage répond est la possibilité d’avoir un composant dans une version différente de celle proposée par la distribution. Notamment les distributions ayant un support à long terme qui vont rester sur des versions fixes de certains composants et ne proposeront que les mises à jour de sécurité de ceux-ci. Les nouvelles versions étant proposées dans les versions majeures de la distribution, certaines fonctions peuvent arriver après plusieurs mois voire années.

Cependant, la chose qui m’agace avec AppImage, c’est l’absence de mise à jour automatisée. Pourtant, il existe bien un système de mise à jour différentielle permettant en plus de gérer le delta entre les deux AppImage… Mais pour cela il est nécessaire que le créateur du binaire AppImage l’ait intégré ! C’est le même problème que les développeurs qui proposent un RPM pour leurs applications mais que ceux-ci ne sont pas proposés via un dépôt logiciel… Obligé de télécharger le paquet pour l’installer manuellement.

Si AppImageUpdate est une bonne réponse à cette problématique, il n’empêche qu’il s’agit ici aussi d’un outil dédié autonome qui n’est pas intégré au système. De ce fait, vous devez déclencher vous même la mise à jour si l’application AppImage vous le notifie. De plus, il est essentiel que le développeur du paquet AppImage ait intégré les informations de mise à jour pour que AppImageUpdate puisse fonctionner !

Pour ma part, j’ai testé avec différents logiciels que j’ai du installer ainsi : Ultimaker Cura, Diagram.net, Infomaniak kDrive. Aucun ne l’a intégré.

Yep, aucune des images n’a été compatible…

De mon point de vue, quand on compare à un gestionnaire de paquets qui centralise toute cette maintenance, c’est une régression.

L’intégration avec le système

La philosophie d’autonomie complète des AppImage entraîne de fait une décorrélation avec le système d’exploitation. Comme dit précédemment, à moins que le développeur n’ait intégré AppImageUpdate, la mise à jour est entièrement manuelle. Pour avoir une appli AppImage qui se lance au démarrage du système, il est là aussi nécessaire de faire des actions manuelles.

Exemple avec le client de synchro kDrive, basé sur celui de ownCloud et fourni en AppImage. Dans les options du logiciel, vous pouvez le mettre en lancement au démarrage et ça fonctionne sans souci comme n’importe quelle appli native. Cependant, si on se base sur le fonctionnement proposé par AppImage qui est chmod a+x fichier.AppImage puis lancement, on constate un souci.

Le chemin de l’exécutable est celui du fichier AppImage. Si vous oubliez de retirer l’ancien pour mettre le nouveau au démarrage du système, c’est l’ancienne version qui reviendra ! Je m’en suis rendu compte quand après la mise à jour la notification “hé, nouvelle version !” avait réapparu au redémarrage suivant.

L’exemple montre aussi un autre souci : l’exécutable est présent dans mon dossier Téléchargements (en vrai non, mais c’est pour la démonstration…). En gros, votre système d’exploitation devient un bordel et nous ne savez plus où sont installés les logiciels, car …

… Un AppImage ne s’ajoutera pas à votre lanceur d’applications. C’est à vous de le faire en ajoutant l’entrée manuellement à votre gestionnaire de bureau. Au mieux, vous le trouverez de base dans les fichiers récents.

AppImage a répondu à ce souci en créant le daemon appimaged. Ce service pourra scruter différents dossiers de votre choix et ajoutera les AppImage à votre lanceur d’application. Il peut aussi gérer la mise à jour de celles-ci. Mais quand on a déjà un gestionnaire de paquets pour gérer tout ça, pourquoi faut-il une nouvelle surcouche ?

L’un des autres soucis que je peux voir avec cette idée d’une binaire utilisable n’importe où est dans le cas d’une installation Linux renforcée en matière de sécurité. Les recommandations de l’ANSSI suggèrent d’appliquer le drapeau noexec au montage /home. Rendant de ce fait l’utilisation d’AppImage dedans impossible. Evidemment, tous les PC Linux ne sont pas configurés ainsi, ceci s’adressant plutôt au monde des serveurs.

Pour ma part, aimant avoir un système organisé, j’ai conservé l’habitude de stocker les AppImage dans /opt/nom_de_lapplication.

En conclusion et résumé

AppImage répond très bien à une vieille problématique de Linux et c’est une méthode de distribution logicielle qui a de nombreux avantages, comme nous avons pu le constater durant sa présentation. Cependant, sa déconnexion totale du reste de l’OS et son autonomie font qu’il devient nécessaire de tout gérer à la main, ce qui est une forte régression pour moi. Si le projet a apporté depuis des outils pour aider à la maintenance des versions, cela reste au bon vouloir du développeur du binaire et ajoute une surcouche à ce qui existe déjà.

Ce qui me pose problème, ce n’est pas spécialement AppImage qui est un moyen de distribution logiciel formidable, mais plutôt la paresse d’utiliser exclusivement ce moyen quand un gestionnaire de paquets fait très bien le boulot. Je pense par exemple à Ultimaker Cura uniquement distribué ainsi alors que c’est un logiciel développé majoritairement en Python. De mon point de vue, AppImage devrait être une solution de repli ou parallèle, et non le standard. Auquel cas il serait nécessaire qu’il ait une bien meilleure intégration avec le système.