Comparaison des gestionnaires de packages Linux : AppImage vs Snap vs Flatpak
Les gestionnaires de packages permettent de regrouper, de distribuer, d'installer et de gérer des applications dans un système d'exploitation. Avec les applications de bureau, de serveur et IoT modernes du système d'exploitation Linux et les centaines de distributions différentes qui existent, il devient nécessaire de s'éloigner des méthodes de packaging spécifiques à la plate-forme au profit de méthodes indépendantes de la plate-forme. Cet article explore trois de ces outils, à savoir AppImage, Snap et Flatpak, qui visent chacun à être l'avenir du déploiement et de la gestion de logiciels sous Linux. À la fin, nous résumons quelques conclusions clés.
1. AppImage
AppImage suit un concept appelé « Une application=un fichier ». Cela doit être compris comme une AppImage étant un « fichier » indépendant régulier contenant une application avec tout ce dont elle a besoin pour s’exécuter dans ledit fichier. Une fois rendue exécutable, AppImage peut être exécutée comme n'importe quelle application sur un ordinateur en double-cliquant simplement dessus dans le système de fichiers de l'utilisateur.[1]
Il s'agit d'un format permettant de créer des logiciels portables pour Linux sans nécessiter que l'utilisateur installe ladite application. Le format permet aux développeurs d'origine du logiciel (développeurs en amont) de créer une version indépendante de la plate-forme et de la distribution (également appelée version binaire indépendante de la distribution) de leur application qui fonctionnera essentiellement sur n'importe quelle version de Linux.
AppImage existe depuis longtemps. Klik, un prédécesseur d'AppImage, a été créé par Simon Peter en 2004. Le projet a été arrêté en 2011 après n'avoir pas passé la phase bêta. Un projet nommé PortableLinuxApps a été créé par Simon à peu près à la même époque et le format a été repris par quelques portails proposant des logiciels pour les utilisateurs de Linux. Le projet a été renommé à nouveau en 2013 sous son nom actuel AppImage et un référentiel a été maintenu dans GitHub (lien du projet) avec toutes les dernières modifications apportées depuis 2018.[2][3]
Écrit principalement en C et bénéficiant de la licence MIT depuis 2013, AppImage est actuellement développé par Le projet AppImage. C'est une manière très pratique d'utiliser les applications comme le démontrent les fonctionnalités suivantes :
- AppImages peut fonctionner sur pratiquement n'importe quel système Linux. Comme mentionné précédemment, les applications tirent de nombreuses fonctionnalités du système d'exploitation et de quelques bibliothèques courantes. Il s'agit d'une pratique courante dans le monde du logiciel, car si quelque chose est déjà fait, cela ne sert à rien de le refaire si vous pouvez choisir les parties à utiliser. Le problème est que de nombreuses distributions Linux peuvent ne pas disposer de tous les fichiers dont une application particulière a besoin pour s'exécuter, car il appartient aux développeurs de cette distribution particulière d'inclure les packages nécessaires. Par conséquent, les développeurs doivent inclure séparément les dépendances de l'application pour chaque distribution Linux pour laquelle ils publient leur application. En utilisant le format AppImage, les développeurs peuvent choisir d'inclure toutes les bibliothèques et tous les fichiers qu'ils ne peuvent pas espérer que le système d'exploitation cible ait dans le fichier AppImage. Par conséquent, le même fichier au format AppImage peut fonctionner sur différents systèmes d'exploitation et machines sans avoir besoin d'un contrôle granulaire.
- La philosophie « une application, un fichier » signifie que l'expérience utilisateur est simple et élégante dans la mesure où les utilisateurs n'ont besoin que de télécharger et d'exécuter un seul fichier qui répondra à leurs besoins d'utilisation de l'application.
- Aucun accès root requis. Les administrateurs système exigeront que les utilisateurs disposent d'un accès root pour les empêcher de jouer avec les ordinateurs et leur configuration par défaut. Cela signifie également que les personnes sans accès root ni privilèges de super-utilisateur ne peuvent pas installer les applications dont elles ont besoin à leur guise. Cette pratique est courante dans un environnement public (comme les ordinateurs d'une bibliothèque ou d'une université ou sur les systèmes d'entreprise). Le fichier AppImage ne nécessite pas que les utilisateurs « installent » quoi que ce soit et par conséquent, les utilisateurs n'ont qu'à télécharger ledit fichier et à le rendre exécutable pour commencer à l'utiliser. Cela supprime les dilemmes d'accès auxquels sont confrontés les administrateurs système et facilite leur travail sans sacrifier l'expérience utilisateur.
- Aucun effet sur le système d'exploitation principal. Le format d'application AppImage permet d'utiliser les applications avec toutes leurs fonctionnalités sans avoir besoin de modifier ni même d'accéder à la plupart des fichiers système. Cela signifie que quoi que fassent les applications, la configuration principale du système d’exploitation et les fichiers restent intacts.
- Une AppImage peut être créée par un développeur pour une version particulière de son application. Toute version mise à jour est créée sous la forme d'une AppImage différente. Ainsi, si nécessaire, les utilisateurs peuvent tester plusieurs versions de la même application en exécutant différentes instances à l'aide de différentes AppImages. Il s'agit d'une fonctionnalité inestimable lorsque vous devez tester vos applications à partir du point de vue d'un utilisateur final pour remarquer des différences.
- Emportez vos candidatures partout où vous allez. Comme mentionné précédemment, les AppImages sont des fichiers archivés de tous les fichiers requis par une application et peuvent être utilisés sans installer ni même se soucier de la distribution utilisée par le système. Par conséquent, si vous utilisez régulièrement un ensemble d'applications, vous pouvez même monter quelques fichiers AppImage sur une clé USB et les emporter avec vous pour les utiliser sur plusieurs ordinateurs exécutant plusieurs distributions différentes sans vous soucier de leur fonctionnement ou non.
De plus, AppImageKit permet aux utilisateurs de tous horizons de créer leurs propres AppImages à partir d'applications qu'ils possèdent déjà ou pour des applications qui ne reçoivent pas d'AppImage par leur développeur en amont.
Le gestionnaire de packages est indépendant de la plate-forme mais se concentre principalement sur la distribution de logiciels aux utilisateurs finaux sur leurs ordinateurs de bureau avec un démon dédié AppImaged pour intégrer les formats AppImage dans les environnements de bureau respectifs. AppImage est désormais pris en charge nativement par une variété de distributions telles que Ubuntu, Debian, openSUSE, CentOS, Fedora, etc. et d'autres peuvent la configurer selon leurs besoins. AppImages peut également être exécuté sur des serveurs aux fonctionnalités limitées via les outils CLI inclus.
Pour en savoir plus sur AppImages, accédez à la page officielle de documentation AppImage.
Lecture suggérée :
- Intégrer AppImages au menu d'application à l'aide d'AppImageLauncher
- Rechercher des applications Linux sur les plates-formes AppImage, Flathub et Snapcraft
2. Vif
Snappy est un système de déploiement de logiciels et de gestion de packages comme AppImage ou tout autre gestionnaire de packages pour cette instance. Il est initialement conçu pour le système d'exploitation Ubuntu Touch, aujourd'hui disparu. Snappy permet aux développeurs de créer des packages logiciels à utiliser dans une variété de distributions basées sur Linux. L'intention initiale derrière la création de Snappy et le déploiement de "snaps" sur les systèmes basés sur Ubuntu est d'obtenir un format unique unifié qui pourrait être utilisé dans tout, des appareils IoT aux systèmes informatiques à part entière exécutant une version d'Ubuntu. et dans un sens plus large, Linux lui-même.[4]
Le développeur principal du projet est Canonical, la même société qui pilote le projet Ubuntu. Ubuntu avait un support natif de Snap à partir de la version 16.04 LTS avec de plus en plus de distributions le prenant en charge immédiatement ou via une configuration simple de nos jours. Si vous utilisez Arch, Debian ou openSUSE, vous trouverez facile d'installer la prise en charge du gestionnaire de paquets à l'aide de commandes simples dans le terminal, comme expliqué plus loin dans cette section. Ceci est également rendu possible en rendant les fichiers de plate-forme Snap nécessaires disponibles sur les dépôts respectifs.[5]
Snappy possède les composants importants suivants qui constituent l'ensemble du système de gestion de packages.[6]
- Snap - est le format de fichier des packages eux-mêmes. Les applications individuelles déployées à l'aide de Snappy sont appelées « Snaps ». Toute application peut être empaquetée à l'aide des outils fournis pour créer un composant logiciel enfichable destiné à s'exécuter sur un autre système exécutant Linux. Snap, similaire à AppImage, est un fichier tout compris et contient toutes les dépendances dont l'application a besoin pour s'exécuter sans les intégrer au système cible.
- Snapcraft - est l'outil qui permet aux développeurs de créer des instantanés de leurs applications. Il s'agit essentiellement d'une commande qui fait partie du système de snap ainsi que d'un framework qui vous permettra de créer vos propres snaps.
- Snapd - est le démon d'arrière-plan qui conserve tous les snaps installés sur votre système. Il s'intègre à l'environnement de bureau et gère tous les fichiers et processus liés à l'utilisation des snaps. Le démon snapd vérifie également les mises à jour normalement 4 fois par jour, sauf indication contraire.
- Snap Store - est une sorte de galerie en ligne qui permet aux développeurs de télécharger leurs clichés dans le référentiel. Snap Store est également un support de découverte d'applications pour les utilisateurs et permettra aux utilisateurs de voir et d'expérimenter la bibliothèque d'applications avant de les télécharger et de les installer.
Le composant snapd est écrit principalement en C et Golang tandis que le framework Snapcraft est construit en utilisant Python. Bien que les deux modules utilisent la licence GPLv3, il convient de noter que snapd possède un code propriétaire de Canonical pour ses opérations côté serveur, seul le côté client étant publié sous licence GPL. Il s'agit d'un point de discorde majeur avec les développeurs puisque cela implique que les développeurs signent un formulaire CLA pour participer au développement instantané.[7]
En approfondissant les détails du gestionnaire de packages Snappy, on peut noter ce qui suit :
- Comme indiqué précédemment, les instantanés sont tout compris et contiennent tous les fichiers (dépendances) nécessaires dont l'application a besoin pour s'exécuter. Par conséquent, les développeurs n’ont pas besoin de créer des clichés différents pour les différentes distributions qu’ils ciblent. Il suffit d'être attentif aux temps d'exécution si les temps d'exécution de base sont exclus du snap.
- Les packages Snappy sont destinés à prendre en charge les mises à jour transactionnelles. Une telle mise à jour transactionnelle est atomique et entièrement réversible, ce qui signifie que vous pouvez utiliser l'application pendant sa mise à jour et que si une mise à jour ne se comporte pas comme elle est censée le faire, vous pouvez l'inverser sans aucun autre effet. Le concept est également appelé programmation delta dans lequel seules les modifications apportées à l'application sont transmises sous forme de mise à jour au lieu de l'ensemble du package. Un dérivé d'Ubuntu appelé Ubuntu Core promet en fait le protocole de mise à jour rapide au système d'exploitation lui-même.[8]
- Un point clé de différence entre les snaps et AppImages réside dans la manière dont ils gèrent les différences de version. En utilisant AppImages, différentes versions de l'application auront différentes AppImages vous permettant d'utiliser simultanément 2 versions différentes ou plus de la même application en même temps. Cependant, utiliser des snaps signifie se conformer au système de mise à jour transactionnelle ou delta. Bien que cela signifie des mises à jour plus rapides, cela vous évite d'exécuter deux instances de la même application en même temps. Si vous devez utiliser l'ancienne version d'une application, vous devrez annuler ou désinstaller la nouvelle version. Snappy prend en charge une fonctionnalité appelée « installation parallèle » qui permettra aux utilisateurs d'atteindre des objectifs similaires. Cependant, elle est encore à un stade expérimental et ne peut pas être considérée comme une implémentation stable. Snappy utilise également des canaux, ce qui signifie que vous pouvez utiliser simultanément la version bêta ou la version nocturne d'une application et la version stable.[9]
- Prise en charge étendue des principales distributions Linux et des principaux développeurs, notamment Google, Mozilla, Microsoft, etc.[4]
- Snapd, l'outil d'intégration de bureau prend en charge la prise de « instantanés » de l'état actuel de tous les instantanés installés dans le système. Cela permettra aux utilisateurs de sauvegarder l'état de configuration actuel de toutes les applications installées via le gestionnaire de packages Snappy et de revenir à cet état quand ils le souhaitent. La même fonctionnalité peut également être configurée pour prendre automatiquement des instantanés à une fréquence jugée nécessaire par l'utilisateur. Des instantanés peuvent être créés à l'aide de la commande snap save dans le framework snapd.[10]
- Les snaps sont conçus pour être mis en bac à sable pendant le fonctionnement. Cela fournit une couche de sécurité et d’isolation indispensable aux utilisateurs. Les utilisateurs n'ont pas à s'inquiéter des applications basées sur Snap qui perturbent le reste des logiciels de leur ordinateur. Le sandboxing est implémenté en utilisant trois niveaux d'isolation, à savoir classique, strict et devmode. Chaque niveau d'isolation permet à l'application différents niveaux d'accès au système de fichiers et à l'ordinateur.[11]
D’un autre côté, les clichés sont largement critiqués pour être centrés sur le modus operandi de Canonical. La plupart des engagements dans le projet proviennent d'employés ou de sous-traitants de Canonical et les autres contributeurs doivent signer un formulaire de décharge (CLA). La fonctionnalité de sandboxing, très importante du point de vue de la sécurité, est défectueuse dans la mesure où le sandboxing nécessite en fait l'exécution de certains autres services de base (tels que Mir) alors que les applications exécutant le bureau X11 ne prendront pas en charge ladite isolation, ce qui rend le ledit élément de sécurité n'est pas pertinent. Les communiqués de presse douteux et autres efforts de marketing de Canonical et du référentiel d'applications « central » et fermé sont également des aspects largement critiqués de Snappy. De plus, la taille des fichiers des différents snaps est également comparativement très grande par rapport à la taille des applications des packages créés à l'aide d'AppImage.[7]
Pour plus de détails, consultez la documentation officielle de Snap.
Lecture connexe :
- Installer les packages Snap dans Arch Linux et Fedora
3. Flatpack
Comme Snap/Snappy répertorié ci-dessus, Flatpak est également un outil de déploiement de logiciels qui vise à faciliter la distribution et l'utilisation de logiciels sous Linux. Flatpak était auparavant connu sous le nom de « xdg-app » et était basé sur le concept proposé par Lennart Poettering en 2004. L'idée était de contenir les applications dans un bac à sable virtuel sécurisé permettant d'utiliser applications sans avoir besoin de privilèges root et sans compromettre la sécurité des systèmes. Alex a commencé à bricoler Klik (considéré comme une ancienne version d'AppImage) et souhaitait mieux implémenter le concept. Alexander Larsson, qui travaillait à l'époque avec Red Hat, a écrit une implémentation appelée xdg-app en 2015 qui a servi de précurseur au format Flatpak actuel.
Flatpak est officiellement sorti en 2016 avec le soutien de Red Hat, Endless Computers et Collabora. Flathub est le référentiel officiel de tous les packages d'applications Flatpak. À sa surface, Flatpak, comme les autres, est un cadre permettant de créer et de conditionner des applications indépendantes de la distribution pour Linux. Cela nécessite simplement que les développeurs se conforment à quelques directives d'environnement de bureau pour que l'application soit intégrée avec succès dans l'environnement Flatpak.
Destiné principalement aux trois implémentations de bureau populaires FreeDesktop, KDE et GNOME, le framework Flatpak lui-même est écrit en C et fonctionne sous licence LGPL. Le référentiel de maintenance est accessible via le lien GitHub ici.
Quelques fonctionnalités de Flatpak qui le distinguent sont mentionnées ci-dessous. Notez que les fonctionnalités partagées par Flatpak avec AppImage et Snappy sont omises ici.
- Intégration profonde dans les environnements de bureau Linux populaires tels que GNOME et KDE afin que les utilisateurs puissent simplement utiliser Flatpaks à l'aide d'outils de gestion de logiciels graphiques au lieu de recourir au terminal. Flatpak peut désormais être installé à partir des référentiels par défaut des principaux environnements de bureau et une fois les applications elles-mêmes configurées, elles peuvent être utilisées et fournir des fonctionnalités similaires aux applications de bureau normales.[12][13]
- Compatibilité ascendante - Les Flatpaks sont conçus dès le départ en gardant à l'esprit le noyau et les environnements d'exécution du système d'exploitation. Par conséquent, même si vous mettez à niveau ou mettez à jour votre distribution, les Flatpaks dont vous disposez devraient toujours fonctionner à moins qu'il n'y ait une mise à jour principale. Ceci est particulièrement crucial pour les personnes qui préfèrent rester sur les versions bêta ou les versions de développement de leurs distributions. Pour ces personnes, étant donné que les problèmes du système d'exploitation lui-même ne sont généralement pas résolus, l'application Flatpak fonctionnera de manière transparente sans avoir à dépendre des fichiers ou des bibliothèques du système d'exploitation pour son fonctionnement.[13]
- Sandboxing à l'aide de Bubblewrap : les snaps sont également mis en sandbox par défaut dans le sens où ils s'exécutent indépendamment du reste des applications exécutées pendant que vous utilisez votre ordinateur. Cependant, Flatpaks empêche complètement l'application d'accéder aux fichiers du système d'exploitation et aux fichiers utilisateur pendant son fonctionnement par défaut. Cela signifie essentiellement que les administrateurs système peuvent être certains que les Flatpaks installés sur leurs systèmes ne peuvent pas exploiter l'ordinateur et les fichiers qu'il contient, tandis que pour les utilisateurs finaux, cela signifie que pour accéder à quelques fonctions spécifiques ou aux données utilisateur, une autorisation root est requise. [14]
- Flatpak prend en charge la distribution décentralisée des applications de manière native, mais l'équipe derrière Flatpak maintient toujours un référentiel central en ligne d'applications/Flatpaks appelé Flathub. Les utilisateurs peuvent en fait configurer Flatpak pour utiliser plusieurs référentiels distants s'ils le jugent nécessaire. Contrairement à Snap, vous pouvez avoir plusieurs référentiels.[13]
- Accès modulable via le bac à sable. Bien que cette fonctionnalité ait un coût potentiel important pour l'intégrité du système, le framework Flatpak permet de créer des canaux via le bac à sable pour l'échange d'informations spécifiques depuis le bac à sable vers le système hôte ou vice versa. Le canal est dans ce cas appelé portail. Un inconvénient de cette fonctionnalité est abordé plus loin dans la section.[14]
L’un des aspects les plus critiqués de Flatpak est cependant la fonctionnalité sandbox elle-même. Le sandboxing est la manière dont les gestionnaires de packages tels que Snappy et Flatpak implémentent des fonctionnalités de sécurité importantes. Le sandboxing isole essentiellement l'application de tout le reste du système, permettant uniquement l'échange d'informations défini par l'utilisateur de l'intérieur du bac à sable vers l'extérieur. Le défaut du concept est que le bac à sable ne peut pas être intrinsèquement imprenable. Les données doivent éventuellement être transférées entre les deux domaines et de simples commandes Linux peuvent simplement supprimer la restriction du bac à sable, ce qui signifie que des applications malveillantes pourraient potentiellement sortir dudit bac à sable.[15]
Ceci, combiné à l’engagement pire que prévu à déployer des mises à jour de sécurité pour Flatpak, a donné lieu à de nombreuses critiques à l’égard de la prétention de l’équipe de fournir un cadre sécurisé. Le blog (nommé flatkill) lié à la fin de ce guide mentionne en fait quelques exploits qui n'ont pas été abordés par l'équipe Flatpak dès qu'ils auraient dû l'être.[15]
Pour plus de détails, je vous suggère de lire la documentation officielle de Flatpak.
Lecture connexe :
- Un guide du débutant sur Flatpak
- Comment configurer facilement les autorisations des applications Flatpak avec Flatseal
AppImage contre Snap contre Flatpak
Le tableau ci-dessous résume toutes les conclusions ci-dessus dans une comparaison concise et technique des trois cadres.
| Feature | AppImage | Snappy | Flatpak |
| Unique feature | Not an appstore or repository, its simply put a packaging format for software distribution. | Led by Canonical (Same company as Ubuntu), features central app repository and active contribution from Canonical. | Features an app store called FlatHub, however, individuals may still host packages and distribute it. |
| Target system | Desktops and Servers. | Desktops, Servers, IoT devices, Embedded devices etc. | Desktops and limited function on servers. |
| Libraries/Dependencies | Base system. Runtimes optional, Libraries and other dependencies packaged. | Base system or via Plugins or can be packaged. | GNOME, KDE, Freedesktop bundled or custom bundled. |
| Developers | Community Driven led by Simon Peter. | Corporate driven by Canonical Ltd. | Community driven by flatpak team supported by enterprise. |
| Written in | C. | Golang, C and Python. | C. |
| Initial release | 2004. | 2014. | 2015. |
| Sandboxing | Can be implemented. | 3 modes - strict, classic, and devmode with varying confinement capabilities. Runs in isolation. | Isolated but Uses system files to run applications by default. |
| Sandboxing Platform | Firejail, AppArmor, Bubblewrap. | AppArmor. | Bubblewrap. |
| App Installation | Not necessary. Will act as self mounted disc. | Installation using snapd. | Installed using flatpak client tools. |
| App Execution | Can be run after setting executing bit. | Using desktop integrated snap tools. Runs isolated with user defined resources. | Needs to be executed using flatpak command if CLI is used. |
| User Privileges | Can be run w/o root user access. | Can be run w/o root user access. | Selectively required. |
| Hosting Applications | Can be hosted anywhere by anybody. | Has to be hosted with Canonical servers which are proprietary. | Can be hosted anywhere by anybody. |
| Portable Execution from non system locations | Yes. | No. | Yes, after flatpak client is configured. |
| Central Repository | AppImageHub. | Snap Store. | Flathub. |
| Running multiple versions of the app | Possible, any number of versions simultaneously. | One version of the app in one channel. Has to be separately configured for more. | Yes. |
| Updating applications | Using CLI command AppImageUpdate or via an updater tool built into the AppImage. | Requires snapd installed. Supports delta updating, will automatically update. | Required flatpak installed. Update Using flatpak update command. |
| Package sizes on disk | Application remains archived. | Application remains archived. | Client side is uncompressed. |
Voici une longue comparaison tabulaire des fonctionnalités AppImage, Snap et Flatpak. Veuillez noter que la comparaison est effectuée du point de vue AppImage.
- https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison
Conclusion
Bien que ces trois plates-formes aient beaucoup en commun et visent à adopter une approche indépendante de la plate-forme, elles offrent différents niveaux de compétences dans quelques domaines. Bien que les Snaps puissent fonctionner sur une variété d'appareils, y compris les appareils intégrés, les AppImages et les Flatpaks sont conçus pour l'utilisateur de bureau. D'autre part, les AppImages des applications populaires avaient des tailles d'emballage et une portabilité supérieures, tandis que Flatpak brille vraiment par sa compatibilité ascendante lorsqu'il est utilisé dans un système de configuration et d'oubli.
Références :
- [1] Concepts — Documentation AppImage
- [2] Slashdot - Installation du logiciel Linux par pointer-cliquer
- [3] Historique du projet AppImage
- [4] Snapcraft - Les Snaps sont des packages Linux universels
- [5] Installation de snapd - Documentation Snap
- [6] Documentation Snap
- [7] Sur Snappy et Flatpak : comme d'habitude dans le département de propagande canonique
- [8] Les mises à jour instantanées sont de moins en moins nombreuses, voici pourquoi
- [9] Que sont les packages Linux Snap ? Pourquoi les utiliser ?
- [10] Instantanés - Documentation des instantanés
- [11] Confinement Snap - Documentation Snap
- [12] Intégration de bureau - Documentation Flatpak
- [13] Introduction à Flatpak - Documentation Flatpak
- [14] Autorisations Sandbox - Documentation Flatpak
- [15] Flatpak - un cauchemar en matière de sécurité