The future of Flatpak
46 points by runxiyu
46 points by runxiyu
Wildly contentious opinion:
I prefer Canonical’s snap over GNOME’s Flatpak.
SnapSnap is simple: download an archive, loop-mount it, symlink its contents into place. Versioning? Keep the old one, too. Rollback? Mount the older one again.
Works with GUI apps, shell apps, anything. With a bit of work, works for a whole desktop, or the kernel, anything.
Common FUD: it’s not FOSS. Truth: snap is 100% FOSS but the Canonical Snap Store is not. But all the tools to run your own snap store are included and it’s documented.
A real snag: clutters your df and blkid etc. output with loop filesystems. Minor pain.
Needs systemd. But that could be worked around if someone wanted.
Simple; you can remove snapd and your snap apps can still be mounted and run.
Speed: it used to be slow, but it’s been around for over a decade and it’s quick now.
FlatpakFlatpak uses OStree for distribution: that’s Git for binaries. It’s complicated. Git is complicated.
Flatpak only directly supports GUI apps; CLI apps need acrobatics.
It can’t be used for system components.
It, and OStree, does acrobatics with virtual filesystems and namespaces in order to work. Apps can’t be installed, run, or updated without that framework. Good luck with manual maintenance if something breaks.
If you want to package the OS like this, you need 2 tools: OStree and Flatpak.
The pair of them.They’re both disk space hogs. They’re both inefficient. They both struggle with dependencies. They both support deduplication via complex hacks. They both have problems with sandboxing. They both have Wild West app stores and problems with trojan apps in them. They both have unofficial packages that look legit but aren’t.
Every snap I’ve ever used has brought me pain. Every Flatpak app I’ve used has worked fine. Including when they were the same app. I recently switched to an OS without Snap and my life has been simpler. Yes, Flatpak has trickery under the hood, but it’s trickery that works.
And on the vibes front, Flatpak feels like a way for app developers to reach an audience without having to deal with cross-distro issues, while Snap feels like a way for Canonical to avoid doing a competent job at packaging for their own distro.
You know, I really wanted to agree with the GP, but…I’ve had your experience.
On a whim, I tried Bluefin Linux, which is a containers-only Linux distro based on Fedora. As such, basically all the GUI apps are Flatpaks. I was expecting to need to use the Distrobox breakout lever a ton based on my experience with snaps but…I just…haven’t. Like, yeah, I’ve needed to break out Flatseal twice (I literally don’t even know how to do whatever the equivalent is on snaps), but basically, everything just works. That’s in stark contrast to me getting fed up with Ubuntu in 2024 in part due to basically any snap I wanted requiring --classic or some such to make sure it was less sandboxed.
Yes, I wish Flatpak could handle CLI apps, or at least that we had one mechanism to handle both. But I’d rather have one tool that does one thing really well, than one tool that does two things really badly.
I’ve had the same experience with Bazzite, another OSTree/Fedora-based distro that relies on Flatpak. It… just works. Surprisingly easily.
I wonder if I’m using the same Flatpak as everyone else. I love the core idea, and I really like having a way to sandbox programs on Linux, even if it’s janky.
But yeah, every Linux install I up Flatpak on eventually develops some weird problems. xdg-desktop-portal always ends up broken forever. I’ve accepted that if I want to send someone a file, I need to open up Discord in my browser (installed outside Flatpak, precisely for that reason). If I try to use Discord’s (Flatpak) desktop app, I just can’t send it. If someone sends me a file via Signal, I either ask them to send them some other way (Signal has no browser version), or I download it to my phone. For software more reliant on file access (e.g. Musicbrainz Picard) I’ve had to switch to a distro-packaged version.
I’ve had this issue on multiple physical computers, on multiple distros (musl Void and Debian), under multiple desktop setups (although all under the “X with no DE” umbrella… maybe I should see what happens on XFCE?).
A few months ago GPU acceleration broke inside of Flatpaks for me. This is something I’ve also failed to troubleshoot and fix, so I just can’t play Steam games now.
There’s more jank than that, and I tend to agree with most criticism of Flatpak I tend to see. I still like the project and I’m grateful for the work people have put into it, but ugh, I wish I could say that it works fine.
As for snap? I dislike and avoid Ubuntu, and I’ve been avoiding snap in particular because of the bad rep it has, so I’ve only used it once so far. It was an Ubuntu 16 box that I had to manually upgrade to Ubuntu 24, along with some software that needed to go through a lot of intermediary versions. I needed a bunch of specific versions of Go (and some other packages I don’t remember) during that process. They weren’t always packaged for the particular version of Ubuntu I was running, so I decided to try snap. It… just worked? The box was a mess (at first apt didn’t even work), and I had to hop through a lot of different versions of the snaps and Ubuntu itself, and I don’t think I ran into any issues with snap itself.
I’m still skeptical of it, because I’m skeptical of everything Ubuntu does, but it’s been a much better experience than Flatpak.
Signal does have a desktop app, it also exists in flatpak form (unofficially), and it is also broken by the current xdg-desktop-portal and electron-accidentally-reverting-portal-support-for-the-5th-time-now issues
Er, I meant a browser version - so I can’t open it up in my browser to work around Flatpak being broken. I could also just install Signal outside of Flatpak, but I prefer crappy sandboxing to no sandboxing.
electron-accidentally-reverting-portal-support-for-the-5th-time-now issues
…oh geez did this happen again? I feel like electron is more finnicky with it than upstream itself
xdg-desktop-portal always ends up broken forever.
One thing worth noting is that portals need some backend implementation to actually work, which is something that not all distros set up ootb. The installed backend, if any, and its own logs are definitely something to look at if you’re having problems.
xdg-desktop-portal itself-ish has had some really bad hits the last week or so
indeed xdp has certainly had its fair share of nasty bugs, I’m just presuming that OP probably already checked the logs for xdp itself at some point, so if the problem was persisting it would’ve been in an adjacent component.
I’ve never had these issues even when I used X11, but I’ve only tried them on KDE (both 5 and 6).
To quote myself on The Other Place…
Depends what you run, I suppose.
I have natively-packaged browsers: Waterfox and Chrome.
In Snaps I run less essential but workaday stuff: Ferdium (my multi-protocol messaging client), Slack, Signal, Telegram, Skype (RIP), Spotify. I don’t care if they can’t access my filesystem; I don’t want them to.
All are trouble-free for me.
I used to carefully remove all snaps, then do apt purge snapd, then block it from being reinstalled. After that I installed deb-get. And then I used that to get, install, and update all the apps I needed that weren’t in the Ubuntu repos.
It worked very well, but Ubuntu version upgrades were hazardous: the best result will be that the do-release-upgrade tool disables them all, the upgrade works fine, then you have to go through and manually re-enable them all, where necessary, editing the apt .list files to point to the new version of each app’s repo.
It was a PITA, and that’s why now, I recommend just leaving snap there.
Common FUD: it’s not FOSS. Truth: snap is 100% FOSS … all the tools to run your own snap store are included and it’s documented.
Could you provide a link for this? I searched for this and came up empty.
I did find https://canonical.com/blog/howto-host-your-own-snap-store from 2016, which is not what you described.
snapstore was a minimalist example of a “store” for snaps, but is not compatible with the current snapd implementation. As a result I have removed the contents here to avoid further confusion.
I also found instructions on how to set up a “brand-specific dedicated Snap Store” https://documentation.ubuntu.com/core/explanation/stores/store-overview/index.html, however this requires you to create a brand account on snapcraft.io and to register each snap that you wish to publish in your store on snapcraft.io. This is very centralized and walled-garden; it’s far from what was promised in that 2016 blog post.
By contrast, Flatpak allows a developer to create their own flatpak store, and it allows users to configure their snap client to use independent flatpak stores, all without anybody getting permission from RedHat.
Wikipedia continues to claim that the snap store is not open source. AFAIK this is still true.
You touched on this as well, but to my knowledge there’s no way for users to configure their client to use an independent snap store without modifying the snap source and recompiling. Which, of course, few are going to do. (And if you do this, you won’t be able to use the official snap store anymore, unless you also modify snap to support multiple stores.)
Could you provide a link for this?
I’ll see what I can dig up. My source was a couple of years ago now, so I may need new links.
I’ve come to agree with you.
I think snap has suffered a classic case of “outdated opinions held strongly” or something to that effect, because you hear the same talking points over and over again from people who are clearly just parroting what they’ve heard other people say. A lot of peoples’ criticisms of snaps in particular don’t have any basis in reality as far as I can tell.
After switching to Ubuntu and deciding to just accept things the way they are (mostly out of exhaustion with this entire space, admittedly), I’ve found snaps to be totally transparent to me; pleasant, even. And even if you’re someone who hates auto-updating, well, you can turn that off. Personally, I like having my Firefox and Thunderbird and whatnot just automatically kept up to date; it always tells me when it’s going to do the update and never forces me to close the app. I also like the new Security Center in Ubuntu allowing you to manage permissions given to snap packages.
I can thank some random guy called Liam Proven coming on the podcast I edit for making me reconsider my opinion of sna—hold on a second…
Sidenote: df and blkid on Ubuntu aren’t cluttered with snap entries anymore. Not sure if they still are on other systems.
A big part of that is because Canonical lost credibility and trust by gas lighting users. They shipped incomplete functionality that caused usability issues with very common software and then told users the bugs were features.
That’s absolutely fair. I think they burned a lot of bridges in the rollout and that has a lasting effect on peoples’ perceptions of Canonical and the stuff they stand behind.
I can thank some random guy called Liam Proven coming on the podcast I edit for making me reconsider my opinion of sna—hold on a second…
You should do the decent thing and link the podcast at that point. While I don’t agree with this point on snaps, it sounds like a podcast I’d enjoy.
I figured people here might not be so keen on off-topic self-promotion in the comments, hence why I didn’t link it ;)
Here’s the podcast episode I was referring to: https://linuxlads.com/episodes/126/
Thanks for sharing it. I enjoyed the listen and have added that to my feeds. I still don’t see a case where I’d prefer snap over appimage, flatpak or oci containers, but it was an interesting episode.
Sidenote: df and blkid on Ubuntu aren’t cluttered with snap entries anymore. Not sure if they still are on other systems.
Of all the complaints I hear about snap this is the only one that resonates with me. I’m tired of grepping out snap entries in df and mount and friends. I still see snap pollution on my system, maybe I need to update.
Oh and also that I need to invoke with sudo. It feels kind of dumb that I need to be root to install untrusted, sandboxed software.
I tried installing VS Code on Ubuntu recently for a demo. It defaulted to installing from Snap. The snap version crashed on startup. I didn’t find a fix for that, but reading problems other people have, it also lacks all of the permissions it needs to do things like talk to the Docker daemon so dev containers don’t work. Oh, and it also lacks the permissions to use ptrace, so debug extensions don’t work.
I tried instead adding the apt repo and installing it via apt. Worked flawlessly.
Sounds about right, TBH. It’s a text editor. A text editor shouldn’t have permission to talk to system daemons.
I am reminded of the fuss and hooha when Windows XP started to take over from Win98. “But I’m used to being the administrator all the time! It’s too much work to keep signing in to get permission to do things!”
And of course some made an admin account, logged in and ran as it all the time, got viruses or otherwise nuked their OS, and then they whined and whinged and complained that XP was no better after all and it was no more secure than 98 had been.
So, in Vista, MS introduced UAC, and basically compelled everyone to run as an ordinary user account… and the users complained about being nagged all the time.
But this was all 20-25 years ago and this industry has a remarkably short memory, so now, it’s all forgotten. And now Linux is getting sandboxed apps and something similar is happening all over again.
Ubuntu desktop is meant to be a Linux for human beings, meaning non-techies, meaning not a server. There’s Ubuntu Server for that – and Ubuntu Server doesn’t have any snaps in it at all, as far as I know, so this is not an issue.
In a smarter saner universe, the Linux world would have something akin to Windows NT domains and universal network authentication. SUSE had the chance – it effectively owned Novell meaning it owned NDS, a better domains than domains, a better Active Directory than Active Directory. When I started at SUSE, I had an @novell.com email address. Did SUSE allow signing into an NDS tree?
Of course it didn’t, because the combined forces of Micro Focus, Novell and SUSE have the deep technical vision of my mum. Who can just about operate her iPad.
The difference is that Windows had a privilege-elevation model when they introduced this stuff. As did macOS. The failure mode was either being told that the app needed permissions it didn’t have, so you could notify the distributor and they could fix it, or you’d get a notification about dynamic permissions and could elevate. The failure mode for VS Code is that none of it works, and you have to go to the forums to discover why. And then the fix is not ‘run it sandboxed but grant these permissions’, it’s ’run it unsandboxed’.
Of course, VS Code also lacks any kind of internal security model and grants all plugins all permissions, which doesn’t help.
VS Code is not just a text editor, it’s an IDE. An IDE shipping without permissions to debug processes is completely missing the point of an IDE.
MULTICS and Symbian both had better solutions to these problems than ‘modern’ Linux.
A fair point, but again, this is a tool built for a phone OS, used in a distro for end-users who do not develop code.
That is a concept of debatable merit and I think the way the industry has gone is rather tragic but it’s where we are.
Snap is not really built for packaging tools for developers.
That does not mean that snap is broken or worse. It means it is the wrong tool for the job.
Ubuntu Server doesn’t have any snaps in it at all, as far as I know, so this is not an issue.
LXD is packaged only as a snap application. It used to be APT, I believe, and then Canonical migrated everybody.
Ah, OK, fair point.
There are versions in openSUSE and other distros – I think including Debian but I haven’t checked – that aren’t, mind.
That was nearly fifteen years after Novell bought SUSE and began ditching its own product line.
If Novell had made NDS a standard feature of SUSE as soon as it bought it, launched with the next major version, Novell Linux Desktop 9 and SUSE Linux Professional 9 – in 2004, the same year the first versions of Ubuntu and Fedora Core came out – then by now SUSE could own the enterprise Unix market, and it could have bought Red Hat.
I deployed NDS on Windows NT 4 networks in the late 1990s. Zenworks system management came free.
Here’s how it worked:
All for free and included in your Netware 4.1 licence.
They could have done that with SUSE. The tech was there and they owned it. First boot, you give network credentials, and then the machine is fully provisioned with no further intervention.
4 years before Chef was founded, 8 years before Puppet, 9 years before Ansible.
Did it in fact even ship with an optional NDS client a decade later?
Nope.
A text editor shouldn’t have permission to talk to system daemons.
Why not? I may want to run a command from my editor to lock my screen (dbus), send a notification (dbus again) or rebuild an image from the file I am currently editing.
I do think that sandboxes, capabilities and minimal permissions are awesome ideas, but at the end of the day it’s my computer, not Canonical’s, not GNOME’s and not the MPA’s.
As you wish. You do you.
The point of projects like Ubuntu (and,. indirectly, Snap, Flatpak, etc.) is to make easier to use and safer FOSS OSes for computers so that that people have alternative choices to Microsoft that are free of charge as well as Free Software.
See Ubuntu Bug #1
https://bugs.launchpad.net/ubuntu/+bug/1
It is not to make tools for hackers, techies, or sysadmins. There are plenty of tools like that already. Ubuntu is based on on Debian. If you are happy with Debian, then go use Debian.
I think it is mean-spirited and petty to complain about tools that are designed to make life easier and safer for novices if you are not a novice. Saying “it gets in my way” when it’s not something designed for you at all is not constructive; it’s quibbling and cavilling.
Common FUD: it’s not FOSS. Truth: snap is 100% FOSS but the Canonical Snap Store is not. But all the tools to run your own snap store are included and it’s documented.
This is extremely misleading.
The evidence is in the outcome: nearly a decade after it’s introduction, nobody except canonical runs a snap store. Hundreds of people run flatpak repos. There’s thousands of thousands of apt repos. The centralization and vendor lock-in is by design.
These are not the actions of a project that has the best interests of desktop Linux at heart. Canonical has done the absolute maximum they can to prevent you from using anything but their snap store, short of shipping an obfuscated binary.
I don’t think a single one of those points is true.
But I have been and talked with senior Canonical representatives about this, as well as with Mark Shuttleworth himself.
If you can provide me with citations for these claims, I will take them up directly with the company.
okay, fine, I’ll bite:
ubuntu.com and snapcraft.io in their repo. There’s hardcoded URLs throughout the whole project.But in the end all of this is irrelevant:
The evidence is in the outcome: nearly a decade after it’s introduction, nobody except canonical runs a snap store. Hundreds of people run flatpak repos. There’s thousands of thousands of apt repos. The centralization and vendor lock-in is by design.
Canonical makes money (theoretically, at least) in a lot of ways from the snap store and is clearly disinterested in allowing anyone else to run one. That should really be plainly obvious. If they were open to the possibility of a vibrant ecosystem of snap stores, there would be one.
The short version appears to be “packaging is not yet solved”.
What are the more radical views of handling packaging? Or at least of qualifying the tradeoffs?
What are the more radical views of handling packaging?
Stuff like Nix and Guix, probably
Honestly, I have very low mental bandwidth these days, but I dipped my toe into the nix[os] waters a couple of years ago and I’m slowly building familiarity. I find I trust my system much more - because it’s basically specified in one file, and can be rolled back on boot with a couple of key strokes. Disk space usage can be high, admittedly, but even as a grumpy old dinosaur I have to concede that storage is cheap these days. It feels like other overheads are probably a bit lower precisely through /not/ having to wrap things up in snap or flatpak. The design of nixpkgs means mostly not having to wait for an upstream flatpak/snap build to get a binary.
What are the more radical views of handling packaging?
I hope it’s OK if I steal a comment of mine from elsewhere.
There is a “bigger picture” view of this which I think is important and relevant:
• AppImage encapsulates apps’ requirements using the app bundle format from the ROX desktop: https://rox.sourceforge.net/desktop/
• ROX borrowed the idea of app bundles from Acorn’s RISC OS, which is still around and is FOSS now: https://www.riscosopen.org/content/
• The RISC OS desktop treats folders whose names begin with a pling (!, an exclamation mark) specially. It expects a structure inside with an icon, a launcher script, etc.
• RISC OS also had an “icon bar”, a forerunner of the Windows taskbar
• One of the Acorn engineers who worked on RISC OS was head-hunted to NeXT Computer in California. He took his Archimedes with him.
Source: an interview I arranged – https://www.theregister.com/2022/06/23/how_risc_os_happened/
• About a year later, Steve Jobs demonstrated NeXTstep 0.8 with a Dock
• NeXTstep also has app bundles, demarked by a folder called $NAME.app instead of !$NAME
This is a pervasive and influential idea. It’s how macOS apps work and that can be traced to RISC OS.
NeXT style bundles are available and work on Linux if you have GNUstep. There are 2 extant GNUstep desktops:
https://onflapp.github.io/gs-desktop/index.html
https://github.com/trunkmaster/nextspace
But there is a distro which takes this idea much further and packages the entire Linux OS in app-bundle directories:
I think the makers of Flatpak, Nix, Guix, and Spack – https://spack.io/ – all really ought to take a deep look at ROX, AppImage, and GoboLinux.
What all of these do can be done better, in a more human-readable way, if you throw away ancient UNIX assumptions about filesystem directory hierarchies.
This was mostly not designed and was in historical fact accidental anyway:
Maybe I’m extremely cynical, but this very much feels like RedHat/IBM asking for volunteers to maintain software they just shipped with 10 years of support. It sounds like they need another head on the project.
Years ago, I wrote an on-screen display (OSD) desktop application for showing keypresses and mouse clicks (KmCaster). Someone thought a flatpack would be useful. I didn’t see the point. It meant: (a) maintaining two installation processes; (b) collating download stats from two sources; (c) trusting a third-party system to maintain package indexes over time; (d) adding yet another package manager to a system that already has a package manager; and (e) bloating the repo with another repo.
Years later, I still only see drawbacks.
There still exists a GitHub page having a large “Download on Flathub” link that goes absolutely nowhere because the package is unmaintained. Who makes the GitHub page go away?
Also, the image on that page is outdated, which would have been one more thing to maintain. In addition, the install instructions are four lines, compared with three lines to download and install without Flathub. My point being: Flathub adds an unnecessary maintenance burden (to some projects).