NOTE: this post is entirely personal. The opinions are my own and do not represent Fedora or Red Hat. The facts, however, are all 100% truthy. 😉 Just to make it 100% clear for any visiting journalists etc. who don’t know me: I work for Red Hat, on Fedora. I am not unbiased and am not claiming to be, but I am claiming that the concrete stuff I say below is true.
You may have read some stuff this week about an application delivery mechanism called Snappy and how it’s going to unite all distributions and kill apt and rpm!
This is, to put it diplomatically, a heaping pile of steaming bullshit. You may not be surprised to learn that said pile has been served by the Canonical press department.
The source of all this press was this gem of a press release, which has been widely covered in a fairly…uncritical way by several outlets. Even Ars Technica, which is usually fairly good at doing actual journalism rather than just unquestioningly paraphrasing press releases, gave it a pretty anodyne write-up.
The press release and the stories together give you the strong impression that this thing called Snappy is going to be the cross-distribution future of application delivery, and it’s all ready for use today and lots of major distributions are buying into it. In the press release you’ll find stuff like this:
“Developers from multiple Linux distributions and companies today announced collaboration on the “snap” universal Linux package format, enabling a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device.”
The stories have headlines like “Adios apt and yum? Ubuntu’s snap apps are coming to distros everywhere” and “Snap Packages Become Universal Binary Format for All GNU/Linux Distributions” (jeez, I particularly love that one).
So what are the problems with this happy-clappy story? Several of them!
First let’s be clear: Snappy is a Canonical project. The press release was issued, I think, sort of as if it came from some sort of independent or cross-vendor project, and there’s the snapcraft.io site to back up that impression, but every Snappy committer is a Canonical employee, and contributions to Snappy require signing the notorious Canonical CLA:
“Contributions are always welcome! Please make sure that you sign the Canonical contributor licence agreement at http://www.ubuntu.com/legal/contributors”
Now, does Snappy actually have the cross-distribution buy-in that the press release claims (but never outright states) that it has? No. The press release sure sounds superficially impressive:
“Developers from multiple Linux distributions…Snaps now work natively on Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, and Xubuntu…Together, these distributions represent the vast majority of common Linux usage on the desktop, server and cloud.”
but it’s a pretty big mis-representation. The other distributions cited have not actually declared their support for Snappy and said ‘yes, this is how we want applications to be distributed in future’. Canonical employees have independently built and released Snappy packages for those distributions. This is the basis of all the press release’s claims. For instance, the Snappy packages for Fedora are in a COPR – COPR is a system like PPA that lets anyone build packages – maintained by a Canonical employee. The sum total of communication between Canonical and Fedora before the release of this press release was that they mailed us asking about the process of packaging snappy for Fedora, and we told them about the main packaging process and COPR. They certainly did not in any way inform Fedora that they were going to send out a press release strongly implying that Fedora, along with every other distro in the world, was now a happy traveler on the Snappy bandwagon.
There is in fact another system with very similar goals, which is now called Flatpak and was previously called xdg-app. To be as fair as I can, I’ll say that Flatpak is quite heavily Red Hat influenced: the main author of Flatpak is Alex Larsson, a Red Hat employee. It is not, however, a “Red Hat project” to anything like the extent Snappy is a Canonical project. There are more than 20 other committers to Flatpak, most of whom are not RH employees (and including contributors to several other distributions). Flatpak is not under any corporate CLA. Insofar as Fedora is supporting one of these systems, it’s behind Flatpak. No other distribution besides Ubuntu is particularly committed to either system, so far as I can tell. Flatpak and Snappy both began, so far as I could find from internet research, in December 2014. Canonical’s press release, of course, doesn’t even acknowledge Flatpak’s existence…which is kind of par for the PR course, but you’d think at least some journalists might go out and do a bit of independent research.
UPDATE: since writing this post I’ve also been made aware of another system, AppImage, which has been around somewhat longer than Flatpak or Snappy (though not necessarily their forerunners). I know little about it so I will say little, but one thing to note is that – so I’ve heard – it does not attempt to do sandboxing like Snappy and Flatpak do, which is a major feature of those two implementations. It’s purely an app bundle format. But hey, it’s a choice! And it’s been around a while!
Neither Snappy nor Flatpak is at all close to being ‘done’, in the sense of being a credible system for cross-platform app distribution with buy-in from software publishers and distributions. The PR’s claim that Snappy enables “a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device” sounds lovely, doesn’t it? Let’s take a look at the truth. Taking Fedora as an example, the Snappy install instructions for Fedora – go to the Snappy site and click the Fedora logo – say:
# SELinux support is in beta, so on Fedora 24 you currently have to: sudo setenforce 0
well, that doesn’t seem terribly ‘secure’ or ‘perfect’ now, does it? Along the same lines, the Fedora packages are actually compiled with Snappy’s confinement disabled. Confinement being the entirety of what’s supposed to be secure about this form of app distribution. If confinement isn’t turned on, you’ve basically just got a big blob with uncontrolled access to the system. Good luck with that.
AIUI, the builds for other distributions are in similar states.
Note that neither Snappy nor Flatpak can possibly provide meaningful confinement of apps running under X11, as mjg59 illustrated. Flatpak will only provide meaningful confinement with Wayland. Snappy, of course, is designed to work with Mir, though they claim it can/could (not sure which) also work with Wayland. But the point here is that neither Wayland nor Mir is out there in real widespread use by Linux users at present, yet here’s Canonical happily glossing over that point while they talk about how Snappy right now allows “a single binary package to work perfectly and securely on any Linux desktop”.
At the time this Panglossian PR was sent out, there were exactly two actual useful applications available as snaps: LibreOffice and Krita. Phoronix quickly found that the LibreOffice snap was huge (over 1GB in size) and buggy. The size issue was quite quickly resolved, but this just goes to show that reality is vastly different from Canonical’s claims. This stuff is in early Alpha or proof-of-concept state. It is not remotely ‘done’ and ready for practical use in the real world outside of the very limited contexts where Canonical was already using it.
Neither is Flatpak, of course. But this is why Flatpak’s developers have been communicating with technical conference presentations and blog posts and trying to build a dialog with application developers and distributors, rather than issuing press releases trumpeting how great Flatpak is and how it’s ready to kill apt RIGHT NOW.
Here’s another interesting thing about Snaps: the server end (the ‘app store’ bit of the equation) is closed source, and Canonical have been refusing to tell anyone how to run their own ‘app store’ – see the comment from Cassidy James Blaede, of Elementary. If you want to distribute your snaps, your choices are 1) publish it through the Canonical store, entirely under Canonical’s control, 2) upload it as a file and tell people to use the CLI to install it, or 3) try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch, and tell your users to do that. Hmm.
So: Snappy is, like Flatpak, a heavily-under-development, interesting attempt to provide an app store-like app provision mechanism for Linux. It is not finished, it is not close to finished. It is not independent or cross-distribution, it is entirely controlled by Canonical. It does not have, so far as I can tell, meaningful buy-in from a single major distribution outside of Ubuntu. It does not work properly on other distributions yet and it likely will not do so in the near future.
But apart from that, sure, it’s all ready to kill apt and dnf tomorrow!
Now I’m sure I will get criticized for being mean and nasty and cynical and attacking Canonical instead of being constructive and all they want to do is make things better for everyone, Adam why are you such an ass?
Well, if Canonical actually wanted to work constructively with others, the way to do so would be to talk to them. We have forums for cross-distribution and cross-project collaboration. Lots of them. We have tech conferences where you can go and talk about your project and try to get buy-in for it. Canonical could have come to other distributions and said, hey, how about we all try to get together behind a single format and a common delivery mechanism for this kind of a confined app bundle?
But they didn’t. They just decided to send out a wildly misleading press release and actively encourage the specialist press to report that Snappy was all set to take over the world and everyone was super happy with that.
That’s not being constructive or working together with others. That’s being a bunch of asshats and trying to present the rest of the community with a fait accompli – and notably, a fait accompli in which Canonical holds all the strings (by means of the Canonical CLA controlling contributions to the client end, and the closed source, closed shop server end that is owned entirely by Canonical).