Il y a une vieille blague dans le monde de la technologie qui dit que chaque fois que quelqu'un essaie de créer un format qui rassemble le meilleur de tous les autres pour éviter la dispersion, il n'en ajoute qu'un nouveau à la liste. Une partie de cela est là avec les efforts pour créer un format de package qui peut fonctionner sur toutes les distributions Linux sans modification. Jusqu'ici ce siècle, nous avons déjà eu trois ans.
Snap, Flatpak et Appimage. Différences avec les formats traditionnels
La principale différence entre les formats de package natifs et les formats de package autonomes est que les anciens partagent des dépendances avec d'autres programmes installés sur le système d'exploitation. En d'autres termes, si le programme Y a besoin de la dépendance 1 et que cette dépendance a été installée par le programme X qui en a également besoin, cette dépendance ne sera pas réinstallée.
Les programmes conditionnés dans des formats séparés incluent toutes les dépendances dont ils ont besoin pour fonctionner. En d'autres termes, la dépendance 1 sera installée chaque fois qu'un programme qui en a besoin est installé.
La deuxième différence est que les formats de paquet traditionnels doivent être construits avec les spécifications de chaque distribution.. C'est pourquoi bien qu'Ubuntu soit une distribution dérivée de Debian, les différences sont suffisamment importantes pour que les référentiels du premier ne puissent pas être utilisés dans le second.
La troisième différence est que toute modification d'une dépendance sur des packages traditionnels peut affecter le fonctionnement de tous les autres qui en ont besoin. En revanche, les modifications apportées à un programme dans un format indépendant n'affecteront pas le reste du système.
En fonction des particularités de chaque distribution, il est possible d'installer les applications dans des formats indépendants à partir d'un gestionnaire de paquets et d'automatiser leur mise à jour avec le gestionnaire en charge.
Dans Ubuntu, le Centre logiciel vous permet d'installer les deux programmes dans des formats traditionnels tels que Snap, en privilégiant ce dernier. Bien qu'il existe un plugin qui autorise le Centre logiciel GNOME (dont Ubuntu est dérivé), il ne fonctionne pas avec cette distribution.
Dans le cas d'Ubuntu Studio, il est possible d'activer l'option d'utiliser les packages Snap tandis que KDE Neon et Manjaro peuvent fonctionner avec les deux formats.
Casser
C'est le plus récent des formats indépendants depuis le début de son développement en 2014. Il est destiné non seulement à être utilisé dans les distributions Linux de bureau, mais également pour l'Internet des objets, les appareils mobiles et les serveurs. ÀBien qu'il soit possible de créer des magasins d'applications séparés, il n'y en a actuellement qu'un seul exploité par Canonical, Snapcraft.
Bien que Snapcraft propose un assortiment des applications open source les plus populaires, Sa force réside dans les programmes développés par des développeurs de logiciels privés et des fournisseurs de services cloud.
Flatpak
Bien que Flatpak ait été officiellement lancé en 2015, il s'agit de la continuation d'un autre projet de format universel connu sous le nom de xdg-app. Ce projet est né avec l'objectif de être en mesure d'exécuter des applications dans un bac à sable virtuel sécurisé, qui ne nécessite pas de privilèges root ou ne constitue pas une menace pour la sécurité du système.
Flatpak se concentre sur les distributions de bureau utilise également le concept de magasin d'applications étant Flathub les plus connus.
Le point fort de Flathub est que il contient généralement les versions les plus récentes des principales applications open source.
Appimage
AppImage est le plus ancien des formats de packages autonomes, car il a été publié pour la première fois en 2004.
C'était le premier format à suivre le paradigme de "One application-one file". Cela signifie que chaque fois que nous téléchargeons un fichier Appimage, nous téléchargeons l'application et tout ce dont elle a besoin pour fonctionner. Si nous voulons utiliser l'application, il suffit de lui donner les autorisations d'exécution et de double-cliquer sur l'icône qui l'identifie.
Appimage n'utilise pas le système de l'App Store, mais, foin une page web dans lequel nous pouvons trouver une liste de tous les titres disponibles.
Pour mettre à jour l'Appimage, nous pouvons utiliser cet outil.
Il me manque qu'il n'y ait aucune mention de l'extrême lenteur croissante du snap lors de l'installation d'applications car il a besoin d'une unité virtuelle pour chacune.
Il me manque qu'il n'y ait aucune mention de l'extrême lenteur croissante du snap lors de l'installation d'applications car il a besoin d'une unité virtuelle pour chacune.
Merci pour ton commentaire. Je garderai ça à l'esprit.
Personnellement, je pense que les problèmes des packages logiciels indépendants ne sont rien de plus que le reflet d'un conflit beaucoup plus profond, qui a à voir avec le degré de conformité aux normes LSB et FSH par les différentes distributions.
L'un des principes fondamentaux de l'empaquetage est la mise en œuvre de bibliothèques standard, en conservant à la fois l'emplacement et l'emplacement du logiciel, ainsi que les fichiers de configuration. Évitant ainsi les conflits de bibliothèques. Ce qui est courant dans d'autres systèmes d'exploitation, et qui malheureusement, en ne respectant pas les normes, finit par rendre difficile la maintenance et la mise à jour du logiciel, sans parler de la migration d'un logiciel d'une distribution à une autre. La mauvaise pratique des compilations manuelles, effectuées plusieurs fois à partir d'un howto, sans analyser le respect des normes dans son implémentation, finit par être un énorme casse-tête pour les administrateurs système. Surtout quand quelqu'un doit prendre en charge un serveur de production installé par un autre administrateur précédent.
L'emballage indépendant, d'une manière ou d'une autre, finit par contribuer à cette philosophie, promouvant plus que l'indépendance, la dépendance à un format ou à une entreprise en particulier. Faire de la migration de plate-forme une tâche presque impossible à plusieurs reprises. Penser davantage à court terme qu'à long terme. Une situation qui peut être observée par tout administrateur sérieux qui a plus de 15 ans d'expérience. Et je dis ce chiffre exprès, car dans cette période il aura vu passer suffisamment de distributions, pour se rendre compte que tôt ou tard, des projets ou des services seront forcés pour une raison ou une autre à migrer de la plateforme. Situation qui entre rarement dans les processus d'évaluation lors de la mise en œuvre d'un projet. Là où les plus faciles à migrer sont précisément les plates-formes qui respectent le mieux les normes susmentionnées. Étant ces packages indépendants, ceux qui sont les plus éloignés de ces normes.
Contribution intéressante, il ne m'était pas venu à l'esprit d'y penser
L'outil de mise à jour des fichiers AppImage est pratiquement inutile. Sur 7 fichiers AppImage que j'ai essayés (Inkscape, Olive, KSnip, MuseScore, OpenShot entre autres), il n'a essayé de travailler qu'avec un seul, se terminant par "Aucune signature de vérification n'existe" et par conséquent, ne le met pas à jour non plus. En d'autres termes, il n'est utilisé pour rien, vous pouvez supprimer la référence. De plus, il n'a pas été mis à jour depuis des mois.
Merci d'avoir commenté