The future of flatpaks

community / off-topic comment:
If you love flatpak and Co., you may be interested in reading the following opinion piece:

1 Like

That is a pretty interesting piece. It is, of course, absurdly one-sided. It is basically a containerized application hit piece.

Ignoring the bias, the real problem is that Linux seems to be moving in the opposite direction from what he is proposing.

It seems like ABI stability is becoming increasingly less of a priority for many desktop oriented distros. Especially as rolling distros continue to become more prevalent. Even Fedora has limited ABI stability long-term.

I hope flatpak will fill in the gap until shared libraries are backward compatible enough, so that apps can switch back to use system libraries again.

In the early dates of .NET, it is not uncommon for one Windows installation to have two or even three versions of .NET runtime installed.


I’m not sure really … .NET has an interesting cross language library with update to .NET Core, Flatpak and Snap stabilize complexe libraries dependencies with Snap pointing to security issues. I believe that the way to go is C++ STL with version 20 and after pointing to the essential job of the compiler, something close to NVidia Cuda, Intel OneAPI, DP C++. I’m not a specialist, just learning but having apps just turning in the compiler, nowhere else than in memory reminds me of IBM road to memory inception with Power 10 chips …

I also think that the reason behind open source software is the ability to recompile indefinitely … at one point the compiler will send warnings about outdated this and that needing remedies. That excludes several library versions, you just use the current version approved by consortium of industry leaders or simple users.

Is a compiler open source?

Once upon a time, there was only one UNIX™, the Bell Labs version, no variants. Then Bell Labs made it available to some universities, and those universities made some tweaks. Then others decided to create UNIX-like systems, with some minor differences on the layer 2 and 3 APIs. This led to the point where application developers had to ‘ifdef’ their C code to allow it to build in different environments. At the point when I chaired the /usr/group POSIX system standardization committee to reunite the environments so that applications could proliferate, the ‘standard’ joke (pun intended) was that the great thing about standards was that there were so many to choose from.
The battle was won, there became a single standard (taken over by IEEE), for the POSIX operating system (syscalls) and the (C) application interface (libc et al).
Nowadays you can run Linux on almost any hardware platform, and the ease of creating and distributing software that has come from developments in build systems, packaging and distribution process has led to the current huge open source product environment benefiting so many. I’m happy that our small group of UNIX supporters made this early (1980s) standardization effort as a catalyst to where we are today.
Now we’re facing the same proliferation of higher level application class APIs, tons to choose from and all offering improvements over the previous generation. So many (standard) APIs and models to choose from.
The next step for open source developers is to continue to allow interesting new ideas and choices, but to eventually go towards the maturity model, narrowing the contenders for such as audio sources, syncs, filter APIs to something that no longer requires substantial effort from developers chasing the latest new model or API.
That’s my observation and opinion, as a software developer since 1963 and UNIX lover since 1976.


I was actually pretty interested when I read it and saw “I’m going to skip over things which can be fixed, and focus on fundamental flaws” and then… all the complaints are either “I think it will be too big on disk” or things which actually are being and will be improved.

It’s very expensive to do, and fewer and fewer (paying) customers are demanding it.

And, honestly, developers never wanted that. What they want is “a stack which matches exactly their chosen deps”. The “here’s your ten-year platform” thing comes from an operations side. And, in the modern world, that part of operations does not have the ear of most business deciders.

1 Like

The problem seems choice of API and ease of development frameworks … I’m just getting into AI and ML as the problem is not tools or what are we looking for but simply how going back to Ars Magna by Cardano published in 1545.

I can’t really comment on the technical side, and don’t know if he is correct in his assessment. I know next to nothing about this. All I can say is that the storage cost of flatpaks/snaps was a big deal to to me, and I was more open to flatpak once I understood how it reused its runtimes, but of course, that’s assuming they are doing it efficiently.

I also agree that this containers aproach adds a lot of complexity, and I don’t know if it could be done in a simpler way.

But I think the author is disregarding reality though. Other than someone who really cares, most app devs just want to ship their app without a hassle, and thats double for proprietary software.

This is the most out of touch thing he said:

How loudly do you think gamers would complain if a distribution upgrade broke their favourite game?

We have a real example of that, Rocket League simply dropped its Linux support because it was a pain to maintain it. Companies won’t go the extra mile to support a platform they don’t care about.

I don’t agree about that i think the main reason that we don’t get apps in native .Deb and .Rpm for all apps and most of the games are not supporting linux just because the userbase is very low in linux in desktop.but for the time being flatpaks and snaps are required to narrow the gap They will care mark my word and it will happen in next 5years linux will be a major player in the world.

You can read a reply to some assertions on that article.


I think this one is drifting really, really far off topic, everyone. The original Flatpak article has some pretty close connection since we’re heavily exploring that technology with Silverblue, Kinoite, etc.

But which versions of propriety and/or commercial enterprise OSes are or are not the best seems like a conversation for another space.


I think this is a great example of why we need a Watercooler category.


So, yeah, I’m going to close this. Right now is probably the closest place we have to a “Watercooler” area, and feel free to take this there.

Maybe discussion.fpo would have been the better place to have a fruitful discussion. Too bad the topic got hijacked and had to be closed. Can’t wait for a watercooler category… Happy Friday!