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.

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.

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.

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.