Snap de Ubuntu, bonne ou mauvaise nouvelle ?
Ubuntu vient d'annoncer que sa prochaine distribution, la 16.04 (à paraître le 21 avril normalement), intégrera la fonctionnalité « Snap ». Et à vrai dire je suis quelque peu mitigé quant à savoir s'il s'agit d'une bonne ou une mauvaise nouvelle…
Qu'est-ce donc ?
Il s'agit d'un nouveau format de packaging des applications, une sorte alternative aux traditionnels fichier .deb si vous voulez. Sauf que bien sûr ça ne fonctionne pas exactement pareil, ça apporte son lot de changements avec leurs avantages, mais éventuellement quelques inconvénients également.
Avantages
Parmi les avantages, on retrouve donc le fait que des applications dans leurs versions les plus récentes pourront être installées, ceci indépendamment de la version du système d'exploitation utilisé. Par exemple, on peut imaginer que si Libre Office package sa suite bureautique au format Snap, la dernière version pourra être installée sur Ubuntu 16.04, ceci même dans plus de 4 ans.
Autre avantage, grâce à l'intégration des bibliothèques tierces nécessaires directement dans le package, les applications distribuée via le format Snap fonctionneront dans environnement isolé (façon bac-à-sable). Ce qui, théoriquement, devrait apporter davantage de sécurité.
Aussi, les mises à jour des application Snap seront « transactionnelles » (je ne sais pas s'il existe une traduction plus appropriée au terme transactional update…). Si j'ai bien compris, ça signifie qu'au lieu de devoir télécharger l'intégralité du paquet, l'outil de mise à jour fait le delta avec la nouvelle version et ne télécharge que ce qui a changé. Il semblerait également que grâce à ce fonctionnement le retour en arrière (rollback) en cas de pépin soit facilité.
Inconvénients
Sur le papier tout ça a l'air bien beau, mais ça me laisse tout de même un peu perplexe… Car qui dit intégration des bibliothèques tierces directement au sein des applications par les développeurs des dîtes applications, dit que ce sont ces mêmes développeurs qui devront mettre à jour les bibliothèques en plus de leurs applications.
Vous le voyez venir le problème ? Non ? Prenons l'exemple d'une application client pour le réseau social Twitter. Celle devrait donc intégrer la bibliothèque OpenSSL (ou GnuTLS) afin de pouvoir communiquer de manière chiffrée avec les serveurs de Twitter. Il reviendrait alors au développeur de mettre à jour cette bibliothèque en cas de faille dans celle-ci.
Si le développeur est actif et fait bien son travail, aucun problème. Mais s'il est un peu négligent, ou un peu incompétent, ou alors comme beaucoup de développeurs de logiciels libres ne s'en occupe que sur son temps libre, on se retrouve avec des applications trouées qui continuent de fonctionner comme si de rien était.
L'avantage d'un système de paquets comme APT est que les développeurs et/ou mainteneurs de paquet ne s'occupent que de leur application. Et je pense que les gens qui s'occupent du paquet openssl savent mieux ce qu'ils font et sont certainement plus consciencieux avec celui-ci, que ne peut l'être le développeur du petit client Twitter. Au pire, les efforts de mise à jour sont mutualisés, avec Snap ils seront éparpillés voire passés à la trappe.
On peut aussi redouter le gâchis d'espace disque que va entraîner l'intégration de chaque bibliothèque tierce au sein de chaque application qui la nécessite, au lieu de la partager au niveau du système d'exploitation.
À noter que, encore une fois, Canonical fait cavalier seul sur cet outil, plutôt que de contribuer au projet similaire XDG-APP porté par freedesktop.org. Peut-être est-ce justifié, je n'en sais rien.
Enfin bon, voyons ce que ça va donner. Pour ce projet Canonical a l'air de vouloir faire en sorte que ça fonctionne sur les autres distributions. Et peut-être qu'un éco-système à la PyPI/Composer/NPM va se mettre en place autour de la gestion des dépendances des paquets Snap et qu'ainsi le travail des développeurs sera facilité. Pour le grand bien des utilisateurs et surtout des adminsys. ;-)
