Bonjour,
Alex PADOLY a écrit :
Quelle est l'utilité de SNAP?
Je trouve que Debian gère très bien les paquets.
Grosso modo, le déploiement d'une application peut s'envisager de deux
manières bien différentes :
* Déploiement intégré (au système hôte) : l'application a été conçue et
compilée pour fonctionner avec les bibliothèques disponibles
nativement sur le système hôte. Dans ce cas, le « paquet » de
l'application ne fournit que l'application et les ressources externes
associées (documentation, fichiers de configuration, icônes et autres
ressources multimédia spécifiques).
* Déploiement autoportant : l'objectif est de rendre le plus possible
l'application indépendante du système hôte, de s'approcher d'un
fonctionnement en vase clos. En plus des ressources précédemment
évoquées, le paquet fournit alors l'ensemble des bibliothèques dont
dépend l'application, dans la version prévue par le développeur de
l'application.
En schématisant un peu, la première approche est l'approche historique
des systèmes Unix, la seconde, est celle de macOS et, dans une moindre
mesure, de MS-Windows. C'est aussi celle des conteneurs plus ou moins
cloisonnés que sont FlatPak, AppImage, Snap et Docker.
Chacune des approches a des avantages et inconvénients, différents (ou
plus ou moins prégnants) selon qu'on est développeur de l'application,
administrateur du système ou utilisateur de l'application.
Pour l'administrateur :
* Le déploiement intégré facilite la maintenance du système et réduit
les ressources requises sur disque et en RAM. En mettant à jour la
bibliothèque lorsqu'un bogue ou une faille de sécurité est identifié,
on patche d'un coup toutes les applications qui l'utilisent. C'est
idéal du point de vue de la sécurité. Une seule copie de la
bibliothèque est stockée sur le disque et une seule copie est chargée
en mémoire. Le déploiement intégré est donc moins couteux en
ressources matérielles, mais les ressources disponibles augmentant
avec le temps, cet argument porte de moins en moins (sauf, sans doute,
dans l'embarqué). Par contre, si l'ABI de la bibliothèque change,
toutes les applications qui l'utilisent doivent être recompilées et un
nouveau paquet doit être publié pour chacune d'entre elles. La
propagation des corrections peut de ce fait être ralentie.
* Le déploiement autoportant fait que la mise à jour du système est sans
effet sur l'application. Celle-ci, ou plutôt son paquet, doit faire
l'objet d'une mise à jour spécifique. La mise à disposition d'une
nouvelle version d'un paquet dépend de la réactivité des mainteneurs
de l'application. La sécurisation du système est donc progressive.
Pour l'administrateur et du point de vue de la sécurité, c'est un
cauchemar. Ce problème est cependant contrebalancé par le
cloisonnement qu'opèrent les conteneurs. S'il est strict et propre,
l'application n'a qu'un accès limité au système. Les failles de
sécurité dont elle souffre ont donc un pouvoir de nuisance limité.
Quelle stratégie l'emporte auprès des administrateurs ? Pour l'instant,
aucune, même si on sent bien que le vent change et que le déploiement
autoportant est en train de gagner des adeptes (pas grâce à Snap,
FlatPak ou AppImage, mais grâce aux véritables conteneurs que sont
Docker et consors).
Pour le développeur :
* Le déploiement intégré est un fardeau qui lui prend une énergie
considérable et l'empêche de se concentrer sur des fonctions utiles et
des tâches plus motivantes. En effet, le développeur n'est pas libre
d'utiliser la version qui lui plait d'une bibliothèque, mais celle
disponible sur l'environnement cible. Lorsque les environnements
cibles se multiplient, les versions aussi. Et ce n'est pas qu'un
problème de plateforme GNU/Linux ou MS-Windows ou macOS. La version de
la bibliothèque mise à disposition diffère selon la distribution
(Debian, Mint, Alma, Manjaro, OpenSuse…), selon la version de cette
distribution (Debian Bullseye, Bookworm ou Trixie), selon que le
système est mis à jour six fois par jour ou une fois par semestre,
selon qu'il est déployé sur une plateforme Intel ou ARM. L'API, les
fonctions offertes, les performances, les bogues ne sont donc pas les
mêmes d'un environnement à l'autre. Et je ne parle même pas des
options de compilation choisies par les mainteneurs. En outre, une
application dépend en général de plusieurs bibliothèques, au point
qu'il devient « impossible » de trouver un socle commun à tous les
environnements.
Le développeur doit s'interdire d'utiliser les versions trop récentes
des bibliothèques, dont les fonctions qui lui font de l'œil et
pourraient résoudre efficacement ses problèmes. C'est frustrant.
Lorsqu'un utilisateur lui signale un bogue, le développeur doit
précisément caractériser son environnement, puis réussir à reproduire
cet environnement s'il ne reproduit pas le bogue dans son
environnement de travail habituel. C'est usant. J'ai eu de nombreux
témoignages directs à ce sujet et je connais plus d'un projet qui
a cessé de supporter certains environnements pour réduire la charge
sur les mainteneurs.
* Il ne faut donc pas s'étonner que de plus en plus de projets décident
de s'émanciper, qu'ils créent dans un conteneur un environnement
parfaitement maitrisé par eux et autoportant, et qu'ils déclarent ne
supporter que les déploiements effectués via ce conteneur (c'est par
exemple le cas de Discourse). Le déploiement autoportant engendre
cependant de nouvelles responsabilités pour les développeurs de
l'application. Puisqu'ils ont créé l'environnement, ils en deviennent
responsables. Il leur incombe d'assurer la veille technologique et
sécuritaire sur les composants qu'ils utilisent, et de fournir dans
les meilleurs délais des versions corrigeant les problèmes.
Un déploiement qui s'abstrait des contraintes du système, c'est aussi
ce que recherchent les développeurs Python avec leurs « virtual
envs », mais c'est aussi ce qu'apprécient les développeurs Rust et Go.
Et là, on ne parle même pas de Snap ou de Docker.
Je pense que de plus en plus de développeurs parmi ceux qui veulent que
leur application fonctionne « partout » vont succomber au charme des
déploiements autoportants.
Pour l'utilisateur :
* Il est bien souvent administrateur de son propre poste ; ce que j'ai
dit pour l'administrateur vaut en partie pour l'utilisateur.
* Mais de manière générale, un simple utilisateur est cependant moins
sensible aux questions de sécurité. Son besoin n'est pas d'assurer
l'intégrité d'un système, mais la production d'un document, la
réalisation d'une tâche, au moyen d'un ou plusieurs logiciels. Cet
utilisateur peut être frustré de ne disposer que d'une version
antédiluvienne de son outil préféré dans les dépôts natifs de sa
distribution. S'il apprend qu'une version bien plus récente de l'outil
est disponible dans un dépôt tiers ou via un paquet Snap ou AppImage,
il hésitera rarement à s'approvisionner par ce biais.
L'utilisateur n'a guère conscience des enjeux et il est seulement
intéressé par la satisfaction de ses besoins, ce qui se comprend (j'ai
moi-même ce comportement dans beaucoup d'autres domaines, par exemple,
avec ma voiture : la seule chose qui m'intéresse est qu'elle fonctionne
et m'emmène à bon port, je prends rendez-vous au garage pour l'entretien
et je paie, le reste, c'est le problème du garagiste, pas le mien).
Au final, quoi qu'on en pense, je suis persuadé que l'approche
déploiement autoportant / conteneur va finir par l'emporter et qu'un
jour où l'autre, notre système d'exploitation se résumera à un socle
minimaliste faisant tourner peu ou prou tous nos outils dans autant de
conteneurs à la porosité minimale. Il me semble que c'est la voie que
proposent déjà les distributions Ubuntu Core et Zorin OS.
Sébastien
--
Sébastien Dinot,
sebastien.dinot@free.frhttps://www.palabritudes.net/Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !