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Ă©.

update

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.

applidemarrage

applidemarrage

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.