The issue is bloat, and duplication of platforms… One flatpak needs gnome 42 platform. Another needs Gnome 43. Another flatpak may need a different version of the Nvidia platform compared to another. Which all seem to be needing updated daily according to Discover…
Currently my 100gb /root partition is sitting at 20% filled. I can see that free space rapidly reducing once more duplications of flatpak platforms get installed…
@Brian_Innes Then perhaps I could interest you in a snappy distro??? 
It’s still a small price to pay compared to all the advantages. Paperdigits is right, disks are large and storage is generally very cheap. A 2TB SSD can cost as low as 150€. I’m not sure if it can be considered bloat if it’s working as intended… it’s giving you a safe, almost platform agnostic way to run applications that otherwise could fall behind and require large efforts to run again, see DisplayCAL.
My journey currently landed on Windows 11, of all things. The WSL runs Ubuntu 22.04 for all things command line and computing, while the desktop runs image editing apps.
Gnome on native 22.04 was giving me too much grief (constant crashes, that stupid, dumb, limited file browser), and I wanted to run some Windows apps. So for now, that’s what I settled on.
The WSL is shockingly smooth these days. It even starts graphical Linux apps natively in Windows with zero configuration. And you can call Linux binaries from your Windows scripts and vice versa. Of course the Windows file browser is in some ways even worse than Gnome’s, and let’s just not talk about the intrusive spyware that is Windows.
So the issue is that your using more hard disk space than you want, even though you’re nowhere near full? Sorta feels like you’re looking for problems. And if you look, you’ll certainly find them.
Snap packages are the devil incarnate!
As I said, the main issue is the duplication of flatpak platforms, and the massive amount of updates needed due the duplication of flatpak platforms…!
Not ideal!
You have the choice of using them or not. What I don’t understand is why complain about your choice.
While flatpaks are a “solution” (e.g Displaycal), they are not an ideal solution, in terms of bloat, duplication of “platforms”, download size etc.
@Brian_Innes Er… … I am absolutely certain that
I wrote snappy, not snap packagy At least
that was what I intended…
Swiftly Yours,
Claes in Lund, Sweden
Everything has a trade off, and the alternative here is to get the last version of Python 2, compile it, compile all the dependencies you need, fix any errors from those packages not being maintained, then get dispalycal and compile that as well. Then have a 10 year old, unmaintained stack running on your computer.
As someone who’s worked on the darktable flatpak, I like it because users get the latest software without much hassle and we are in control of the libraries used. Need exiv2 in the latest version with an optional flag turned on? No problem. Newer version of lensfun? No problem. It also makes troubleshooting easier because I know what’s there and I can replicate the deployment in my own environment.
I can also run stable and master side by side without issue.
Indeed. I’ve found for image processing software, the distro copies are almost always behind the current revs of most supporting libraries (excepting libjpeg, libpng, libtiff, those are pretty stable now). exiv2, libraw, and lcms are in that category.
That, and if you choose to compile the source you can have major headaches keeping libwhatever-dev out of your link, and use a more recent version of the library.
flatpack/AppImage/snap are like Windows installers in that regard, library-bloaty but insular in their dependency on the operating system. If you don’t want to make a hobby out of having the latest version, they’re the way to go…
Although another issue with Flatpaks, is you cannot launch one Flatpak application from within another. A good example of this is with the darktable edit in gimp Lua script…
Edit: Apologies, my original quick response was not helpful to the conversation. I would say Flatpak solves some specific issues, but are simply an option among many. If your distro has the native packages you require, then that would be the most efficient use of space. But DisplayCal for example exists in no useful form in any distro now, and it’s exactly for the problem you have with Flatpaks that it’s able to function this way, with dependencies that don’t exist elsewhere and that you don’t want other software using.
Actually not true at all. Just the way you launch flatpaks are different than the way you launch a binary from your system. You can see the RawTherapee flatpak, which has a few patches to enable launch the gimp flatpak. Basically you want to run flatpak run org.gimp.Gimp <some file>.
Personally I don’t understand why they use flatpacks. Wouldn’t it be possible to just build statically linked applications?
What do you think a flatak is, essentially?
The flatpak intro talks about bundled libraries, not statically linked ones.
Also, a plain binary would not come with its own filesystem…
It is interesting though, seeing how some graphics application developers seem to prefer Appimage (e.g. Digikam), while others prefer flatpaks or snaps if they do not provide native builds of the applications…
Maybe there will be another competing packaging system soon, FlatImage or AppPacks…
A lot of those who have appimages had the build script made by the appimage developer or by @Carmelo_DrRaw, not a Dev from the project themselves. I find appimage to be nontrivial to work with, it that’s just me.
Yay! I’m not the only one… 
I do essentially that for Windows, 'cept I then package the .exe files in a Windows installer file. The mxe cross-compiling environment gives me a completely static build suite, where the only dependencies are the core Windows kernel .dlls
Probably not so simple for Linux. There’s no single graphics API, and you’d be surprised at the nest of dependencies for things like XML parsing, regular expressions, file ops and the like in a lot of OS infrastructure code. Even the c/c++ libraries will be OS-specific. So, it’s probably impractical to get away from an “environment packager” like flatpak or AppImage, just to include the minimal core .so libraries.
The nirvana is this, had to dig a bit to find a static executable to demonstrate it:
glenn@bena:~/matrix$ ldd matrix-static
not a dynamic executable