cmart learns about: Snap application packaging
Editorial note: please treat all of this as low-quality, non-fact-checked writing. I am trying to understand something new and fit it into what I already know and believe. I am sharing my personal notes for others who may find it helpful. Please don’t rely on this or cite it in anything important. Please feel free to tell me why I’m wrong.
Since 2014, I’ve used Debian as my main personal operating system. For even longer, I’ve supported a variety of Linux distros for work, both Debian-derived (Ubuntu) and Red Hat-derived. Ubuntu 22.04 now packages both Firefox and Chromium browsers as something called a snap. Snap is different than the dpkg + APT software packaging system that Debian and Ubuntu have used for 2 decades. The introduction of snaps has caused a stir, and this associated bug is now causing problems for users of the service that I work on: you can’t open any Snap-packaged software in a remote desktop (VNC) session. I guess it’s time to learn about Snaps.
What are snaps?
Let’s start at Wikipedia. Snaps are “self-contained applications running in a sandbox with mediated access to the host system”. Sounds sort of like kernel-level virtualization (a.k.a. containers). Okay, snaps work across a range of Linux distributions.
Snaps manage dependencies
There is a snap file format containing a SquashFS filesystem. That filesystem contains the application along with all of its libraries and dependencies. Snap sounds tightly integrated with systemd, and supports both desktop and non-desktop (server) applications. Cool. It is often a challenge to manage a software dependencies, and bundling all the dependencies into the package is one strategy to make it work. This strategy has some tradeoffs, like packages that take a lot of storage space (and if you have many of these packages on your computer, you end up storing the same dependencies in multiple duplicate places). Maybe snaps mitigate some of those tradeoffs?
Snaps provide a permissions framework?
“Applications in a snap run in a container with limited access to the host system.” Aha, of course there are containers. 😉 “Interfaces” are used to provide an application with access to features of the host like USB devices. “These interfaces mediate regular Linux APIs”. The article claims that applications don’t need to be rewritten for this mediated access to work – huge if true. This sounds like it’s trying to (among other things) bring smartphone-like granular app permissions to desktop software, which I believe is badly needed in the Linux ecosystem. Can it actually be done without re-writing software to ask the operating system for permission for various actions?
Snaps force automatic updates
Snaps also include automatic updates. This sounds flexible in all sorts of ways except perhaps the most important one, the ability to turn off automatic updates when needed. That aside, snap software can be published with a “track” (like latest or 2.0) and a “risk” (like stable or maybe beta). The user can specify a combination of track and risk, which is called a channel. Still, the inability to disable automatic updates sounds like “we know what users need better than they do” attitude. Even when the developers are making what is often the best choice for most people, I don’t like any software that intentionally takes away autonomy that people are likely to want, especially when it would be easy to provide. People move away from proprietary operating systems specifically to avoid this sort of paternalism, and now here it is on Linux. Thanks, Canonical.
Snapcraft is a packaging tool that builds Snaps inside a virtual machine. It uses another Canonical tool called Multipass that I don’t know anything about, feels a bit out of scope here.
Canonical has a Snap Store. What’s it like? Wikipedia says it is closed-source, and Snap is “locked” to it. Is Canonical trying to use Snaps to build a proprietary software distribution ecosystem? I need to learn more.
Before reading more, this sounds like Snaps are trying to solve some big existing problems with software distribution on Linux.
- Bundling dependencies, which relieves pressure on developers and distro maintainers, and provides more flexibility to users, with various technical tradeoffs
- Empowering regular, non-extra-sophisticated users to manage permissions for what applications are allowed to do, just like we already have on Android and iOS
- Automatic updates, though this is kind of a solved problem already
- What is the difference between snap, flatpak, and appimages? Flatpak doesn’t support non-desktop applications and system services? https://www.fosslinux.com/42410/snap-vs-flatpak-vs-appimage-know-the-differences-which-is-better.htm
- How much storage space do snaps take compared to non-snap-distributed applications?
- Why do people say that snaps take a long time to start?
- How much RAM do snap-packaged applications consume while running, compared to non-snap-packaged ones?