Snap out of it: Canonical on Flatpak friction, Core Desktop, and the future of Ubuntu 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 …
When they foisted FF as a snap on LTS but it wouldn't work anywhere but /home/user I had to remove snaps and go to the mozilla ppa to get FF back.
Took them years to fix the bug, by which time I'd given up, and I'd never touch them again.
Partly because they're kludgy, and partly because I don't trust Canonicals attention to their engineering.
Pipewire next? Time to move.
Snap attempts two things: packet management and enhanced security/stability. It attempts to do so mainly by separating applictions from the rest of the OS and other applications as much as possible. These can be Good Things and there are many real-world situations where you don't just want that, but actually need it.
The problem with snap, though (as I see it) is the way this idea is being implemented. Snap packages usually try to install a complete environment in a sandbox for the application to run in, and then proceed to brutally enforce that isolationism. The result is often an appalling amount of overhead, causing long load times, bad application performance, and a high demand on system resources. (Firefox comes to mind.) This is combined with severely restricted file system access to the point where it impacts the usability of applications. For example: before I replaced Ubuntu with Mint (the latter having flatpak rather than snap by default) I had a snap-ified version of Musicbrainz Picard for MP3 taggng. But because I don't keep my 30,000+ MP3 collection in my home directory, Picard was unable to access the files and therefore unable to tag them (which is the raison d'être of Picard in the first place).
My point is, snap is a great option if you really need the separation and sandboxing, but it should not a default strategy. Don't try to ram it down my throat because it's supposed to be for my own good. I will decide when and if I want it, thank you very much.
If snap gets in the way to the point where it impacts the performance or usability of applications, I'm not interested, unless I have compelling reasons to put up with that nonsense.
Decent interview, cheers.
I might not agree with a bunch of what he says but it’s nice that he’s at least aware of the points of difference and has his reasons for why they’re taking the path they are. Too many interviews are just “we’re right, critics are wrong”.
I’ve not really played with immutable installs. If the Ubuntu one is a way off, what’s the best in class at the moment?
Regarding an immutable install to try, I've been using Project Bluefin for about a year, which has changed how I use or maintain my Linux laptop (for the better). You really need to commit to Flatpak and Brew on it though, as these are the only ways you would get your GUI and CLI applications.
Think of immutable distros as "locked down Linux" or "Linux with training-wheels". It provides just what it says, an immutable core, so the normal customizations advances users have made for years in /etc and elsewhere are no longer available. Further complicating matters is the lack of standardization in how apps look for config overrides from, e.g. /usr, /etc/ and then ~/. Not all apps implement the same lookup leaving users who need customization often with nothing but a dive into the package source to see if and what config paths are utilized.
That said, I agree with the assessment of the interview. While I may not agree with the design decisions being made, at least the justifications were given, and they are free to choose their own path forward. For Ubuntu user, the good news is the announcement that a "Ubuntu-Classic" will be available along side. So you can give both a drive and make your own decisions for your use case. There are some where immutable is a great fit - just not for a normal power-user desktop or server.
The choice vs polish thing is true and a major stumbling block, at home I switched from Windows to Ubuntu at the beginning of the year and have stuck with it. One of the biggest headaches was working out which of the many ways to configure the system is active. The chopping and changing of audio system, and even windowing system over the years makes it very difficult to research an issue as last year's fix might configure something that is ignored, configurations are routinely overwritten too, leading to even more confusion and deeper research. Then you pop into a forum and get shouted at because you don't know the correct terms or that something has changed, so you don't do that again, you either give up, change the hardware you can't get working or keep searching.
However, after many rabbit holes I'm happier with the system I use today than I have been for years with Windows. One way Ubuntu could make things easier is to have an app that just lists which of the many ways to configure the system is active. I'm fully aware that someone reading this is foaming at the mouth shouting "write it yourself", well that's a whole different rabbit warren.
It's a false dichotomy. Apple has a more polished experience because it just hides everything from you. You could make it even more polished by just pasting a screenshot on the display instead. You can't break what you can't interact with. Maybe that's the ultimate logic of AI browsers.
The problem isn't choice or fragmentation, it's that things aren't clearly explained or laid out because they're designed and written by people who assume you'll read the manual. Having better UX designers is a better solution than reducing everything to a lowest common denominator.
I'm 100% in favour of sandbox style packaging the application level. It's very convenient to have an app just install and work regardless of the distribution.
But at a lower level this stuff can be a source of grief because its security sandboxed and if the policies get screwed up or don't behave the way the native executable does it can fail in surprising ways. I've suffered errors that only happen in snap but not the same executable run directly so I prefer the latter. I really don't like the zeal Ubuntu is trying to do this. I'm sure they'll say they're trying to modularise their distribution, make it all componentized but it comes at a cost.
I also don't buy arguments they had to use snap because flatpak supports multiple websites - that is a feature not a bug. There would be nothing to stop Ubuntu using flatpak and pointing at their own site and their own signed flatpaks if they were so worried about that.
So application level good, below application level, not so much.
Which of course is true, and also part of my problem with it. Yes, I'm not their target audience. But I am one of their users. Could they please stop trying to force me to do something I don't want to do for the benefit of some other user who I am not?
I don't mind that snaps exist, but if I sudo apt install something I expect to get it packaged as a deb, not a silent redirect to the snap store. If I wanted the snap I would have asked for it.
"Sandbox packaging" is completely obsolete in my use case. How so? Because I was able to buy my 5750GE from China after all. So now I've got my GPU card plus my integrated GPU. The way I do it, I've got a host Linux Mint OS running with the integrated GPU, and I've got a guest Linux Mint OS running with the discrete GPU card. Fully accelerated any which way.
So all I do is boot up another environment (in Virtual Machine Manager "virsh" running QEMU, can handle any of em) and install/run whatever application in whatever operating system it happens to prefer, it makes no difference to me whether its Windows Mac Linux Solaris Kolibri or whatever.
Yeah maybe not the latest greatest A.I. infused operating system versions, but then I'm running mostly legacy applications anyway. The operating system is pretty much irrelevant to what I'm doing, I know some people don't like to hear that kind of talk, but that's the way I go.
So the reason why sandbox packaging is obsolete is I already run a sandbox, with snapshots, clones, multiple VMs. I mean sure, if you have to package your app in another sandbox that's not any problem, go nuts. Doesn't do anything useful or worthwhile from my perspective.
" 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."
Go for the latter, make the whole desktop stack coherent, and test the lemon juice out of the most common applications that people use and make sure they work. Make SnapKits available for specialised applications. Show us what is possible.
Those who need a high degree of customisation will find something else, Debian, Arch whatever. The river will carry on flowing.
I can even live with the opacity. I know enough to know that I know nothing. I have no idea how 90% of my system works - and I'm pretty sure that the bits I think I know I'm probably wrong because they've likely been replaced with something else since I last looked.
What I can't live with - what drives me to distraction - is the fact that things keep breaking and then when I try and work out what went wrong, the tools that have served me for years to debug them don't work any more because apparently the thing I think I'm working on is just an abstraction layer over another thing, which is an abstraction layer over another thing, which is probably an abstraction layer over something else after that!
I wouldn't mind (I mean, on a philosophical level I kinda object to that kind of abstraction, but mostly I wouldn't mind because I wouldn't think about it) if the bloody thing was sufficiently reliable that I never had to dig down there and notice what a mess everything is becoming under the surface.
Well, like I said, I wouldn't mind having no idea how any of it worked if it "Just worked" (tm) but it doesn't. If it's not going to "Just work" (tm) then I need to be able to debug it, and at that point, yes the opacity becomes a problem.
I mean, I have no idea how the kernel works really. It's just sort of... there. It does its thing. But I also don't really need to know because it's so reliable. I only need to know when things go wrong a lot, and it seems like snaps go wrong a lot.
I think you're correctly highlighting the unproven thing about immutable distros. There are clear advantages in some areas, but is reliability really one of them? If it's not, you end up with the Apple approach of "take it back to the shop"... which would be a bit difficult with Linux!
You have to remember, though, that for most users, almost everything about every operating system is pretty opaque. A lot of people want a system which requires zero tinkering, because they want to do things with their computer rather than do things *to* the computer.
If immutable distros meet the needs of people who just want something that works reliably without tinkering, great! The world is big enough for many different approaches.
Jon Seager seems like a very serious person to me, and I believe that since he arrived at Canonical, Ubuntu is getting back on track to be the reference again, if it isn't already. I agree with him that a store in a general-purpose operating system must have guarantees from the entity responsible for that operating system. But for that, Snapcraft should have more human resources; I think they take a long time to resolve some bureaucratic aspects from what I see in their forum, and they rely on automatic review processes that don't always work with some Snaps.
Having said the negative, let's move on to the praise. Snaps in 2025 work wonderfully. Fast? They are. Performance? I've been using them with Steam for a couple of months on different computers and it's perfect. Permissions? I see they are working on it. This is the only part where it still falters. I have no opinion on including basic system components in Snap packages. To avoid hurting any sensitivities again, just leaving PipeWire in the repositories would be enough, in my opinion. I am glad to see that Ubuntu Core Desktop will not be launched until it is ready. We have already seen how launching Snap for general use when it wasn't ready created a bad image that they can't seem to shake off, so an immutable distro that is meant to mark your future must be launched with everything refined.
As Seager rightly says, Canonical had a crisis in the 2010s for wanting to be too ambitious, but I think that so far this decade they have been regaining ground. They are still very ambitious, but now in small doses that don't put the entire project at risk. I am confident that they can continue to create something that people want to stick with and grow on.
P.S. Excuse my English. :D
AFAICS it looks very much like emulating the Windows experience.
Current Linux practice is along the following lines:
libwhatever is used by a lot of executables - low level stuff such as the command line shell and the graphical shell, the command line and graphical file managers and higher level stuff such as a browser, a couple of graphics applications, an office suite and others*. Some vulnerability in it is fixed or maybe some clamoured for extra functionality is developed. The new version is placed in the repository and a user's regular update process discovers it, downloads it, either automatically or by user approval, and everything that needs it just uses it on the next invocation. It's very quick and the only things I've ever seen need a reboot are a new kernel and, on one occasion, a very low level service. In practice a few small updates might pass through every week, a larger batch of programs that work together every few weeks and a new kernel every few months.
As I understand it the immutable version of doing things is that in order to do this an entire snapshot of the core OS has to be created, installed and booted. I doubt this is going to happen just because libwhatever has been changed because it will be disruptive so it will only happen at intervals (monthly? every 2nd Tuesday?). If libwhatever has security issues the core is going to have to live with it unless an out of schedule update is issued. This becomes very Windows-like AFAICS. Maybe this is the intention - make it familiar with a lengthy, disruptive update happening every month. There's also the added detail that AIUI those higher level applications, the browsers etc, aren't going to use the libwhatever in the immutable core, they're going to have their own version in a snap, flatpak or wherever which is a bit of a lottery because they might get the newer version faster than the core if it's released more quicker** or never if the packager never gets round to it.
* In a few cases applications might have their own version for some reason and the launch process has to arrange to use it. It will be stored somewhere out of the way - an application-specific directory tree under /opt is the accepted place or /usr/local if it was locally compiled from source, Like snaps etc it might get updated on a different schedule to the main system implementation. If you're Ubuntu or whatever this suffers from NIH syndrome.
** What would be the schedule for releasing these? As and when ready as per current practice or alongside the immutable core?
I wonder about this sort of thing.
Now, I see the benefit of an immutable "base" image relative to which all other things can be delivered as diffs and/or overlays depending. You borked an update? Just put it back to the base image and try again. Base image stays pretty much the way it is and could sit like that for potentially years with more and more and more overlays being laid on top of it.
Do that, and you can release updates to libfoo on whatever schedule you like, because you just release a new libfoo overlay.
...but if you start doing that you've just invented a really complex and resource intensive way of versioning individual files, so I'm going to assume that's not the plan. If that's not the plan, however, all the problems you just outlined seem to come creeping back in again. If I can't update one file - or even little cluster of files representing some specific application or library - and have to wait for the monthly release of the new base image that seems... sub-optimal, to put it politely.
Regarding, "The thing is that the option to have multiple stores is not always the answer. It's been a big problem for Fedora"
I asked Jon if he actually meant to refer to the OBS Studio bug when he made this statement, and he said "no", so I would like to ask you to remove that link.
The Register's article about the Fedora Flatpak dispute itself is such poor quality that it really should be removed entirely. For example, it supports its argument with the statement "OBS Studio users found features missing or simply not working, along with other issues," and links to three examples. One of them has no discussion or conclusion, one of them links to a problem that affected OBS Studio's official package on Flathub, and one of them links to an issue that was caused by a regression in QT.
> no such thing as an immutable general purpose operating system
I'd love to hear what he considers a general purpose OS. SteamOS, for example, might be designed for gaming but it is perfectly capable of school work, office work or running the lights for a concert.
How more general purpose can an OS be?
5 letter word for change that doesn’t really serve any purpose or confer any advantage.
“The program already works, but unless we keep f’ing around and around and around, people won’t think it’s any good anymore.”
(Unless you keep innovating new attack vectors into your system, eventually nobody is going to try attacking it anymore. Once the job is done EVERYBODY OUTTA WORK!)
I really couldn't care about desktop Linux. I care about the server side. What is going to happen there, or am I going to lose Ubuntu as a viable server alternative? There are critical applications I run that Ubuntu is the most supportable OS choice (RHEL and Rocky are not supported).
I feel that a lot of the changes discussed really are focused so desktop based that they forget that there is a whole group that runs Ubuntu as a server, paying for support directly from Canonical.
Did you miss what he said about Ubuntu being the only OS that can build an entire data center without any third party tools?
Ubuntu is all about the server. There's your love. The desktop was Shuttleworth's first motivation in the early 2000s. It stopped being the focus since the 2010s and it's still a side project since then. It might get some love now, but the server is Canonical's bread and butter. How can you ask for more love?
There's not a single commercial Linux desktop distro. All desktops are either community driven or a side project at big Linux commercial distros. Neither RedHat, nor Suse or Canonical are properly pushing the desktop. That's why big software vendors care so little about us.
After reading this interview (which should have been much longer), I have new hopes that Canonical gives the desktop as much love as the server in some not so distant future.
Did you miss what he said about Ubuntu being the only OS that can build an entire data center without any third party tools?
Ubuntu is all about the server. There's your love. The desktop was Shuttleworth's first motivation in the early 2000s. It stopped being the focus in the 2010s and it's still a side project since. It might get some love now, but the server is Canonical's bread and butter. How can you ask for more love?
There's not a single commercial Linux desktop distro. All desktops are either community driven or a side project at big Linux commercial distros. Neither RedHat, nor Suse or Canonical are properly pushing the desktop. That's why big software vendors care so little about us.
After reading this interview (which should have been much longer), I have new hopes that Canonical gives the desktop as much love as the server in some not so distant future.
This post has been deleted by its author
There is a general movement to hosted desktops in the corporate world to replace heavy Windows HVD's. Even MSFT is offering Windows Desktop in Azure. Especially companies with large call centers.
If you want to distribute and manage a large group of desktops, but control the app suites in scope, you create a "core OS" and let the customizations of applications come via Snaps (or Flatpaks)..
No one gets offended with the new generation of Linux based server OS'es which are basically a web GUI that lets you load containers of your choice from their "store".
So this looks like the same direction, just with desktops and snaps.
If that is not your thing, stick with Classic. My guess is Core is for call centers and classrooms.
It's really wasteful. For example, this desktop machine, running Ubuntu 25.04 now has 15 copies of python installed! That's a terrible waste of bandwidth, disk, RAM, and energy, especially when we solved this years ago with (versioned) shared libraries and a package manager. Also, snap isn't even a very good security system - the "Inner platform" effect means that you have to allow so many exceptions - e.g. to allow the user access to their files - that you might as well just use the regular OS permissions model.
locate python3 | grep -E '/usr/bin/python3$'
/snap/core/17212/usr/bin/python3
/snap/core/17247/usr/bin/python3
/snap/core18/2947/usr/bin/python3
/snap/core18/2952/usr/bin/python3
/snap/core20/2599/usr/bin/python3
/snap/core20/2669/usr/bin/python3
/snap/core22/2133/usr/bin/python3
/snap/core22/2139/usr/bin/python3
/snap/core24/1196/usr/bin/python3
/snap/core24/1225/usr/bin/python3
/snap/gnome-3-28-1804/194/usr/bin/python3
/snap/gnome-3-28-1804/198/usr/bin/python3
/snap/kf6-core22/42/usr/bin/python3
/snap/kf6-core22/43/usr/bin/python3
/usr/bin/python3
It feels like the whole need to have any snaps in default install is a really weird workaround to "no feature upgrades in deb packages" rule which is purely political!
If improved webcam support requires upgrading related OS level libraries, just upgrade the OS level libraries.
If you're willing to upgrade binaries inside the snap packages for software that's installed be default, you're already breaking the "no new features for OS updates" rule.
And once you can bring new features as part of the updates there's no need to use snap for any OS level update!
The whole problem Canonical is trying to fix with "Wireplumber or Firefox as snap package" is purely political one. And there has never been a good technical solution to any political problem. Just fix the political issues first!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
