Stuart Langridge, Jeremy Garcia, and special guest star Jorge Castro present Bad Voltage, in which we in theory want to talk about loads of news but actually we spend all our discussion time on one topic:
[00:02:00] Jorge is into Flatpak. And there's quite a lot to talk about here. This is very much about the Linux desktop, distribution of applications, and how things have changed; stuff has certainly happened since the last time we looked at this, and it's worth getting into. Let's talk about what flatpak means today.
FWIW, I (a KDE Neon user and Desktop Linux user of just over 20 years) use a combination flatpak, snap, and OG packages.
I’ve been following along the trajectory of this stuff for a while. I haven’t yet tried Silverblue (I would prefer a KDE-oriented distro), but immutable operating systems are very interesting to me. At my previous gig, I briefly worked on the team that was responsible for delivering the OS to the 5-digit fleet of bare metal servers. I spent a bunch of time trying to convince people that an immutable OS was the way to go. As Castro says, drawing a line between the system and the application layers makes a ton of sense, and making the system-level immutable really wipes out entire classes of bugs, mistakes, attacks, etc.
As an aside, IMO, much hand-wringing has been done over the past 20 years about desktops looking cohesive, but I’ve always felt these were overblown. A snapshot of typical Windows or MacOS desktop would look equally disjointed, as different toolkits are used to develop applications on those platforms as well (sometimes even applications written by the OS vendor themselves!). Sure, work to make toolkits look nice, try to get them to play together where you can, but don’t let that stop progress.
I’ve noticed there seems to be a lot of bad feeling towards snaps from the Linux community, even from ex-Canonical folks. I was really put off by the centralised snap store too, but listening to this episode makes me think that whilst our instinct is to want a solution without a central point of control, in practice a packaged app platform will always gravitate towards a centralised app store because it’s just way more convenient and secure (as long as you trust the entity which controls it or signs the packages).
That was certainly my experience working on Firefox OS where we set out to build something decentralised, but in using packaged apps ended up with a centralised app store regardless.
The only exception to this phenomenon which really scales seems to be true (progressive) web apps, which are self-hosted by the app developer at an HTTPS URL and executed inside a safe sandbox, rather than being packaged and distributed from a central source. This is what Chrome OS has been able to capitalise on.
Outside of the issue of centralisation (and general anti-Canonical sentiment), it seems a lot of pushback against snaps is about having a cohesive desktop environment. I wonder therefore whether the killer use case for snaps is actually IoT devices running Ubuntu Core and a single application, rather than a disjointed collection of apps in a desktop environment.
In developing IoT products, Ubuntu Core is actually quite a compelling proposition. Free OS level updates for 10 years, and a secure containerised application platform with automatic updates. Having tried to build a snap for Ubuntu Core I can attest to the fact that it’s a real pain the ass (it took me the best part of a year to get something half working, even with the help of Canonical), but I think the basic idea is good. Balena OS does something kind of similar with Docker containers (though I find their business model a bit problematic).
For desktop I really don’t know what the solution is. Web apps provide me with 80% of what I need and the remaining 20% is still kind of a mess. Maybe that remaining 20% can eventually be filled by web apps too.
And no, I don’t think blockchain is the solution either.
I advocated loudly for Flatpaks for years, but no longer. Pushing the sandbox and rootless install verbiage has done a lot to alienate the people who know those benefits are bullshit. There’s no fundamental reduction of risk or exposure to malfeasant maintainers by using flatpaks, and there may even be less scrutiny of flatpaks than distro-native packages.
A related and consistent community papercut has been the perception that many flatpaks are built by random (meaning not vetted) contributors, but that this is buried by the hyperbolic security-oriented sales fluff flatpak uses to present itself. It’s a self-inflicted injury of overzealous marketing.
Jorge showed up ready to scuffle, but he lacked a cohesive or practical vision of how flatpak dislodges an admittedly imperfect yet functional status quo. The dramatization that conventional installing of an app “gives the developer root” is reductive and sensational; Linux is built on community trust from the ground up and Flatpak does nothing to change that.
The current federated system of package management doesn’t white board well, but in practice it’s functional, durable, and amazingly secure thanks to the ingenuity and scrutiny of a massive community. If the most compelling case for Flatpak is a uniform rolling-release app overlay for every Linux system, then I’ll pass.
I think there’s nothing wrong with Canonical shipping with and promoting a single remote app store, but it should be easy to both create a snap store, and to add arbitrary ones. It’s just not reasonable otherwise; you’re investing a lot (doubling down, really, if you’re using Ubuntu) into a single organization who can unilaterally change (or abandon) the whole structure at any time.
Shuttleworth actually did a Keynote at SCALE a few years back; and he talked a lot about Snaps enabling IoT/edge stuff. It definitely makes a ton of sense there.
To clarify, “gives the developer and the package maintainer root”, but yes, strongly agreed. I can’t think of a time when that trust has been broken intentionally (certainly packaging mistakes have been made) at the distro level. The model has flaws, but I’ve not seen any reason to believe “sabotage” is one of them. Ironically, it’s the generation of package repos (pypi, npm, etc) that came later where this has become a concern and there have indeed been quite severe breaches of trust and sabotage. I would have liked to have heard a bit more about how flatpak is more like the former in terms of trust (it’s still relying on volunteer packagers), but manages to add further security.
I will say: I want it to work. I like the idea of faster moving, distro-agnostic end user application packages. I use flatpaks and snaps. I just think it’s better to show how they’re better and try to rally help to improve where they aren’t.
I feel like arguments like this expose one of the central problems with Linux, that (unlike the take-it-or-leave-it corporate world) most Linux distributions want to be all things to all people. This includes people who range from what I call the “pathological hobbyists” (Linux should be insecure, hard to use, and infinitely configurable, because it entertains them), Free Software purists, people who weirdly seem to only support the Linux kernel (so a Chromebook or Android tablet is “using Linux”) and love running proprietary software, people who want Linux to look like something else (a web browser, a giant phone, whatever), people who just want a general-purpose computer without big-corporate entanglements, and so forth. And a lot of the time, those factions outright refuse to believe that the other groups exist.
That’s a long way around the idea, but it’s hard to design a solution when stakeholders don’t agree that a problem exists, let alone what the problem is.
Honestly, standards for libraries seem like they would’ve been a better move. If the worry is “I can’t install X because version Y of the operating system is Z versions behind on a required library,” the problem is that either versions of libraries ship breaking changes, or the operating system can’t host multiple versions of libraries. The problem is not that the operating system doesn’t have enough bespoke copies of the same library to be distributed among applications.
Mostly, though, I’m just irritated that I need to care which application gets packaged which way at all. “Just search each repository for the latest version” is equivalent to “build from the source, which you’ll need to track down,” except that you don’t know that you have an official version without something-something-blockchain-something or whatnot.
Please respect our code of conduct which is simple: don't be a dick.
