What problems Snaps and Flatpaks are solving

May 1, 2020

One of the reactions to things like my problems with 'snaps' on Ubuntu 20.04 and the push for Snaps and Flatpak is to ask why they exist at all (for example, this lobste.rs comment). Despite my bad experience with Canonical's Chromium snap and my desire not to use Flatpaks at all, I do see why people are pushing them, or at least I think I do. The necessary disclaimer here is that I'm an outsider and somewhat cynical, so this is my perception of how things really are, not necessarily what people are saying out loud.

Snaps and things like them solve problems both for software developers and for people like Canonical. For software developers, Snaps promise to deliver a 'build once, run on every Linux' experience, rather than the current mess of trying to build for a variety of Linuxes with a variety of system setups, shared library versions, package formats and standards and so on. Although it's not the only thing you need, such a low hassle and reliable experience is pretty necessary if you want to attract more people to the Linux platform, especially commercial software. This is the straightforward pitch for snaps, flatpaks, and so on that you generally hear (for instance, it's almost all of the pitch on the Flatpak site).

For Canonical and people like them, that Snaps and Flatpaks are sandboxed theoretically allows them to reconcile three desires that are otherwise in tension. Canonical wants to run a single 'app store' that users get everything from (because that makes it attractive to both users and developers), for it to be pretty safe to install software from their app store (because otherwise people won't and then developers go away), and to not have to spend a lot of resources and money on vetting developers and auditing submitted Snaps. Canonical will have seen how much resources Apple and Google put into auditing submitted apps, in environments with much better fundamental security than standard Linux has, and they almost certainly want none of that. Sandboxing applications and carefully limiting their power over the system both at install time and at run time is necessary to square the circle here.

(Standard operating system packages are extremely dangerous because they have almost unlimited power at install time and thus often at runtime. This can easily lead third party packages to do undesirable things, or simply to have bugs or badly thought out ideas in their installation. And of course the installed software has free run of the system once you run it, even if it installs nothing ostensibly dangerous. If you're running a distribution, you really can't just put packages prepared by third parties into your distribution repositories; you have to audit both the packaging and the contents. Otherwise, things will blow up in your face sooner or later.)

Sandboxing and other safety measures would not be essential to Snaps if you didn't have the central 'app store' and got your Snaps directly from the software vendor. Then you would already have a direct trust relationship (including possibly deciding to give them money), and if they proved to be untrustworthy after all that would be on you alone. But then neither you nor the software vendors would have the benefits of a central app store, and there are benefits for both parties (in addition to benefits to Canonical).

Written on 01 May 2020.
« The afterlife of Python 2
What OSes we use here (as of May 2020) »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri May 1 23:07:19 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.