Gestionnaires de paquets fournir un moyen d'empaqueter, de distribuer, d'installer et de maintenir des applications dans un système d'exploitation. Avec les applications modernes de bureau, de serveur et d'IdO 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 conditionnement spécifiques à la plate-forme vers des méthodes indépendantes de la plate-forme. Cet article explore 3 de ces outils, à savoir AppImage , Cliquer 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 un 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, l'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]
C'est un format pour créer un logiciel portable pour Linux sans que l'utilisateur n'ait à installer ladite application. Le format permet aux développeurs originaux du logiciel (développeurs en amont) de créer une version indépendante de la plate-forme et de la distribution (également appelée binaire indépendant de la distribution) de leur application qui fonctionnera essentiellement sur n'importe quelle version de Linux.
AppImage existe depuis longtemps. Cliquez , 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é le stade 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 de nouveau été renommé 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 au même depuis 2018.[2][3]
Écrit principalement en C et portant la licence MIT depuis 2013, AppImage est actuellement développé par le projet AppImage . C'est un moyen très pratique d'utiliser des applications, comme en témoignent les fonctionnalités suivantes :
- AppImages peut s'exécuter 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. C'est une pratique courante dans le monde du logiciel, car si quelque chose est déjà fait, il est inutile de le refaire si vous pouvez sélectionner et choisir les parties à utiliser. Le problème est que de nombreuses distributions Linux peuvent ne pas disposer de tous les fichiers nécessaires à l'exécution d'une application particulière, 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 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 nécessiter de 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 fichier qui répondra à leurs besoins pour utiliser l'application.
- Aucune exigence d'accès root . 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 ou privilèges de super utilisateur ne peuvent pas installer les applications dont elles ont besoin à leur guise. La pratique est courante dans un cadre public (tel que des ordinateurs de bibliothèque ou d'université ou sur des systèmes d'entreprise). Le fichier AppImage n'oblige pas les utilisateurs à "installer" 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 rencontrés par 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 des applications avec toutes leurs fonctionnalités sans avoir besoin de modifier ou même d'accéder à la plupart des fichiers système. Cela signifie que quoi que fassent les applications, la configuration du système d'exploitation principal 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 en tant qu'AppImage différente. Ainsi, les utilisateurs peuvent, si besoin, 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 d'un point de vue d'utilisateur final pour remarquer des différences.
- Emportez vos applications où que vous soyez. 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 installation ni même se soucier de la distribution utilisée par le système. Par conséquent, si vous avez un ensemble d'applications que vous utilisez régulièrement, 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, le 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 maintenant pris en charge nativement par une variété de distributions telles que Ubuntu, Debian, openSUSE, CentOS, Fedora, etc. et d'autres peuvent le configurer selon leurs besoins. AppImages peut également être exécuté sur des serveurs avec des fonctionnalités limitées via les outils CLI inclus.
Pour en savoir plus sur AppImages, accédez à la documentation AppImage officielle page.
Suggestion de lecture :
- Intégrer AppImages au menu de l'application à l'aide d'AppImageLauncher
- Rechercher des applications Linux sur les plates-formes AppImage, Flathub et Snapcraft
2. Rapide
Vif 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 conçu à l'origine pour Ubuntu Touch, aujourd'hui disparu. Système opérateur. 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 derrière le projet est Canonical , la même entreprise 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 prêt à l'emploi ou via une configuration simple ces jours-ci. Si vous utilisez Arch ou 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. Cela est également rendu possible en mettant à disposition les fichiers de plate-forme snap nécessaires sur les dépôts respectifs.[5]
Snappy possède les composants importants suivants qui constituent l'ensemble du système de gestionnaire de packages.[6]
- Cliquer – 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 supposer faire partie du système cible.
- Snapcraft – est l'outil qui permet aux développeurs de faire des clichés de leurs applications. Il s'agit essentiellement d'une commande qui fait partie du système de snap ainsi que d'un cadre qui vous permettra de créer vos propres snaps.
- Snapd – est le démon d'arrière-plan qui gère 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.
- Magasin Snap – 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 alors 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 la licence GPL. Il s'agit d'un point de discorde majeur avec les développeurs, car 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 paquets Snappy, on peut noter ce qui suit :
- Les Snaps, comme indiqué précédemment, sont complets et contiennent tous les fichiers nécessaires (dépendances) 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. Tenir compte des runtimes est tout ce qui est nécessaire si les runtimes de base sont exclus du composant logiciel enfichable.
- 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 le devrait, 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]
- L'un des principaux points de différence entre les snaps et AppImages est la manière dont ils gèrent les différences de version. L'utilisation d'AppImages différentes versions de l'application aura 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, il est encore au stade expérimental et ne peut pas être considéré comme une implémentation stable. Snappy utilise également des canaux, ce qui signifie que vous pouvez utiliser la version bêta ou la version nocturne d'une application et la version stable en même temps.[9]
- Prise en charge étendue des principales distributions Linux et des principaux développeurs, dont Google, Mozilla, Microsoft, etc.[4]
- Snapd, l'outil d'intégration de bureau, prend en charge la prise d'"instantanés" de l'état actuel de tous les snaps 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. Les instantanés peuvent être créés à l'aide de la commande d'enregistrement instantané 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 les snaps qui interfèrent avec le reste du logiciel sur leur ordinateur. Le sandboxing est mis en œuvre à l'aide de 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 envers le projet sont effectués par des employés ou des sous-traitants de Canonical et les autres contributeurs sont tenus de signer un formulaire de décharge (CLA). La fonctionnalité de sandboxing, très importante en effet du point de vue de la sécurité, est défectueuse dans la mesure où le sandboxing nécessite en fait certains autres services de base pour s'exécuter (tels que Mir) tandis 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 d'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, les tailles de fichier des différents snaps sont également relativement très volumineuses par rapport aux tailles d'application des packages créés à l'aide d'AppImage.[7]
Pour plus de détails, consultez la documentation officielle de Snap .
Lire connexe :
- Installez les packages Snap dans Arch Linux et Fedora
3. Trousse plate
Comme le Snap/Snappy listé 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 des applications sans avoir besoin de privilèges root et sans compromettre la sécurité des systèmes. Alex a commencé à bricoler avec Klik (considéré comme une ancienne version d'AppImage) et voulait mieux mettre en œuvre le concept. Alexandre Larsson qui travaillait à l'époque avec Red Hat a écrit une implémentation appelée xdg-app en 2015 qui a agi comme un précurseur du 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'application Flatpak. À sa surface, Flatpak, comme les autres, est un cadre pour créer et empaqueter 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.
Ciblé principalement sur les trois implémentations de bureau populaires FreeDesktop , KDE , et GNOME , le framework Flatpak lui-même est écrit en C et fonctionne sur une LGPL Licence. Le référentiel de maintenance est accessible via le lien GitHub ici .
Certaines 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 approfondie 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 maintenant ê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 construits à partir de zéro en gardant à l'esprit le noyau central et les runtimes des systèmes d'exploitation. Par conséquent, même si vous mettez à niveau ou mettez à jour votre distribution, les Flatpaks que vous avez devraient toujours fonctionner, sauf s'il y a une mise à jour principale. Ceci est particulièrement crucial pour les personnes qui préfèrent rester sur des versions bêta ou des versions de développement de leurs distributions. Pour ces personnes, étant donné que les défauts 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]
- Sandbox avec Bubblewrap - les snaps sont également par défaut en bac à sable en ce sens qu'ils s'exécutent indépendamment du reste des applications en cours d'exécution 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 à des 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 en ligne central d'applications/Flatpaks appelé Flathub . Les utilisateurs peuvent en fait configurer Flatpak pour utiliser plusieurs référentiels distants comme ils le jugent nécessaire. Contrairement à snap, vous pouvez avoir plusieurs référentiels.[13]
- Accès modulaire via le bac à sable. Bien que cette capacité ait un coût potentiel élevé pour l'intégrité du système, le cadre Flatpak permet de créer des canaux via le bac à sable pour l'échange d'informations spécifiques de l'intérieur du 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é de bac à sable elle-même. Le sandboxing est la façon 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 un échange d'informations défini par l'utilisateur de l'intérieur du sandbox vers l'extérieur. Le défaut du concept étant 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 se débarrasser de 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 de déployer des mises à jour de sécurité pour Flatpak, a donné lieu à de nombreuses critiques à l'égard de la haute revendication 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é corrigé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 .
Lire connexe :
- Un guide du débutant pour 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.
| Fonctionnalité | AppImage | Vif | Flatpak |
| Caractéristique unique | Pas un appstore ou un référentiel, c'est simplement un format d'emballage pour la distribution de logiciels. | Dirigé par Canonical (même entreprise qu'Ubuntu), propose un référentiel d'applications central et une contribution active de Canonical. | Dispose d'un magasin d'applications appelé FlatHub, cependant, les individus peuvent toujours héberger des packages et les distribuer. |
| Système cible | Postes de travail et serveurs. | Ordinateurs, serveurs, appareils IoT, appareils embarqués, etc. | Desktops et fonction limitée sur les serveurs. |
| Bibliothèques/Dépendances | Système de base. Runtimes facultatifs, bibliothèques et autres dépendances packagées. | Système de base ou via des plugins ou peut être empaqueté. | GNOME, KDE, Freedesktop groupés ou groupés personnalisés. |
| Développeurs | Community Driven dirigé par Simon Peter. | Entreprise dirigée par Canonical Ltd. | Communauté pilotée par l'équipe flatpak soutenue par l'entreprise. |
| Écrit | C. | Golang, C et Python. | C. |
| Version initiale | 2004. | 2014. | 2015. |
| Sandboxing | Peut être implémenté. | 3 modes - strict, classique et devmode avec différentes capacités de confinement. Fonctionne de manière isolée. | Isolé mais utilise les fichiers système pour exécuter les applications par défaut. |
| Plateforme de sandboxing | Firejail, AppArmor, Bubblewrap. | AppArmor. | Papier à bulles. |
| Installation de l'application | Pas nécessaire. Agira comme un disque auto-monté. | Installation avec snapd. | Installé à l'aide des outils client flatpak. |
| Exécution de l'application | Peut être exécuté après avoir défini le bit d'exécution. | Utilisation des outils d'accrochage intégrés au bureau. Fonctionne isolément avec des ressources définies par l'utilisateur. | Doit être exécuté à l'aide de la commande flatpak si la CLI est utilisée. |
| Privilèges utilisateur | Peut être exécuté sans accès utilisateur root. | Peut être exécuté sans accès utilisateur root. | Sélectivement requis. |
| Hébergement d'applications | Peut être hébergé n'importe où par n'importe qui. | Doit être hébergé sur des serveurs Canonical propriétaires. | Peut être hébergé n'importe où par n'importe qui. |
| Exécution portable à partir d'emplacements non système | Oui. | Non. | Oui, après la configuration du client flatpak. |
| Dépôt central | AppImageHub. | Magasin Snap. | Flathub. |
| Exécuter plusieurs versions de l'application | Possible, n'importe quel nombre de versions simultanément. | Une version de l'application dans un canal. Doit être configuré séparément pour plus. | Oui. |
| Mise à jour des applications | À l'aide de la commande CLI AppImageUpdate ou via un outil de mise à jour intégré à AppImage. | Nécessite l'installation de snapd. Prend en charge la mise à jour delta, se mettra à jour automatiquement. | Flatpak requis installé. Mettre à jour à l'aide de la commande de mise à jour flatpak. |
| Tailles des packages sur disque | L'application reste archivée. | L'application reste archivée. | Le côté client n'est pas compressé. |
Voici une longue comparaison tabulaire des fonctionnalités AppImage, Snap et Flatpak. Veuillez noter que la comparaison est effectuée du point de vue d'AppImage.
- https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison
Conclusion
Bien que ces trois plates-formes aient beaucoup en commun les unes avec les autres et visent à être indépendantes de la plate-forme dans leur approche, elles offrent différents niveaux de compétences dans quelques domaines. Alors que Snaps peut s'exécuter sur une variété d'appareils, y compris ceux intégrés, AppImages et Flatpaks sont conçus pour l'utilisateur de bureau. AppImages d'applications populaires, d'autre part, 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 "set it and forget it".
Références :
- [1] Concepts – Documentation AppImage
- [2] Slashdot – Installation de logiciels Linux point-and-klik
- [3] Historique du projet AppImage
- [4] Snapcraft :les Snaps sont des packages Linux universels
- [5] Installation de snapd – Documentation Snap
- [6] Documentation instantanée
- [7] Sur Snappy et Flatpak :les affaires comme d'habitude dans le département de propagande canonique
- [8] Les mises à jour instantanées sont de plus en plus petites, voici pourquoi
- [9] Que sont les packages Linux Snap ? Pourquoi les utiliser ?
- [10] Instantanés – Documentation relative aux instantanés
- [11] Confinement Snap - Documentation Snap
- [12] Intégration au bureau – Documentation Flatpak
- [13] Présentation de Flatpak – Documentation Flatpak
- [14] Autorisations Sandbox – Documentation Flatpak
- [15] Flatpak :un cauchemar pour la sécurité