Snap Out Of It: Canonical On Flatpak Friction, Core Desktop, And The Future Ofubuntu

Ubuntu Summit The Register FOSS desk sat down with Canonical’s vice-president for engineering, Jon Seager, during Ubuntu Summit earlier this month. This is a heavily condensed version of our conversation.

The Register: There’s some interesting stuff happening in immutable distros. Recently, I’ve written about the EU OS proposal and the KDE Linux project. Where’s Core Desktop? I’ve been waiting for three years.

Jon Seager: I will start by saying my personal opinion is that, medium to long term, the default Ubuntu that people will use will be a Core Desktop. I don’t know exactly when that will happen. It certainly won’t be for 26.04 or even 28.04 – this is, say, a five to ten-year thing, but I think there will come a point where, if you go to ubuntu.com/download and you click “download Ubuntu Desktop,” that will be a Core image. There will be an option to download some kind of “Ubuntu classic,” which is Ubuntu as we see it today.

But there are lots of challenges for us to get there. I am something of an immutable Linux bore. I wrote a blog recently called “The Immutable Linux Paradox.” I spent a lot of time working with NixOS, and more with things like Universal Blue. If you look at where immutable Linux is right now, there’s no such thing as an immutable general purpose operating system. Hence the paradox. But of what we have, Nix and Snap are kind of oddly similar, looking at how packages are built, how they end up on disk, and how they work. In fact, in Snapcraft, we use patchelf, which was originally a Nix tool, to achieve some of the things that we do. There’s lots of momentum behind bootc, and OStree is part of that. We’re not going to go that path. It’s interesting, and it has some nice properties, as I outlined in my blog.

At the moment, honestly, progress is slow. When we said “this is going to be ready,” I was not in the driving seat for Ubuntu. On closer inspection, myself and a couple of others decided that we had some architectural work to do, to make sure that it was something we could be proud of when it released. So what we got was a kind of a concept: we showed that we could start a machine up that was Core GNOME, and we also had an engagement for a while with the KDE folks.

TR: Yes, we covered that last year.

JS: That’s what triggered us to rethink. It became apparent that the way the original concept had been built made it quite difficult to swap out gdm for kdm, GNOME for KDE, and whatever. So, we have gone to a better architecture, I think, but not to the extent I would like.

Right at the core of this is snapd. That’s still being very actively developed. One of the things that we’re working on that will have a bigger impact on Core Desktop is permissions prompting. You’ve seen this in experimental mode in 25.10, and it should be GA in 26.04. This is the key to unlocking Snaps on the desktop. There are already places where Snaps have worked excellently on the desktop, like Signal Desktop, Discord, and various other Snapcrafters… But there are other places where the experience has been less smooth, because of the security confinement. Often what happens is someone is using a famous app, they try to do something outside of the sandbox, and either the app does nothing, or it crashes. That is infuriating, there’s no two ways about it. It’s right at the heart of where people start to draw comparisons between Flatpaks and Snaps, which, while similar, do confinement differently.

Permissions prompting is going to introduce the sort of mechanism people have become used to on iOS and Android and macOS, where you download a Snap, and when you click a button that means it needs to use your camera, the app will be suspended, and a prompt will come up and say, this app is trying to use your camera. Do you want to allow it to or not? So we can still distribute binaries that are confined, and can’t access things by default, and we can basically say to the user, “it’s up to you to allow them to use your camera.” Let them make a judgment call. That’s critical for us to land Core Desktop, because in Core Desktop, there are no “classic” (unconfined) snaps. So while there hasn’t been a huge amount of progress on Core Desktop itself, lots of fundamental mechanisms are actually being worked on every day.

TPM FDE (Full Disk Encryption) is another. The reason TPM FDE has taken slightly longer for Ubuntu than the route that some other distros have taken is because we are building this kind of hybrid approach that works just as well on Core Desktop as it does on classic Ubuntu. So, a lot of the underlying pieces we’re tackling very squarely as we speak.

I do have a plan for post-26.04 to assemble a tiger team on Core Desktop. In what I would like to achieve with the desktop, it’s very high up the list, but I don’t want to get there badly, just to get it out the door quickly. I want to get there in order to build the desktop for the next 20 years.

We have a roadmap. One of the things we’re looking at for 26.04 is shipping Pipewire as a Snap on the desktop. Now this is a bit of a risky move, because there is a crowd of people who love to say that the first thing they do on Ubuntu is remove snapd, and if they do that on this future release, they’ll have no sound. Why start with Pipewire? Well, it interacts with things like cameras, so it would allow us to more easily backport support for newer cameras and speakers to Ubuntu. Pipewire is a user-space daemon: it normally runs as a systemd user unit. With Snaps, we get automatic management of systemd units. We had to do a bunch of snapd work for Core Desktop anyway, and I see this as another thing that we are doing on the way to Core Desktop.

TR: I heard from a reader last week who had removed all the Snap apps and snapd, and replaced it with Flatpak. I’m happy for them. It’s not done Linux Mint any harm, for example.

JS: There was this awkwardness where we released 25.10, and installing new Flatpaks didn’t work. Not through malice, not because I don’t want Flatpak to be a thing, certainly not some foul play. It was as a result of us shipping more AppArmor profiles for things in the archive, which is a good thing: in general, more things should be more confined. It was really just an indication that Flatpak is just not a priority. Actually, I have asked the team to put a series of tests in, to make sure that if we break Flatpak in future, we know about it, because I recognize that that is an important ecosystem that people like to use. I don’t want to actually stop people from using Flatpaks.

TR: There is this perception that Snap is closed, and Flatpak is open, and therefore Flatpak is better. A couple of years ago, I wrote about how the tooling for building and distributing Snaps was all open.

JS: The thing is that the option to have multiple stores is not always the answer. It’s been a big problem for Fedora. In reality, every time you add another store, you are essentially giving those people root on your machine. With .DEBs, you run maintainer scripts as root. The negative way of looking at it is that Canonical has root.

I think there is something to be said for the model with the Apple App Store and the Google Play store: they’re being kind of the obvious place that your software comes from, from a vendor who is committed. I acknowledge that some people don’t love the kind of notarization that Apple have, the way they levy fees, but all of that aside, if you think about just the notion that there is a store full of content that has been somewhat vetted by the distributor of the platform, I think it is difficult to argue that that is a straight bad thing. I also sympathize, which is why you can still add PPAs. You can still download a Snap file off the internet and do snap install -- dangerous.

In reality, if you look at the Linux desktop today compared to its other professional counterparts, like Mac and Windows, much as I love it, and I do, it is not polished in many ways, and I think some of that is due to this, like, unquenchable quest for choice and extensibility and plug-ability and hack-ability. So the question for me is: how do we set the bias between that and delivering a product that for 90 or 95 percent of people, they install it, they boot it up, and it just works, and it’s great.

I have done this experiment. Take Ubuntu, and a reasonably modern workstation, and I use a pile of Snaps. I use the Firefox Snap. I use VS Code, Obsidian, Todoist, Ghostty, all these things, and I’ll be honest, Mattermost, Discord, and Signal. Day to day, I do not run into these issues. I’m not trying to gaslight the internet. I acknowledge Firefox used to be very slow to start up, but I think we fixed that. The one thing that doesn’t work for me is the native messaging between OnePassword and Firefox. But I’m using my position to begin conversations with them.

My point is, we have this really long-term support commitment. How great would it be able to be to say to an ISV – say Proton, who are here today – you don’t need to think about windowing and volume and brightness and screen sharing and camera and microphones and whatever. For any given release Ubuntu, we’ll stand by this for 12 years like we stand by the rest of the distro. And by the way, we are irrefutably the most deployed desktop Linux. And so, if you appear in our store, you’re a verified publisher, you’ve worked with us, you adhere to those APIs, and it works.

One of the things that excites me about Canonical is that I do think we’re possibly – I’m happy to be corrected here – the only vendor that can truly do an entire datacenter, top to bottom, with just our stack. We have Ubuntu, we have MaaS – which is a bare-metal orchestrator; we have our own OpenStack; we have LXD, which is our own hypervisor; we have Juju, which is an orchestrator; we have our own Kubernetes; and we have all the apps. That’s pretty wild, and we also have various networking products we like. If we can get all the dots to join up, which is the hard part, there is something lovely about this vertical integration story, from your blinky thing on Kubernetes, down to literally the BMC on your server, and everything in between. You think about that from a commercial standpoint, for somebody who needs to build a datacenter, that’s a very easy engagement, in a sense. But the problem, of course, is that all of these things are very complicated. Bare metal orchestration for a datacenter is no walk in the park.

There were a few years in the middle, around the time when we dropped the phone, which predates me, where things were a bit tough, and some of those teams are running a bit lean, but we are back in, those teams are staffed.

Now there is the rust coreutils and sudo-rs. People calling me nasty names on the internet doesn’t really bother me. When the original GNU coreutils came out, it replaced something else, and the only reason it got so good is because it got so ubiquitous, many people used it, reported bugs and worked on it. And the same will happen with this. It’s not without risk, but I don’t think it’s reckless. ®

Original Source