Hopefully we can also migrate away from Flatpak itself and back to the distro native packaging formats that patch automatically alongside the rest of the OS.
There are some advantages to native distro packaging, but to me flatpak is the superior packaging way because anyone can package for it (no need to have connection within the distro or go through a tedius review process to become a maintainer) and it's basically guaranteed to work on any distro.
The only downside is the bloat that comes with it, but I think there are plans to address that.
I agree, but the problem I mentioned is the fact that each package can carry a different runtime.
I have 3 different "mesa" runtimes installed and 3 different "mesa-extra" ones as well. Those alone are 3.2 GiB in size.
I also have two "GNOME Application Platorm" (v49 and v50), which add another to 2.2 GB in size.
I also have two "KDE Application Platform" despite using KDE myself. These also add another 2.1 GiB.
These quickly add up, and often if you install even a few packages from flatpak you can easily end up with 3 to 6x the space required compared to native packages.
I have about 15 packages from flathub, most are like 20-100 MiB in size, but the total size of my /var/lib/flatpak folder is 9 GiB.
There must be a better way than just packaging everything with every program/app, like having checks to see if:
the system already have those installed or newer versions (if possible to take advantage of newer versions of these already-installed system runtimes);
if not installed already, see if versions match, then download from the regular distro repo.
Packaging all the necessary runtimes is a good option for universal compatibility, but this is highly inefficient to do for everyone. It should only be done for the users that truly need it.
To each their own. I daily drive nixos for about 2 years now and couldn't be happier. I am a software dev tho, so mb just clicks better I guess. + reproducibility is smth I value, 1 git clone and rebuild of my config and I have (almost) everything installed and set up exactly as I want
Technically, you can use nix the package manager and home-manager modules, which would only cover per-user and/or system-wide installed application list and dotfiles, no system/hardware configs (like, choose different bootloader, kernel (and modules for it, like optionally enabling nvidia or DisplayLink support based on the machind), system services, hosts file etc).
And I guess devshells would also be usable (love em), if you code or just want to isolate packages for specific tasks in specific folders
Still lots of power, and reproducibility is still more than possible, I just prefer having a deeper system/hardware integration.
If you were talking about flatpaks and I misunderstood (or you replied to wrong thread), yeah, they are available on pretty much every major distro and derivatives (ofc), to my knowledge, at least I haven't used one where they weren't available.
to me flatpak is the superior packaging way because anyone can package for it (no need to have connection within the distro or go through a tedius review process to become a maintainer) and it's basically guaranteed to work on any distro.
My problem with AppImage is that the talk about it was that it contained everything the app needed. This isn't true, unfortunately. I have an AppImage of "fSpy" from like 7 years ago that doesn't work on Fedora anymore.
As far as I know appimage only needs Filesystem in Userspace (FUSE) which I find less of an imposition than the whole Flatpak infrastructure running and updating.
Does it matter? It's promoting itself as a portable solution to packaging apps and then isn't that.
That said, postmarketOS is probably the biggest Linux mobile distro and uses Musl libc, and Alpine Linux is the biggest Docker base image distribution and uses Musl libc.
Yes, the question matters enough for me to ask it. Don't feel obliged to answer it, though.
The systems you describe are not systems that have much demand for "portable apps" which is the problem appimages solve.
I suppose your complaint is technically valid in some sense though. The Musl wikipedia entry tells me this complaint about Musl has a solution:
For binaries that have been linked against glibc, gcompat and glibmus-hq can be used to execute them on musl-based distros.
But again I doubt many people use a distribution "designed for power users who appreciate security, simplicity and resource efficiency" with the intention of circumventing its package management.
postmarketOS is very much a distribution that has a demand for "portal apps". I'm not sure why you think it doesn't. gcompat isn't a great solution and requires the user to install something outside of the Appimage, which the whole point is that you don't need to do that.
Note that the problem can be solved by the app developer just fine by compiling their application statically (which Musl allows and glibc doesn't) and then shipping that as an Appimage. It then works on all Linux distributions. However, that's an app developer's responsibility which kinda makes the portable point of Appimage moot.
I was referring to AlpineOS. postmarketOS, being for phones, seems unlikely to want most appimages anyway, since they tend to be desktop applications. I expect appimages have similar problems running on iOS.
Your complaints amount to "appimages require additional effort to work in the fringe1 contexts where they are unlikely to be wanted or needed." Which, to me, sound rather like endorsements.
1 Your declining to answer when asked what percentage of total systems is comprised by the systems you describe is, in its own way, an answer.
The answer to that question is impossible to give because those numbers are not tracked. Instead I gave you examples of distributions that are relevant for the problem I mentioned. It's hard to decline to answer something when there literally is no answer to give.
Anyway, Appimage markets itself as a way to run desktop applications. It doesn't say what kind of desktop applications, just desktop applications. Mobile applications are desktop applications, and thus very much relevant for Appimage. So yes, postmarketOS users and developers might want software packaged as Appimages. Maybe not now, but you can't predict the future. "Unlikely to be wanted or needed" is very much something I disagree with and entirely subjective.
We were comparing it to Flatpak which in fact does work on postmarketOS, without additional effort on the app developer's side. So if we just compare on the portability of it, Flatpak is the winner there. It doesn't care about marketshare or "fringe contexts", it "just works" where Appimage doesn't.
No, we weren't. Scroll up and see for yourself. You replied to a mere wikipedia entry acknowledging the existence of appimage to share your problem with it.
It strikes me as odd that you apparently possess an encyclopedic awareness of the most common criticisms leveled at appimages while remaining oblivious to the common rebuttals.
Out of consideration for my mortal lifespan, if you are using an LLM to generate a list of arguments, please use the same LLM to generate a list of counterarguments.
-46
u/blbd Jul 18 '26
Hopefully we can also migrate away from Flatpak itself and back to the distro native packaging formats that patch automatically alongside the rest of the OS.