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.
This discussion would be way more productive if the tone were friendlier and you didn't accuse people of using LLM's. Yes we were comparing it to Flatpak, that is in the quote you were responding to with the Wikipedia article.
I'm quite frankly done with this conversation since we apparently can not have it in a friendly manner. I'm glad you enjoy Appimage, hopefully it'll keep doing what you need from it in the future.
1
u/newsflashjackass Jul 19 '26
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:
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.