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, [email protected] https://www.palabritudes.net/ Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !
