Si vous suivez les actualités Linux, vous avez probablement déjà entendu parler du débat sur les packages snap. Développé par Canonical comme un moyen plus rapide et plus facile d'installer les dernières versions des logiciels sur les systèmes Ubuntu, le logiciel a fini par lancer un débat enflammé dans la plus grande communauté Linux. Pour les utilisateurs plus occasionnels, le composant logiciel enfichable n'est qu'un moyen d'obtenir le logiciel qu'ils souhaitent le plus rapidement possible. Mais pour les utilisateurs concernés par l'idéologie des logiciels libres et open source, il s'agit d'une étape dangereuse vers les types de «jardins clos» propriétaires qui les ont peut-être conduits à Linux en premier lieu.

Peut-être que l'adversaire le plus vocal de snap, et certainement celui qui a le plus retenu l'attention des médias, est Linux Mint. Dans un article du 1er juin sur le blog officiel de la distribution, le fondateur de Mint, Clement Lefebvre, a clairement indiqué que le spin-off d'Ubuntu n'approuve pas le nouveau format de package et ne l'inclurait pas dans les installations de base. De plus, il a annoncé que Mint 20 empêcherait activement les utilisateurs d'installer le framework snap via le gestionnaire de packages. Il peut toujours être installé manuellement, mais cette opération est considérée comme un moyen d’empêcher son ajout au système sans le consentement explicite de l’utilisateur.

La version courte de la plainte de Clement est que le pack snap s’installe à partir d’une source propriétaire spécifique à Canonical. Si vous souhaitez distribuer des snaps, vous devez créer un compte chez Canonical et y héberger. Alors que le logiciel sous-jacent est toujours open source, le snap packager rompt avec la longue tradition selon laquelle la distribution du logiciel est également ouverte et gratuite. Cela rend sans aucun doute l'installation simple pour les utilisateurs naïfs et plus facile à entretenir pour les mainteneurs canoniques, mais cela enlève également la liberté de choix et la diversité des sources de packages.

Un package pour les gouverner tous

Pour comprendre la situation, nous devrions probablement prendre du recul et regarder ce que sont réellement les clichés. En termes simples, il s'agit d'un progiciel conteneurisé qui inclut les bibliothèques que le programme donné nécessite pour fonctionner. L'idée est que les développeurs pourraient publier un seul composant logiciel enfichable qui fonctionnerait essentiellement sur n'importe quel système Linux moderne, plutôt que d'avoir à créer des packages spécifiques à la distribution. En théorie, cela permet d'économiser du temps et des efforts de la part du développeur et garantit que même les utilisateurs de distributions de niche supplémentaires peuvent accéder au logiciel qu'ils souhaitent.

Naturellement, la distribution de logiciels comme celui-ci présente des inconvénients. D'une part, un package instantané sera toujours plus volumineux qu'un package traditionnel pour le même programme, car toutes les dépendances doivent être fournies avec. Étant donné que de nombreux programmes auront naturellement les mêmes dépendances, cela signifie qu'un système avec de nombreux snaps installés gaspillera inutilement de l'espace de stockage sur des données redondantes. Bien que même lorsque les systèmes d'entrée de gamme incluent désormais des disques durs de téraoctets, ce n'est peut-être pas aussi préoccupant que cela aurait été les années passées.

Packages d'accrochage montés sur une installation par défaut d'Ubuntu 20.04.

Les packages d'instantanés ont également tendance à être plus lents à s'exécuter, en partie parce qu'ils sont en fait des images de système de fichiers compressées qui doivent être montées avant de pouvoir être exécutées. Certains utilisateurs trouvent cet élément particulièrement ennuyeux du point de vue de la maintenance du système, car chaque package d'instantanés que vous installez apparaîtra en fait comme un système de fichiers monté.

En fait, il a été question d'ajouter un indicateur spécial aux packages d'accrochage montés afin que des outils courants comme mount ou lsblk ne les montrera pas, mais cela mène évidemment à ses propres problèmes. Après tout, il est utile de pouvoir déterminer la quantité d’espace disque qu’ils occupent.

Par exemple, examinons la façon dont le package d'accrochage d'un outil commun se compare à son installation directe:

Comme vous pouvez le voir, la différence est substantielle. Si nous téléchargeons youtube-dl directement à partir du site Web du développeur, le script ne prend que 1,7 Mo sur le disque. Mais le package instantané du même programme pèse 91 Mo. Il est clair que ce problème pourrait être aggravé à mesure que davantage d’accrochages sont installés.

Cela étant dit, il existe sans aucun doute une demande pour ce type de package Linux «universel». Assez qu'il y ait au moins deux autres approches concurrentes qui fonctionnent selon des principes similaires, Flatpak et AppImage.

La débâcle du chrome

Du point de vue des ressources système, les packages conteneurisés ne sont clairement pas idéaux. D'un autre côté, beaucoup seraient plus qu'heureux de prendre le coup sur les performances si cela signifiait qu'ils avaient accès aux dernières versions de programmes populaires sans avoir à attendre qu'ils arrivent dans le référentiel de packages natifs de leur distribution. Les utilisateurs devraient être libres de décider par eux-mêmes de l'itinéraire à suivre en fonction de leurs besoins personnels.

C'est ce qui rend la gestion par Canonical du package Chromium dans Ubuntu 20.04 si troublante. Examinons de près ce qui se passe lorsque vous essayez de l'installer via apt:

Bien que nous ayons demandé au système d'installer le package natif, ce que nous recevons réellement est le composant logiciel enfichable. L'utilisateur n'a aucun choix, aucun avertissement. S'ils ne faisaient pas assez attention, ils ne se rendraient même pas compte de ce qui s'est passé. Au risque de paraître trop dramatique, c'est de la subversion.

Certes, il existe des raisons valables pour lesquelles Canonical souhaite distribuer Chromium en un clin d'œil. Plutôt que de créer des versions pour chaque version prise en charge d'Ubuntu, ils peuvent pousser un seul composant logiciel enfichable qui fonctionnera sur chacun d'eux. Cela est particulièrement vrai pour les anciennes versions d'Ubuntu LTS (Long Term Support), qui pourraient sinon être bloquées sur une ancienne version du navigateur en raison de bibliothèques système obsolètes.

En utilisant cette méthode d'installation «furtive» pour le composant logiciel enfichable Chromium, ils peuvent s'assurer que le processus est aussi rationalisé et indolore que possible pour leurs utilisateurs. En effet, la majorité ne remarquerait probablement même pas que le changement s'est produit.

Mais pour ceux qui l'ont remarqué, c'est une affaire énorme. De nombreux utilisateurs ont quitté les systèmes d'exploitation propriétaires spécifiquement pour échapper à ce type de comportement. Ces personnes veulent être l'arbitre de leur propre ordinateur et ne prennent pas gentiment les décisions importantes qui sont prises en leur nom sans même l'avertir qu'elles se produisent. Ce sont les utilisateurs que Clement Lefebvre avait en tête lorsqu'il a promis que les futures versions de Mint n'installeraient jamais de packages de snap sans accord préalable.

Snap to the Future

Alors que Canonical n'est pas étranger à revenir sur des décisions impopulaires, les packages snap sont presque certainement là pour rester. Les avantages logistiques des packages conteneurisés sont tout simplement trop importants lorsque toute votre entreprise est structurée autour de la prise en charge de plusieurs versions d'une distribution Linux. Inversement, les utilisateurs qui ont de forts sentiments sur les snaps seront inévitablement une petite minorité (si vocale). Les snapshots conçus par Canonical sont la solution aux défis uniques de maintenir une distribution énorme et à multiples facettes comme Ubuntu, et cela fonctionne exactement comme prévu.

Cela dit, il semble peu probable que les packages snap soient adoptés par la plus grande communauté Linux. Actuellement, le back-end du référentiel est en fait propriétaire. Bien que Canonical permette aux entreprises de créer des versions «de marque» du Snap Store, il ne s'agit que d'un changement cosmétique et ne vous permet pas d'exécuter votre propre serveur. Ainsi, même si une autre distribution telle que Mint décidait d'adopter le format de package instantané, ils devraient s'appuyer sur Canonical pour fournir l'infrastructure de distribution des packages à leurs utilisateurs. Ce seul point d'échec est forcément un point de discorde pour l'adoption en dehors d'Ubuntu lui-même.

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici