> Wick started his talk by saying that it looks like everything is great with the Flatpak project, but if one looks deeper, ""you will notice that it's not being actively developed anymore"". There are people who maintain the code base and fix security issues, for example, but ""bigger changes are not really happening anymore"". He said that there are a bunch of merge requests for new features, but no one feels responsible for reviewing them, and that is kind of problematic.
I think Red Hat should really be stepping up more here, especially since with RHEL 10 they stopped maintaining a ton of desktop packages with the advice for users of those packages being "get the package from Flathub instead of from us" (see https://docs.redhat.com/en/documentation/red_hat_enterprise_... , search for Flathub). If that's Red Hat's attitude towards desktop software, they should be providing the resources to make Flatpak a viable alternative.
> A user's Linux distribution may still be providing an older version of Flatpak that does not have support for --device=input, or whatever new feature that a Flatpak developer may wish to use. Wick said there needs to be a way for applications to use the new permissions by default, but fall back to the older permission models if used on a system with an older version of Flatpak.
I'm glad he brought that up as a problem. I maintain a game on Flathub that has audio and controller support. Because of the limited permissions granularity, that means that the game is displayed as requiring arbitrary device access (--device=input is too new, so the Flathub maintainers don't allow it in packages yet) and being able to listen to your device's microphone (the audio permission doesn't allow only accessing speakers but not microphones). I hope that Flatpak adds backwards compatibility for permissions so newer Flatpak versions can start having more granular permissions.
Flatpak is probably the best way to distribute desktop apps on Linux. I say this as an app dev, a packager, and a user. At one point I maintained close to a dozen packages.
I eagerly waited for months to see what they would do next - what magical features they would introduce. I was active on the forums helping other users package apps, helped review Flathub submissions (since it was always the same problems each time), and started checking out what PRs were happening. Silence.
The months turned into years, and as more years came, I slowly fell away from engaging with Flatpak. I'm back to using the AUR for most things (Arch, btw), but I'm quite sad to hear the situation get spelt out. Flatpak really was revolutionary; bringing modern apps and painless distribution to all desktops - LTS or rolling release. But it hasn't really changed at all since it first took off years ago.
In case anyone ever seriously contemplates a new design, here's an anecdote:
Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents.
I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too.
However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better.
(This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)
Basically, he argues that application distribution outside of the distro (a la flatpak, snap, appimage) is just a bad model. The right model is the one distros have been using for years: You get software through the distro's package manager, and that software is packaged by people working on behalf of the distro. As he says: "Software distributions are often volunteer-run and represent the interests of the users; in a sense they are a kind of union of users."
The other issue, of course, is that in practice flatpaks/snaps/appimages never seem to 100% work as well as distro packages do.
Nice breakdown. I'm new to Linux and didn't know about this:
> Flatpak still uses PulseAudio even if a host system uses PipeWire. The problem with that is that PulseAudio bundles together access to speakers and microphones—you can have access to both, or neither, but not just one. So if an application has access to play sound, it also has access to capture audio
Years ago, I wrote an on-screen display (OSD) in Java for showing keypresses and mouse clicks[1]. Someone thought a flatpack would be useful[2]. 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[3]; (d) adding yet another package manager to a system that already has a package manager; and (e) bloating the repo with another repo.
I've installed flatpak to install VSCode/Codium to have an usable debugger for a Python project I'm working on. After some time tweaking VSCode/Codium trying to get the debbuger to work, just realized flatpak could be the problem. After another considerable amount of time trying different flatpak permissions, realized this is not a good use of my time. Installed the same packages from snap, and everything worked OK.
I've switched to a flatpak-based immutable distro lately. It's great when it works. But so many niceties don't work, and then it feels like my computer is not really the fantastic tool it should be. For example:
- I had to run around with a distrobox running WINE and a bunch of permissions and kludges to run an external tool for Godot
- I gave up on the flatpak for Firefox because it can't talk to my KeepassDX flatpak
- The Godot and Krita flatpaks are oddly unstable and crash more than they did on Windows (may just be Gnome or something)
- non-flatpak tools like AppImages and .rpms feel pretty dang grungy
I want to see more cool stuff with Flatpak so seeing the state it's in is kind of a bummer.
It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. macOS has an API to ask for permissions to add an interface/change routes.
I'm not an open source maintainer or even a dev, but it seems bonkers to me that with all the numerous distributions out there, all facing the same problem of package management, that they couldn't just refocus their combined efforts toward improving Flatpak and guiding it toward universal adoption.
Side note but I wanted to build a cli program on flatpak and I kind of couldn't.
I have unfortunately not read the whole thing but I just want these two things:
better cli support
better permission support as I have had some issues with permissions. Currently using nix-shell as a sort of substitute against flatpak because I just want to use ephemeral environments without any permission issue or smth. Like I do nix-shell -p obs-studio and run obs and then close the shell and be peaceful as I rarely use obs for example and dependency hell. I may have wrote the exact same comment in the past but I want to use archlinux so much but nix-shell is way more comfortable to use on nix(I know its available on arch as well) and nix has the same name but arch might have different name so IDK.
I'm currently using Slackware current. I use an approach of compiling from source or using AppImage. Things like Flatpak and Snaps are an opaque black box to me.
I have AppImages for things like Zoom, KeePass and LibreOffice. I don't need to keep updating them. They do what I want them to do. I have them on a separate partition. If I reinstall my system they're all ready to go out of the gate.
It's ridiculously simple.
I did try out Fedora awhile ago, but decided it wasn't for me. Why is everything a Flatpak? Just use the repo mechanism.
Never understood the point of flatpak, snap and the like. Can't you just distribute static binaries? They are not that hard to compile.
(I mean, from the distributing point of view. The sandboxing and resource management is a OS-thing that should be an orthogonal issue. Users must be able to sandbox programs that they don't trust, regardless to how they are packaged and distributed.)
I've been using Fedora 41 about half a year, and flatpak has not made it better.
Fedora 41 started with a bunch of apps distributed as rpm, but some of them have since been updated as flatpaks when I run 'sudo dnf update'. Splendid, except that the rpm apps, now a little out-of-date, are not deleted, which may be good or bad, but that explains why I have duplicate icons for the same app all over my desktop, and its pretty confusing trying to tell which is which, which is better, or how to manage the all the differences and conflicts, which Fedora 41 makes anything but scrutable.
The thing about the microphones and speakers getting tangled up, as explained in TFA, also was somethig of and for which I was unaware and unprepared respectively when I had some problem with the old-fashioned way and decided to install musescore as a flatpak.
I've been thinking about upgrading to Fedora 42, but this article is giving me considerable premonitions of additional inconvenience and incidental despair. Anyone
have this stuff under control?
It's too complex. An application format shouldn't need to rely on 5 different APIs to be secure. And the apps aren't portable. I think something like WebAssembly is going to be the way forward.
Flatpak’s biggest bug isn’t in the code, it’s the bus factor.
> Tons of features are stuck in merge-request limbo because there just aren’t enough reviewers, and if we don’t swap some “+1”s for actual PR reviews (or funding), we’ll be shipping apps in 2030 with a sandbox frozen in 2024 while everything else rides OCI.
I see the real utility these tools are providing to many folks, but ...
It just feels so ugly. Square peg meets round hole.
We built all these tools for defining security boundaries for user-installed applications, and it turned out that the Linux packaging/distribution landscape was such a wasteland that people spent a lot of time duct taping software distribution artifact reproducibility onto the security-boundary tools.
So now we're in this weird worst-of-all-worlds spot:
The simplicity, performance, and decades of work we spent to make it easy to develop powerful applications that run directly on userland is now bifurcated/trifurcated and a mess. The legibility of "I want to run an application that dynamically links a cryptography library; that library is provided by the distro and I know it is both patched and compatible with the rest of the distro" or "my application can access files/devices at /path/to/whatever and use those resources if it has permission to do so" is buried under tons of container indirection.
Meanwhile, as TFA explains in detail, the actual security/encapsuation boundaries that these tools were originally built for proved to be a fast-moving target for which tons of support is still missing years later.
We can see the possibilities of what could have been in other systems. Take BSD's pledge(2) for example: its approach is so aggressively oriented towards only solving the security problem that I can't really imagine a world where the pledge/capability system "grew" a packaging/distribution ecosystem the way Snap and Flatpak did. Or take plan9's approach: perhaps if we had modeled the entirety of the OS in such a way that the basic SysV permissions model (users, groups, files, permissions) covered as much as possible of applications' security sandboxing needs, then things like SElinux/snap/flatpak wouldn't have ended up being necessary.
The biggest thing that got us into this state wasn't the tools, though--it was the human stuff: the tensions between "distro/package repo maintainers are burnt out and want to support a relatively small number of dependency targets and ways to add things to the package graph on a given OS"; "app developers want to make complex software available to users as quickly as possible"; and "users are very willing to do insecure things to get new applications to run, but are generally unwilling to do complex things (configure/make, customize AUR sources, know what nix is) in order to install stuff".
Fast forward a few years, add a lot of false starts and other bullshit due to dueling desktop environments/compositors/audio systems, and where we ended up is not good.
The current situation is basically:
"Come on down to DLL hell but way worse, we have: tons of brittleness when apps want to talk to the rest of the OS (sucks for users--but only when apps need rare and advanced functionality like ... uuuh basic audio playback), all baked into highly complex container systems (sucks for application authors) aimed at delivering apps that each package their own look/feel/OS integrations (sucks for distro maintainers and consistency of UX) in massive "it's not actually static linking, I promise" images, each of which contains 75% of an OS, running on leaky isolates (sucks for the security patchers) with an update story of "just download the universe again" (sucks for bandwidth/CDN costs)."
Like, I understand how we got here. I get that it's better than the bad old days of "but which autoconf?"/"I just wanted to update my browser but then glibc-2.11-compat-compat-compat-but-for-real-this-time-FINAL updated and broke my bootloader". And I get that some of those areas might improve over time (e.g. OCI images help with redownload-the-world; eventually Wayland will percolate around and the container runtime X compositor geometric complexity explosion will die down; someday someone will finally fix universal D-Bus discoverability and security for the eighteenth time...).
But overall it is and will remain a mess at a fundamental, philosophical level. Seems like the Linux ecosystem did this in a maximally slow and fragmented way, which is nothing new. But it sucks to see such an "everyone loses" end state as the result.
Is there an active Flatpack community that is actually interested in it, in the same way communities form around distros and their repos? It seems like probably no…
I dunno. So far my experience with these third party store things (or whatever) is that occasionally Firefox gets switched to a Snap, requiring active intervention and possibly nuking my profile is I do it wrong. It is… pretty annoying.
If a packaging mechanism, respecting virtualisation had been capable of existing 30 years ago we'd have one. Now, given how the fracture lines run, we're fated to have three or more.
It's pythons virtual environment and pip-is-weak problem, magnified. It's homebrew or Mac ports or fink or pkgsrc.
Mechanisms designed after fork, are never fork neutral.
I use NixOS and Flatpak I found is the easiest way to install and update applications. The Nix model is great for system software, but not an ideal way of updating and installing desktop apps.
The only problem I've had is fonts installed system wide not being available in the sandbox, but this is due to how NixOS exports fonts and can be solved by telling NixOS to publish fonts in /usr/share/fonts.
If not Flatpak, what is the future for portable sandboxed applications on Linux? I would love a solution where I can run semi-trusted or untrusted applications (e.g. vscode+extensions) confident that it doesn't have uncontrolled access to whatever my userid privileges permit.
Biggest problem with flatpak for me is that it's not suitable for server-side software, which is well supported in Snap. Is that even planned at some point?
I think D-bus has many problems and isn't very good. I also think the sandboxing (of Flatpak and other systems) has problems, e.g. lack of some kinds of permissions (e.g. permissions that depend on command-line switches, permissions to execute user-specified external programs by popen (without the restrictions affecting them too), and more), inability to properly use character encodings, etc. There are other issues as well, even though I think that the sandboxed execution is not a bad idea in general.
it was really for cross-distro GUI desktop applications. I saw it's used in embedded linux projects that has no GUI, for its portability at a heavy price(flatpak is quite fat, it needs to install a full sandbox)
Interesting read. While Flatpak does work nicely for a lot of things, the downsides are real and have me almost preferring Snap for the most part. Flatpak terminal apps are annoying, the permissions thing is annoying, sound, etc...
Interesting that the creator is thinking about the next thing already.
Over here in Windows land I can’t fathom why you need something like Flatpak just so users can reliably launch and run a program. I mean trust me I understand that Linux is so broken it needs something like flatpak. But imagine saying you’re disappointed the Windows executable format isn’t evolving! Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be.
It still irks me that AppImages (the unambiguously superior choice) are not more successful than Flatpak or Snap solely because Linux users (in their characteristic laziness) are only used to getting their software from monolith stores and repositories.
For a long time, there was a pax debiana in my world. I used Ubuntu mostly (swapped to Debian and added Fedora towards the end) and the package management was really good. APT was a great tool and I got quite chummy with its ways. It was straightforward to keep my system updated and resolve dependencies. It was way smoother than any other updater system had been, even across major system upgrades.
I sort of lost it when snap started usurping stuff. I knew it was coming, because docker was already making inroads. Then we had flatpak and company. As an admin, as a system architect, I felt that's the point when I lost control of my system. It wasn't possible to know its update state anymore. It wasn't possible to centrally manage or monitor those updates. It became a free-for-all of self-updates and shadow updates. Ubuntu was also introducing livepatch and kernel updates that went outside the apt model.
I think that perhaps it became too great a burden for the major distros to be packaging all of their own downstream packages. Perhaps they saw the opportunity to offload some of that packaging burden on a really pro service that could just package everything, and make pan-distro packages available. If Debian and RHEL packagers are doing less downstream packaging, then perhaps they could focus on their core competencies. I noticed that nearly every Ubuntu package needed to include Ubuntu-specific tweaks, and basically when Ubuntu was already downstream from Debian, why should Canonical be maintaining every damn package themselves as well?
So what's the endgame for all this? Would apt or dnf/rpm eventually get abandoned and have them go all-in on a new system? Or does the proliferation and splintering continue? Many of us said that the beauty of Linux is our freedom of choice. Well there's too much choice. Look at Distrowatch and be paralyzed by not knowing what to choose. Windows or macOS on your desktop is easy to choose because there's... one of each.
When I visited Catalonia my friend took me to Carrefour. We strolled the aisles and I spotted pig-legs (jamon serrano) on every counter. A huge selection of eggs. Everything my stomach could desire. She led me into the olives aisle and gestured around to all the olives there. She said pick whichever I want. There were so many. They were all in fancy jars. I knew nothing of olives. I left without choosing any.
Linux will die a death of a thousand cuts, until some consolidation and unification can happen that's beyond the kernel.
Both flatpak and snap have been a bane with inconsistent behaviors, permissions bugs, and a bunch of stuff I never figured out. I got so frustrated with them that I wiped, put Debian on and just the old package systems.
Great, after bringing Pulse (+ Limewire to fix it), systemd, wayland, dbus, flatpak to dilute and overcomplicate everything, RHEL is now abandoning the desktop alltogether. Meanwhile, zero new desktop apps have been created for Linux in like two decades. Today even Firefox on Ubuntu and Fedora can't access a webcam for teams/gmeet because of permission problems of layered container frameworks that are there just to protect fictional, as in non-existant, apps from accessing your damn files. Seriously, the only way out and where progress has been made seems to be embracing win32 apps using wine/proton, but maybe using SteamOS/Arch instead since bazzite is based on fedora.
Linux has the worst software distribution model towards the general public of all OS. The one of windows (and probably MacOS but I don't know much) is also full of issues, but is still infinitely better than linux. When you compound the number of distributions, the number of their versions, the number of software, and their versions, you realize that having the distribution managed by the distribution or the software authors is unsustainable. In comparison, windows and mac only require at most 2 versions of the software each to reach at list 90% of the users.
I don't know if flatpak or appimage or whatever are a solution, and I cannot propose one myself. But I really think that at one point the linux model will completely fail if it doesn't improve
BTW I'm not saying that the linux model is always inferior. Actually it is often superior: in the server world were professionals take care of things, in the embedded world where the resources are scarce, the possibilities to configure and select everything to the smallest detail make it great.
The Future of Flatpak
(lwn.net)279 points by dxs 18 hours ago | 234 comments
Comments
I think Red Hat should really be stepping up more here, especially since with RHEL 10 they stopped maintaining a ton of desktop packages with the advice for users of those packages being "get the package from Flathub instead of from us" (see https://docs.redhat.com/en/documentation/red_hat_enterprise_... , search for Flathub). If that's Red Hat's attitude towards desktop software, they should be providing the resources to make Flatpak a viable alternative.
> A user's Linux distribution may still be providing an older version of Flatpak that does not have support for --device=input, or whatever new feature that a Flatpak developer may wish to use. Wick said there needs to be a way for applications to use the new permissions by default, but fall back to the older permission models if used on a system with an older version of Flatpak.
I'm glad he brought that up as a problem. I maintain a game on Flathub that has audio and controller support. Because of the limited permissions granularity, that means that the game is displayed as requiring arbitrary device access (--device=input is too new, so the Flathub maintainers don't allow it in packages yet) and being able to listen to your device's microphone (the audio permission doesn't allow only accessing speakers but not microphones). I hope that Flatpak adds backwards compatibility for permissions so newer Flatpak versions can start having more granular permissions.
Flatpak is probably the best way to distribute desktop apps on Linux. I say this as an app dev, a packager, and a user. At one point I maintained close to a dozen packages.
I eagerly waited for months to see what they would do next - what magical features they would introduce. I was active on the forums helping other users package apps, helped review Flathub submissions (since it was always the same problems each time), and started checking out what PRs were happening. Silence.
The months turned into years, and as more years came, I slowly fell away from engaging with Flatpak. I'm back to using the AUR for most things (Arch, btw), but I'm quite sad to hear the situation get spelt out. Flatpak really was revolutionary; bringing modern apps and painless distribution to all desktops - LTS or rolling release. But it hasn't really changed at all since it first took off years ago.
Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents.
I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too.
However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better.
(This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)
https://news.ycombinator.com/item?id=32936114
https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
Basically, he argues that application distribution outside of the distro (a la flatpak, snap, appimage) is just a bad model. The right model is the one distros have been using for years: You get software through the distro's package manager, and that software is packaged by people working on behalf of the distro. As he says: "Software distributions are often volunteer-run and represent the interests of the users; in a sense they are a kind of union of users."
The other issue, of course, is that in practice flatpaks/snaps/appimages never seem to 100% work as well as distro packages do.
> Flatpak still uses PulseAudio even if a host system uses PipeWire. The problem with that is that PulseAudio bundles together access to speakers and microphones—you can have access to both, or neither, but not just one. So if an application has access to play sound, it also has access to capture audio
That's a pretty decent sized hole.
Years later, I still only see drawbacks.
[1]: https://gitlab.com/DaveJarvis/KmCaster
[2]: https://github.com/flathub/com.whitemagicsoftware.kmcaster
[3]: https://flathub.org/apps/search?q=kmcaster - whoops!
- I had to run around with a distrobox running WINE and a bunch of permissions and kludges to run an external tool for Godot
- I gave up on the flatpak for Firefox because it can't talk to my KeepassDX flatpak
- The Godot and Krita flatpaks are oddly unstable and crash more than they did on Windows (may just be Gnome or something)
- non-flatpak tools like AppImages and .rpms feel pretty dang grungy
I want to see more cool stuff with Flatpak so seeing the state it's in is kind of a bummer.
It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. macOS has an API to ask for permissions to add an interface/change routes.
I have unfortunately not read the whole thing but I just want these two things:
better cli support
better permission support as I have had some issues with permissions. Currently using nix-shell as a sort of substitute against flatpak because I just want to use ephemeral environments without any permission issue or smth. Like I do nix-shell -p obs-studio and run obs and then close the shell and be peaceful as I rarely use obs for example and dependency hell. I may have wrote the exact same comment in the past but I want to use archlinux so much but nix-shell is way more comfortable to use on nix(I know its available on arch as well) and nix has the same name but arch might have different name so IDK.
I have AppImages for things like Zoom, KeePass and LibreOffice. I don't need to keep updating them. They do what I want them to do. I have them on a separate partition. If I reinstall my system they're all ready to go out of the gate.
It's ridiculously simple.
I did try out Fedora awhile ago, but decided it wasn't for me. Why is everything a Flatpak? Just use the repo mechanism.
(I mean, from the distributing point of view. The sandboxing and resource management is a OS-thing that should be an orthogonal issue. Users must be able to sandbox programs that they don't trust, regardless to how they are packaged and distributed.)
Fedora 41 started with a bunch of apps distributed as rpm, but some of them have since been updated as flatpaks when I run 'sudo dnf update'. Splendid, except that the rpm apps, now a little out-of-date, are not deleted, which may be good or bad, but that explains why I have duplicate icons for the same app all over my desktop, and its pretty confusing trying to tell which is which, which is better, or how to manage the all the differences and conflicts, which Fedora 41 makes anything but scrutable.
The thing about the microphones and speakers getting tangled up, as explained in TFA, also was somethig of and for which I was unaware and unprepared respectively when I had some problem with the old-fashioned way and decided to install musescore as a flatpak.
I've been thinking about upgrading to Fedora 42, but this article is giving me considerable premonitions of additional inconvenience and incidental despair. Anyone have this stuff under control?
> Tons of features are stuck in merge-request limbo because there just aren’t enough reviewers, and if we don’t swap some “+1”s for actual PR reviews (or funding), we’ll be shipping apps in 2030 with a sandbox frozen in 2024 while everything else rides OCI.
It just feels so ugly. Square peg meets round hole.
We built all these tools for defining security boundaries for user-installed applications, and it turned out that the Linux packaging/distribution landscape was such a wasteland that people spent a lot of time duct taping software distribution artifact reproducibility onto the security-boundary tools.
So now we're in this weird worst-of-all-worlds spot:
The simplicity, performance, and decades of work we spent to make it easy to develop powerful applications that run directly on userland is now bifurcated/trifurcated and a mess. The legibility of "I want to run an application that dynamically links a cryptography library; that library is provided by the distro and I know it is both patched and compatible with the rest of the distro" or "my application can access files/devices at /path/to/whatever and use those resources if it has permission to do so" is buried under tons of container indirection.
Meanwhile, as TFA explains in detail, the actual security/encapsuation boundaries that these tools were originally built for proved to be a fast-moving target for which tons of support is still missing years later.
We can see the possibilities of what could have been in other systems. Take BSD's pledge(2) for example: its approach is so aggressively oriented towards only solving the security problem that I can't really imagine a world where the pledge/capability system "grew" a packaging/distribution ecosystem the way Snap and Flatpak did. Or take plan9's approach: perhaps if we had modeled the entirety of the OS in such a way that the basic SysV permissions model (users, groups, files, permissions) covered as much as possible of applications' security sandboxing needs, then things like SElinux/snap/flatpak wouldn't have ended up being necessary.
The biggest thing that got us into this state wasn't the tools, though--it was the human stuff: the tensions between "distro/package repo maintainers are burnt out and want to support a relatively small number of dependency targets and ways to add things to the package graph on a given OS"; "app developers want to make complex software available to users as quickly as possible"; and "users are very willing to do insecure things to get new applications to run, but are generally unwilling to do complex things (configure/make, customize AUR sources, know what nix is) in order to install stuff".
Fast forward a few years, add a lot of false starts and other bullshit due to dueling desktop environments/compositors/audio systems, and where we ended up is not good.
The current situation is basically:
"Come on down to DLL hell but way worse, we have: tons of brittleness when apps want to talk to the rest of the OS (sucks for users--but only when apps need rare and advanced functionality like ... uuuh basic audio playback), all baked into highly complex container systems (sucks for application authors) aimed at delivering apps that each package their own look/feel/OS integrations (sucks for distro maintainers and consistency of UX) in massive "it's not actually static linking, I promise" images, each of which contains 75% of an OS, running on leaky isolates (sucks for the security patchers) with an update story of "just download the universe again" (sucks for bandwidth/CDN costs)."
Like, I understand how we got here. I get that it's better than the bad old days of "but which autoconf?"/"I just wanted to update my browser but then glibc-2.11-compat-compat-compat-but-for-real-this-time-FINAL updated and broke my bootloader". And I get that some of those areas might improve over time (e.g. OCI images help with redownload-the-world; eventually Wayland will percolate around and the container runtime X compositor geometric complexity explosion will die down; someday someone will finally fix universal D-Bus discoverability and security for the eighteenth time...).
But overall it is and will remain a mess at a fundamental, philosophical level. Seems like the Linux ecosystem did this in a maximally slow and fragmented way, which is nothing new. But it sucks to see such an "everyone loses" end state as the result.
I dunno. So far my experience with these third party store things (or whatever) is that occasionally Firefox gets switched to a Snap, requiring active intervention and possibly nuking my profile is I do it wrong. It is… pretty annoying.
It's pythons virtual environment and pip-is-weak problem, magnified. It's homebrew or Mac ports or fink or pkgsrc.
Mechanisms designed after fork, are never fork neutral.
The only problem I've had is fonts installed system wide not being available in the sandbox, but this is due to how NixOS exports fonts and can be solved by telling NixOS to publish fonts in /usr/share/fonts.
Oh, hey... I made that feature. Nice to see that other people want narrower permissions, too.
I do like AppImage better (it's simpler), but there's no equivalent of FlatHub, the discoverability is just poor.
Also, per TFA: https://m.xkcd.com/2347/
Interesting that the creator is thinking about the next thing already.
https://m.xkcd.com/927/
For a long time, there was a pax debiana in my world. I used Ubuntu mostly (swapped to Debian and added Fedora towards the end) and the package management was really good. APT was a great tool and I got quite chummy with its ways. It was straightforward to keep my system updated and resolve dependencies. It was way smoother than any other updater system had been, even across major system upgrades.
I sort of lost it when snap started usurping stuff. I knew it was coming, because docker was already making inroads. Then we had flatpak and company. As an admin, as a system architect, I felt that's the point when I lost control of my system. It wasn't possible to know its update state anymore. It wasn't possible to centrally manage or monitor those updates. It became a free-for-all of self-updates and shadow updates. Ubuntu was also introducing livepatch and kernel updates that went outside the apt model.
I think that perhaps it became too great a burden for the major distros to be packaging all of their own downstream packages. Perhaps they saw the opportunity to offload some of that packaging burden on a really pro service that could just package everything, and make pan-distro packages available. If Debian and RHEL packagers are doing less downstream packaging, then perhaps they could focus on their core competencies. I noticed that nearly every Ubuntu package needed to include Ubuntu-specific tweaks, and basically when Ubuntu was already downstream from Debian, why should Canonical be maintaining every damn package themselves as well?
So what's the endgame for all this? Would apt or dnf/rpm eventually get abandoned and have them go all-in on a new system? Or does the proliferation and splintering continue? Many of us said that the beauty of Linux is our freedom of choice. Well there's too much choice. Look at Distrowatch and be paralyzed by not knowing what to choose. Windows or macOS on your desktop is easy to choose because there's... one of each.
When I visited Catalonia my friend took me to Carrefour. We strolled the aisles and I spotted pig-legs (jamon serrano) on every counter. A huge selection of eggs. Everything my stomach could desire. She led me into the olives aisle and gestured around to all the olives there. She said pick whichever I want. There were so many. They were all in fancy jars. I knew nothing of olives. I left without choosing any.
Linux will die a death of a thousand cuts, until some consolidation and unification can happen that's beyond the kernel.
I don't know if flatpak or appimage or whatever are a solution, and I cannot propose one myself. But I really think that at one point the linux model will completely fail if it doesn't improve
BTW I'm not saying that the linux model is always inferior. Actually it is often superior: in the server world were professionals take care of things, in the embedded world where the resources are scarce, the possibilities to configure and select everything to the smallest detail make it great.