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).


Comments on this page:

By Ruben Greg at 2020-05-03 14:55:03:

I do not want to sound snarky but 'snaps' do solve one problem. Ubuntu or canonical can avoid fixing bugs. You wrote about this a while back (1). This weekend missus's computer (2) hitup on issue with vlc - we stream everything from freeNAS. Next thing, vlc hung while using upnp. After quite some googling I found (3). Whatever reason Canonical knows - it is 'Unassigned'.

I really wanted to ask Mark S; if at all I see him at a conference. Last time I spoke to him he was empathetic and attentive.

With great anxiousness install snap, and vlc. Just works.

1. https://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuBugReportsUseless

2. It was properly running xenial. To update bios, I just swapped to a temporary windows ssd (ya,ya - finally spectre fix came home). Could have stopped there but out of curiosity... I enabled autoupdates :-(

3. https://bugs.launchpad.net/ubuntu/+source/libupnp/+bug/1571199

By Blissex at 2020-05-09 10:33:04:

Yes, mostly it is those things about "app store" blobs, but there is another angle, which is the same as containers and VMS: eliminate system administration of packages, both at the platform vendor level, and at the user level, but turning apps into "black boxes" that neither platform vendors not users need (or can) know anything about.

But what all these "encapsulation" technologies really do is not to eliminate system administration, but to move it from platform vendors and users to developers, which eventually becomes a an "abandonware" strategy, because developers are rarely interested for long in updating and maintaining installed applications as the "sale" is already made.

But never doing updates or other preventive maintenance (and not just to apps, and not just for computing) is already a common practice among many users whether organizations or (especially) individuals, to cut business running costs, so removing the ability to do them only impacts those who do, which may well be a minority.

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

Page tools: View Source, View Normal, 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.