Full Circle Magazine FR

Snappy allows you to install an automatically and fully updated, properly stable application on any distribution that supports it. This currently includes Ubuntu, Fedora, Arch, Debian, openSUSE and Gentoo. Snappy applications can even be installed from the graphical software center, if the software center supports it. Why is installing an automatically and fully updated, properly stable application on Linux not currently possible? Well this is a big problem on the current Linux desktop. There’s an apparently unresolvable dilemma between having stable applications and having up-to-date applications. This arises due to the nature of the Linux desktop’s shared dependency system. If you have fully up-to-date dependencies all the time—i.e., a rolling-release distribution model—you may find that you end up breaking slightly older applications that haven’t been updated upstream to work with the newer dependencies. This means that users are faced with significant bugs which they should never have had to deal with. It’s impossible to test properly for these occasions because, in order to get the updates out as fast as possible, the testing period is very short—which means less time to catch the bugs, and less time to make patches to fix them. You may think that this is possible, but reality has shown that it is not. On pressing those who claim that distributions like Arch, Antergos and Manjaro are stable, you find that actually they have to do various package management and configuration tasks, which an ordinary end-user should not have to do. Further, updates to dependencies on these rolling distributions can break key features of the desktop which should never be broken, not just applications. Antergos broke LightDM for at least a few hours (possibly more if it was a while between when the bug occurred and when the developers filed a blog post on it). If millions were using the Antergos operating system, this would have resulted in a great many unhappy users.

Snappy vous permet d'installer une application stable, complètement et automatiquement mise à jour, sur n'importe quelle distribution qui le prend en charge : notamment, à ce jour, Ubuntu, Fedora, Arch, Debian, open SUSE et Gentoo. Les applications Snappy peuvent même être installées à partir du Centre de logiciels graphique, si le centre le prend en charge.

Pourquoi l'installation d'une application stable, complètement et automatiquement mise à jour, sur Linux n'est-elle pas possible ? Eh bien, c'est un grand problème sur l'ordinateur de bureau Linux actuel. Il y a, apparemment, un dilemme sans issue entre avoir des applications stables et avoir des applications à jour. Ceci est dû à la nature du système de dépendances partagées du bureau Linux. Si vos dépendances sont toujours entièrement à jour, ce qui est le cas d'une distribution à publication continue, vous pourriez finir par casser des applications un peu plus vieilles qui n'ont pas été mises à jour en amont pour qu'elles fonctionnent avec les nouvelles dépendances. Cela signifie que les utilisateurs rencontrent des bogues importants qu'il faut traiter, ce qu'ils n'auraient jamais dû avoir à faire. C'est impossible de tester pour cela comme il faut, car, afin de pouvoir sortir les mises à jour aussi rapidement que possible, la période de test est très courte, ce qui signifie moins de temps pour se rendre compte des bogues et moins de temps pour faire des correctifs. Ça peut vous sembler possible, mais la réalité montre le contraire. Si vous insistez auprès de gens qui prétendent que des distributions comme Arch, Antergos et Manjaro sont stables, vous trouverez qu'ils sont en fait obligés de faire des tâches diverses de gestion et configuration de paquets, des tâches auxquelles un utilisateur final lambda ne devrait pas être confronté. Qui plus est, des mises à jour des dépendances sur ces distributions en publication continue peuvent casser des fonctionnalités importantes du bureau qui ne devraient jamais être cassées, et pas seulement des applications. Antergos a cassé LightDM pendant au moins quelques heures (et sans doute davantage, si c'était survenu entre le bogue et le moment où les développeurs ont sorti un billet de blog le concernant). Si des millions d'individus étaient en train d'utiliser le système d'exploitation Antergos, le résultat en aurait été de très très nombreux utilisateurs malheureux.

So much for the rolling-release model. As for the release-based distributions, they have the opposite problem. They may not be able to install a newer application because they rely on and expect a newer dependency that isn’t yet in the distribution – so they get bugs that way. If you update the dependency, you risk introducing bugs into other programs that depend on the same dependency, and this is why PPAs on Ubuntu, for example, can be quite risky and why packages aren’t always kept completely up-to-date by default in the first place. So how do we get properly up-to-date applications that work without these dependency-related bugs? Well, you allow the developer to bundle the dependency versions that they expect! This means that an update to a dependency does not result in users being left with a broken application; the developer of the application can update the dependencies and their application, ensuring that it still works correctly, in their own time. Snappy adopts this approach. There are still a few shared dependencies like libc, but much less than there were previously.

Le modèle d'une distribution en publication continue n'est apparemment pas la solution. Quant aux distributions basées sur des versions, elles ont le problème inverse. Elles peuvent être incapables d'installer une application récente, parce qu'elles font confiance et s'attendent à avoir des dépendances récentes qui ne font pas encore partie de la distribution - et elles rencontrent des problèmes ainsi. Si vous mettez à jour la dépendance, vous risquez d'introduire des bogues dans d'autres programmes qui ont la même dépendance et c'est pourquoi les PPA (archives personnelles de paquets) sur Ubuntu, par exemple, peuvent être très risquées et pourquoi les paquets ne sont pas toujours complètement à jour par défaut en premier lieu.

Alors, comment obtenir des applications, mises à jour comme il faut, qui fonctionnent sans les bogues associés aux dépendances ? Eh bien, vous permettez au développeur d'inclure les versions des dépendances attendues ! Cela signifie qu'une dépendance mise à jour ne laisse pas l'utilisateur face à une application cassée ; le développeur de l'application peut, quand il veut, mettre à jour les dépendances et leur application en s'assurant que tout fonctionne très bien. Snappy adopte cette approche. Quelques dépendances partagées restent, notamment libc, mais beaucoup moins que précédemment.

At this point, people complain about the file size. The file size does now increase because you have multiple copies of the same library used on the operating system. This is probably the only real disadvantage of snappy, but there are several reasons why this is not as big an issue as it seems. Firstly, with delta updates, once you have a snap installed, your computer downloads only a small amount of data to update the snap. Secondly, the file size of individual snaps can be cut down by stripping out unneeded features of dependencies, like Peek has done with ffmpeg and imagemagick. Thirdly, there’s usually quite a lot of a hard drive space on today’s laptops and desktops, so a big file size isn’t too much of an issue. Finally, there is a precedent for this way of handling packages: Android, for example, which has many duplicate Jar files, and even macOS and Windows, to a lesser extent. There’s another big advantage of snappy that makes it worth using: background updates happen without a prompt, like in ChromeOS, so there is less user interaction and users can just get on with using their operating system. Could this mean that an update breaks the app without the user’s permission? Perhaps, but this is less likely because there’s few shared dependencies and updates can be rolled back if necessary. Perhaps this seems insecure? But the applications are confined, they don’t have access to your whole system (they can if they need to – if they use classic confinement, but these snaps are manually reviewed before entering the snappy store), so this is not really a problem. Indeed, the confinement of snaps is itself another reason why snappy is great. They’re confined Android-style, they have access to only certain parts of the system, not the entire filesystem like with Linux applications packaged traditionally. Programs that really need to access the filesystem, like code editors, can do so, this is called Classic confinement, but the vast majority of snappy applications are confined properly.

C'est à ce stade que les gens se plaignent de la taille du fichier. Il est vrai que la taille du fichier augmente, parce qu'il y a de multiples copies de la même bibliothèque utilisées sur le système d'exploitation. C'est sans doute cela le seul inconvénient de Snappy, mais il y a plusieurs raisons pour lesquelles ce problème n'est pas aussi important qu'il peut paraître. Tout d'abord, avec les mises à jour delta (uniquement les changements), une fois qu'un snap est installé, l'ordinateur ne télécharge qu'une petite quantité de données pour mettre le snap à jour. Deuxièmement, la taille du fichier d'un snap individuel peut être réduite en enlevant les fonctionnalités inutiles des dépendances, comme Peek fait avec ffmpeg et imagemagick. Troisièmement, de nos jours, les ordinateurs de bureau ou portables ont généralement beaucoup d'espace disque et la grande taille d'un fichier n'est souvent pas un problème. Enfin, il y a un précédent pour cette façon de gérer les paquets : Android, par exemple, a de nombreux fichiers Jar en double et même macOS et Windows, dans une moindre mesure.

Cela vaut la peine d'utiliser snappy à cause d'un autre grand avantage : les mises à jour en arrière-plan ont lieu sans une invite, comme sous Chrome OS, et il y a donc moins d'interaction utilisateurs et les utilisateurs peuvent tout simplement continuer à utiliser leur système. Serait-il possible de casser une app avec une mise à jour faite sans la permission de l'utilisateur ? Peut-être, mais c'est moins probable parce qu'il n'y a que très peu de dépendances partagées et vous pouvez désinstaller les mises à jour au besoin. Le côté sécurité vous inquiète ? Mais les applications sont confinées et ne peuvent pas accéder à votre système entier (elles peuvent le faire au besoin, si elles utilisent le confinement classique, mais ces snaps-là sont évalué manuellement avant d'arriver dans le snappy store) ; ainsi, ce n'est pas vraiment un problème. En effet, le confinement des snaps contribue lui-même à la magnificence de snappy. Ils sont confinés comme dans Android et ne peuvent accéder qu'à certaines parties du système, pas à tout le système de fichiers, comme les applications Linux empaquetées de façon traditionnelle. Les programmes qui ont vraiment besoin d'accéder au système de fichiers, comme les éditeurs de code, peuvent le faire - cela s'appelle le Confinement classique -, mais la grande majorité des applications snappy sont confinés comme il faut.

Snappy would make regular application updates on desktop Linux very easy for the end user, and will continue to result in a better end-user desktop experience as development on the format continues. But snappy is also excellent for developers writing desktop Linux applications. They need to write only one declarative snapcraft.yaml file to build a snap of their application, and only a couple of commands (or even a couple of clicks) to get it published on the snappy store and thus published on every Linux install which has snappy installed – with no packager middleman. Despite the possibility of having no packager middleman, non-programmers like myself can get involved by helping upstream developers out by creating snapcraft.yaml files for them to adopt. Just go to the snapcraft (the name of the tool which makes snaps) tutorial, complete it (20 mins), then go and complete more snapcraft tutorials if you wish (like for Python, and websites), find a program that hasn’t been snapped yet, and snap it, then forward the working snapcraft.yaml to the developer to use themselves. If you face problems along the way, you can check out the snapcraft documentation, and you can ask questions to the friendly snapcraft community on the forums, Rocket Chat, and Stack Overflow. This is our opportunity to solve an old problem with the Linux desktop and drastically improve the usability of that desktop for ordinary computer users. Let’s grasp that opportunity.

Snappy facilite les mises à jour normale des applications sur Linux Desktop pour l'utilisateur final et continuera à améliorer l'expérience du bureau de l'utilisateur final au fur et à mesure de la continuation du développement du format. Mais snappy est également excellent pour des développeurs qui écrivent des applications pour Linux Desktop. Ils ne doivent écrire qu'un fichier déclaratif snapcraft.yaml pour faire un snap de leur application et ne saisir que deux ou trois commandes (ou même faire deux clics) pour qu'il soit publié sur le snappy store et, donc, publié sur chaque installation de Linux avec snappy, sans empaqueteur intermédiaire. Malgré la possibilité d'omettre l'empaqueteur intermédiaire, des gens, comme moi, qui ne sont pas des programmeurs, peuvent s'impliquer en aidant les développeurs en amont en créant des fichiers snapcraft.yaml qu'ils peuvent adopter. Il suffit de suivre le tutoriel de snapcraft (le nom de l'outil qui crée des snaps), le terminer (20 minutes), puis, si cela vous tente, aller faire d'autres tutoriels snapcraft (comme pour Python et des sites Web), trouver un programme qui n'a pas encore été « snappé » et snapper, puis envoyer le snapcraft.yaml fonctionnel au développeur pour qu'il puisse lui-même l'utiliser. Si vous rencontrez des problèmes en chemin, vous pouvez lire la documentation de snapcraft et vous pouvez poser des questions à la communauté amicale de snapcraft sur les forums Rocket Chat et Stack Overflox.

C'est l'occasion de résoudre un vieux problème sur le Linux desktop et d'améliorer considérablement la facilité d'utilisation de ce bureau pour les utilisateurs ordinaires d'ordinateurs. Saisissons cette opportunité !