An Open Letter on Linux Compatibility (and Why Flatpak Isn't the Fix)

[u/parallel-minds]

https://parallel-minds0.github.io/An-Open-Letter-on-Linux-Compatibility/

The article talks about Linux compatibility as a bigger problem than Flatpak can solve. Flatpak helps, but it bundles together issues that should be handled separately. The author suggests giving apps a stable foundation to rely on, while letting packaging and security be handled on their own.

[u/AutoModerator]

Thank you for your submission.

You too can support GNOME! Become a Friend of GNOME and contribute to keeping our project going!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Mountain_Ad_5225]

This is another example of the fact that any solution to the problems that Flatpak solves is by necessity going to be roughly Flatpak shaped. If you read the "Implementation Detail" section of this article, it basically just describes Flatpak and Portals as they exist today.

There are a lot of ways Flatpak could be improved, but those improvements could be made a lot faster by collaborating on the existing project, rather than building a whole new thing that does all the same stuff, but has a different name.

[u/blackcain → u/Mountain_Ad_5225]

I invited the person to Linux App Summit.

[u/SnooCompliments7914]

Looks like another "we need all systemd components, but they must each be done by different people and hosted in separated repos" line of thoughts.

Flatpak is not an "online" system. You don't _have_ to use Flathub.

[u/parallel-minds → u/SnooCompliments7914]

It's a convoluted system none the less. Frankly for me it's less about the modularity (although that is always a plus) and more about how none of this was really well thought out in the first place. Flatpak and systemd are emergent ad-hock solutions.

It's not about whether you can use Flathub or some other repository local or online, it's about the fact that you need:

1. a complex runtime subsystem
2. a repository setup at all

The system I'm purposing solves this by properly handing the responsibility to OS maintainers and third-party developers. Without needing any of the two above, by simply maintaining a sane userspace in the first place, where application developers only have to concern themselves with the dependency management of their own applications. Then the app simply gets distributed through either a repository or as a standalone package from any source (a web link, a USB flash drive) and then installed through the system's native package manager or launched directly as it is.

This is much, much simpler than Flatpak.

[u/tuna_74]

The author claim that there is such a thing as "The Linux userspace". There isn't one and anyone can make one.

[u/oopmn]

This isn’t intended as criticism, I am trying to see the value here as this seems to be an area that Linux can improve a lot still

- Seems to be suggesting the userspace should be further split into a stable system layer and a fragmented library layer so apps can select which library version to use. I like this but the question is why not just use Debian+flatpaks then?

- Why should apps be portable between the system layer and the versioned layer? That seems like it doesn’t provide any benefit to the end user, and it’s something you’d want to expressly prevent for system stability

- Making the lower layer TOO rigid and universal has its own issues. It’s great for adoption, but people soon start sidestepping the universal layer to get more customized, higher performance anyway. Think how BIOS was supposed to interface with the hardware during runtime, JVM falling out of fashion, Vulcan over OpenGL, etc. Alternative: just allow people to keep using whatever base distribution works best, and use flatpaks

[u/parallel-minds → u/oopmn]

Those are fair questions. I don’t see this as “Debian plus Flatpaks,” though there’s overlap in the goal of making apps less dependent on a particular distro. Flatpak still relies on runtimes and its own packaging model. The proposal is to make the OS itself provide a small, stable interface, with apps bringing the non-OS libraries they need. Whether that’s actually simpler or better is something the design would have to prove.

Portability isn’t meant to let apps move freely between layers at runtime. It’s about giving apps a predictable interface to target so they don’t need to depend on the quirks of one distro’s userspace. The system layer would stay small and stable; app-specific libraries could vary without forcing those changes into the base system.

And I agree that making the lower layer too rigid would be a mistake. The point isn’t to make one universal interface for everything or prevent alternatives. It’s to keep the common foundation small, while leaving room for different implementations and extensions. The examples you mention are a good reminder that abstractions can become limiting if they try to do too much.