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.