Ces dernières années, les paquets multi-distributions ont gagné en attractivité sous Linux. Des solutions intéressantes à première vue, mais pas sans contraintes. Nous faisons le point sur les trois principales, de leur concept central à leurs avantages et inconvénients, en passant par leurs différences.

La diffusion de logiciels est depuis longtemps à l’avantage des distributions Linux face à macOS et Windows. Les différents systèmes de paquets sont exploitables aussi bien en ligne de commande que via des interfaces graphiques.

L’utilisateur reste maître de cette utilisation, notamment dans le choix d’inclure des logiciels aux sources fermées ou non, via les fameux dépôts. Ces derniers livrent aujourd’hui aussi bien les applications que les nouvelles versions de l'OS, le noyau Linux lui-même et ainsi de suite. Chacun peut d'ailleurs en créer pour son propre usage ou en les rendant disponibles à tous.

Depuis plusieurs années, un autre type de paquet envahit peu à peu l’espace Linux : le « tout-en-un », basé sur le concept d’image disque ou de conteneur selon les cas. Pour l’utilisateur, le changement se veut transparent, bien qu'il ne le soit pas toujours. Les développeurs, eux, sont encouragés à y passer, chacun vantant les avantages de sa solution.

Canonical est notablement très enthousiaste sur ses snaps... qui font grincer des dents.

Paquets contre paquets

Pour comprendre ce qui différencie ce nouveau type de paquets des anciens, il faut expliquer comment fonctionne la distribution traditionnelle d'applications sous Linux, reposant sur des applications visant une plateforme particulière.

Les paquets contiennent normalement les dépendances nécessaires, c’est-à-dire les ressources dont l’application a besoin pour fonctionner. On pourrait comparer (très) grossièrement aux DLL de Windows quand un logiciel est installé. Les distributions Linux savent depuis longtemps télécharger les dépendances quand celles-ci sont absentes.

Une action facilement visible en ligne de commande : quand on demande par exemple à APT d’installer un paquet, il avertit automatiquement des éléments manquants, précisant qu’ils seront installés au passage.

Cette faculté, ajoutée à l’aspect centralisé des commandes d’installation, a toujours rendu cet aspect nettement plus évident dans sa logique que sur les plateformes concurrentes comme macOS ou Windows. Certes, ces dernières disposent de leurs propres boutiques applicatives, mais il s’agit bien de vendre (idéalement) et de retenir une commission – même si de nombreuses applications sont gratuites – plutôt que de repenser la distribution et l'installation.

Logiciels dans Fedora 32

Autre gros avantage de la manière de faire sous Linux, la mise à jour automatique gérée par un unique service. Là encore, sur les plateformes concurrentes, soit la boutique s’en occupe, soit le logiciel doit avoir un mécanisme intégré. Une situation qui n’évolue pour ainsi dire pas :  la proportion d’applications sur les boutiques d’Apple et Microsoft reste faible.

L'ère des paquets « tout-en-un »

Cela étant, la gestion des paquets sur les systèmes Linux répond aux spécificités de chaque distribution. Les deux formats les plus courants, deb et rpm, ont ainsi leurs particularités et visent des familles d'OS différentes. Le premier est le format adopté par Debian et donc par les dizaines de distributions qui en sont dérivées (dont Ubuntu), tandis que le second est depuis longtemps soutenu par Red Hat et se retrouve notamment dans Fedora et openSUSE.

En outre, cette solution peut rencontrer les mêmes problèmes que d’autres systèmes utilisant des composants communs accessibles aux applications. Il peut y avoir conflit, chaque mise à jour du système ou d’un seul composant devant être testée aussi bien par les développeurs d’un système que ceux d’une application.

C'est là qu'AppImage, Flatpak et Snap entrent en scène. Leur avantage ? Ils fournissent des paquets contenant tout le nécessaire à une application, sans avoir à gérer les particularités de chaque système. Il faut simplement que ces derniers gèrent ces approches, qui se veulent ainsi « agnostiques ».

Elles n’ont cependant pas toutes les mêmes caractéristiques. Elles permettent de régler nombre de soucis potentiels et de se simplifier la vie, mais pas sans coût. De plus, leur pluralité est autant une force qu’une faiblesse. Explications.

AppImage : le plus ancien

AppImage, dans sa forme actuelle, existe depuis 2013. Ce système de paquet est maintenu depuis dans son dépôt GitHub sous licence MIT. Son principal auteur, Simon Peter, n’était pas un novice dans le domaine, puisqu’il avait déjà créé Klik, que l’on peut qualifier d’ancêtre d’AppImage, dès 2004. Le projet fut abandonné en 2011 au profit de PortableLinuxApps, finalement renommé en AppImage en 2013. Son mantra est depuis : « une application = un fichier ».

Le nom résume à lui seul la philosophie du projet : l’image d’une application. Un fichier unique, qu’il suffit de monter puis de lancer, contenant le programme et toutes ses dépendances, même si le format est souple et laisse les développeurs libres d’intégrer ce qu’ils souhaitent. Une situation très comparable aux fichiers DMG que l’on trouve sur macOS.

Chez Apple, une fois l’image montée, on peut prendre l’application et la copier vers une destination, d’où on pourra la lancer. Traditionnellement, on la range dans Applications, mais ce n’est qu’une commodité. L’application se présente comme un fichier unique, en fait une archive contenant toutes les données nécessaires.

AppImage ne réclame aucun accès administrateur. D’ailleurs, il n’y a techniquement aucune installation, puisqu’on se contente de lancer un fichier exécutable. L’application se lance sans avoir à vérifier que les dépendances existent dans le système. Quoi qu’il lui faille pour s’afficher correctement, le développeur y a normalement pourvu. Sans installation, plusieurs versions différentes d’une application peuvent fonctionner côte à côte.

AppImage est très clairement pensé pour la distribution d’applications classiques vers les utilisateurs finaux. On reste sur l’idée d’un format portable, puisque l’image peut très bien être placée sur une clé USB et exécutée telle quelle sur une autre distribution. Pour ceux qui le souhaitent, AppImageKit permet même de fabriquer sa propre image à partir d’une application installée sur sa machine.

AppImaged, le service responsable du bon fonctionnement des paquets AppImage, est présent sur un très grand nombre de distributions, dont Debian, Ubuntu, Fedora, CentOS et openSUSE. Il n’y a pas de dépôt officiel centralisant les versions AppImage des applications, mais le site AppImageHub sert par exemple de concentrateur tiers.

Snap : le mastodonte promu par Canonical

Ubuntu intègre un autre format de fichier tout-en-un, mais conçu différemment et servant des objectifs plus larges. On retrouve l’idée d’une archive contenant une application, mais contrairement à AppImage qui offre une certaine souplesse, un snap contient forcément l’intégralité des dépendances, permettant au logiciel de fonctionner sans vérification.

On reste ainsi sur le principal avantage déjà mis en avant par AppImage : les développeurs n’ont pas à viser de plateforme particulière. Il suffit que le système embarque snapd, le service responsable de la gestion des snaps. Ubuntu et un nombre croissant de distributions l’intègrent. Mais il existe plusieurs différences techniques notables avec AppImage.

Les mises à jour sont ainsi transactionnelles : la nouvelle version peut s’installer pendant que l’ancienne fonctionne encore, les différences étant appliquées au lancement suivant. En outre, dans le cas où une mise à jour introduirait des problèmes, l’utilisateur peut revenir facilement à l’état antérieur.

Il y a donc maîtrise des versions et simplification de l’administration dans ce domaine. Un avantage entrainant un inconvénient : contrairement à AppImage, snapd ne permet pas l’exécution concurrentielle de plusieurs instances d’une même application, y compris de versions différentes. Une fonction expérimentale a été introduite l’année dernière pour permettre les installations parallèles, mais la documentation s’y rapportant n’a pas été mise à jour depuis neuf mois.

Les snaps savent cependant gérer les canaux de distribution. Une application disposant d’un canal bêta spécifique pourra ainsi être installée aux côtés de la version stable, sans que l’une empiète sur l’autre. Snapd permet en outre de prendre des instantanés (snapshots) des snaps en cours d’exécution, via la commande principale snap save.

L’opération peut être ponctuelle ou automatisée, par exemple pour définir une sauvegarde des états à intervalles réguliers, définis par l’utilisateur. Les instantanés permettent alors de restaurer une application dans un état spécifique.

Mais la plus grosse différence entre AppImage et Snap est sans conteste l’obligation, pour ce dernier, d’exécuter les applications de manière isolée, dans le cas présent une version modifiée d’AppArmor. Les droits de l’application contenue dépendent du niveau défini dans le snap : classic, strict ou devmode. Il y a donc un apport réel de sécurité, puisqu’un logiciel donné n’aura que des interactions très contrôlées avec le reste du système.

Contrairement à AppImage et Flatpak, les snaps sont conçus pour être installés dans toutes sortes d’environnements, notamment les serveurs et les objets connectés (IoT). Canonical a imaginé sa solution comme une technologie transversale permettant de vastes déploiements, quand les autres ont des approches beaucoup plus « desktop-centric ».

Les snaps ne sont pas étrangers à la critique, loin de là. L'isolation, tout d’abord, n'est pas aussi complète qu’on le souhaiterait, nécessitant l’accès à certains composants centraux du système pour fonctionner. En outre, les vieilles applications X11 sont incompatibles. Les snaps sont également très volumineux. La taille des fichiers est souvent multipliée par deux, trois ou quatre comparée à l’équivalent AppImage.

Ce n’est peut-être pas un problème pour nombre de machines, mais pour celles équipées de petits SSD ou les utilisateurs n’ayant pas un débit de téléchargement très élevé pourront se sentir pénalisés.

Le plus important reproche fait aux snaps est cependant lié à leur popularité. Il est vrai que propulsés par la très connue distribution Ubuntu, ils sont assurés d’une bonne visibilité. Depuis, l’intégration de snapd dans d’autres systèmes et l’utilisation de ce format par des acteurs majeurs comme KDE, Google, Microsoft, Mozilla ou encore Spotify l’ont presque transformé en standard de facto, au grand dam d’un nombre croissant de voix.

Deux problèmes majeurs ont été relevés. D’abord la présence, au sein de snapd – le service d’installation et de gestion des paquets snap – de code propriétaire de Canonical, donc source d’agacement dans la communauté du logiciel libre. Ensuite, une crainte de situation hégémonique sur la distribution des paquets, l’éditeur étant suivi de grands noms du secteur.

La situation trouve un parfait exemple de ces tensions dans l’annonce récente par l’équipe de Linux Mint d’une renonciation à installer snapd par défaut dans le système. Pourquoi ? Parce que Canonical n’a pas tenu sa promesse initiale : snapd ne devait jamais être rendu obligatoire pour installer une application. Or, la distribution de Chromium sur Ubuntu passe uniquement par un snap, donc requiert snapd.

Face à cette « trahison », les développeurs de Mint ont décidé de ne plus inclure snapd. Depuis Logiciels, l’interface GNOME servant à installer des applications, on peut toujours voir Chromium, mais il s’agira d’un paquet vide. Son installation affiche un résumé de la situation, l’utilisateur restant libre d’installer snapd s’il le souhaite.

Un changement qui sera effectif dans la version 20, dont la bêta est imminente, basée sur Ubuntu 20.04 LTS. Notez que toutes les applications encapsulées en snap sont disponibles dans le dépôt officiel de Snapcraft.io. Le code open source, sous GPL 3.0, est disponible sur le dépôt GitHub du projet. 

Flatpak : un concurrent direct aux snaps

Le fonctionnement de Flatpak se rapproche davantage des snaps que d’AppImage, même si le concept central reste le même. On retrouve un paquet contenant l’application et toutes ses dépendances, le tout reposant sur un mécanisme d'isolation. Là encore, l’application ainsi lancée se passe de droits administrateur.

Le projet ayant abouti à Flatpak se nommait précédemment xdg-app. Il fut écrit en 2015 par Alexander Larsson – alors développeur chez Red Hat sur la base d’une idée formulée plus d’une décennie avant par Lennart Poettering. Larsson était déjà familier avec ce type de développement, puisqu’il avait suivi de près le projet Klik, ancêtre d’AppImage. Il préférait cependant l’idée d’une exécution isolée de l’application.

Les forces de Flatpak sont nombreuses et en partie similaires à snap (tout comme certaines de ses faiblesses). Les flatpaks se distinguent cependant par leur intégration visuelle, la technologie ayant été pensée dans une optique d'utilisation via une interface graphique (GUI) plutôt qu'en ligne de commande (CLI), tout particulièrement GNOME et KDE.

Tout comme les snaps, ils sont en théorie insensibles aux changements de versions du système. Mais les développeurs ont un peu plus de libertés dans les éléments qu’ils souhaitent intégrer dans le paquet, de même que le choix de le distribuer eux-mêmes, en dépit de l’existence d’un dépôt officiel : FlatHub. Une différence de taille avec les snaps centralisés.

Par défaut, une application Flatpak n’a accès à presque rien : données personnelles, réseau, autres processus, etc. Pour débloquer ces capacités, les développeurs doivent prévoir des Portals, littéralement des portes vers des composants du système. Aucun Portal ne peut être ouvert sans accord explicite de l’utilisateur.

Souvent, les développeurs n’ont cependant rien à faire, car de nombreux frameworks intègrent déjà cette gestion, comme GTK3 ou Qt5. Contrairement à Snap, l’exécution de plusieurs versions d’une même application est possible. L'isolation prend appui sur Bubblewarp, mais la sécurité de Flatpak a été sévèrement critiquée, sur plusieurs aspects.

Les applications les plus populaires ont ainsi souvent de nombreuses autorisations actives par défaut. Ensuite, l’application des correctifs de sécurité dans le dépôt central serait trop lente. Est également critiqué le classement comme « mineure » d’une faille de sécurité qui permettait un accès root (local) complet, au sein même du framework de gestion.

On pourrait en outre critiquer la taille des paquets, comme pour les snaps. Selon les applications, l’une ou l’autre version sera la plus volumineuse. Il faut donc tenir compte là aussi d’un éventuel manque de place avec la multiplication des applications. Les sources du projet sont disponibles dans ce dépôt GitHub.

Le futur de la distribution ?

Chaque technologie a ses qualités et défauts. Chacune semble plus adaptée à certains scénarios que les autres. Aucune cependant ne peut prétendre à l’universalité. Il reste probable que les snaps, poussés par Canonical, resteront pendant un temps la solution la plus visible. Ne serait-ce que parce qu’elle permet à de nombreux éditeurs de proposer un seul paquet à destination de toutes les distributions Linux intégrant snapd.

Mais l'entreprise va devoir être vigilante. En prenant notamment soin de snapd, car elle est déjà revenue sur sa promesse de ne pas le rendre obligatoire pour l’installation d’applications sur Ubuntu, donc les distributions qui le reprennent. Linux Mint n’a beau être « qu’un » système dérivé, il est assez connu pour que le problème soit sous les feux des projecteurs. Canonical opérant dans le monde du logiciel libre, un passage en force pourrait provoquer une vive réaction générale.

Il n’est pas certain non plus que les utilisateurs soient directement témoins des avantages portés par ces solutions. Cela reste des applications lancées, la plupart du temps, depuis une grille. Ils pourraient cependant s’agacer de voir la consommation d’espace disque exploser avec l’installation d’applications.

D’un point de vue technique, ces types de paquets offrent de réels avantages dans la distribution, ne serait-ce justement que parce qu’ils la simplifient pour les éditeurs. Le concept d’exécution de type conteneur est là aussi – et dans l’absolu – très intéressant sur le plan de la sécurité, mais pas sans défaut.

Le projet le plus abouti semble toutefois toujours AppImage, sans doute parce qu’il est aussi le plus ancien. Les développeurs ont le choix d’intégrer ou non un mécanisme de sandbox, et tout ou partie des dépendances, sans modifier le concept central d’un fichier par application.

Dans la bataille, qui ne fait que commencer, l’utilisateur devra rester au centre des préoccupations. Dans ce contexte, certains risquent par exemple de ne pas comprendre la décision de Linux Mint, puisque l’expérience d’utilisation va directement en pâtir. Les décisions de Canonical seront à suivre de près.