Appimages totally suck, because many developers think they were a real packaging format and support them exclusively.
Their use case is tiny, and in 99% of cases Flatpak is just better.
I could not find a single post or article about all the problems they have, so I wrote this.
This is not about shaming open source contributors. But Appimages are obviously broken, pretty badly maintained, while organizations/companies like Balena, Nextcloud etc. don’t seem to get that.
I’m a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:
Usability issues
GearLever solves all the problems mentioned.
Updates
There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.
The lack of repositories
Appimages don’t even have a central place where you can find them, not to mention download them.This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.
Lack of Sandboxing
That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.
Random location
[…] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.
I completely disagree with making the entirety of /home as non-executable, when
$HOME/.local/binis recommended by the XDG standard as a place to store executables. As long as$HOME/.local/binis in the XDG spec, I’ll continue storing my executables there. If you disagree, go argue with the XDG guys.Duplicated libraries
This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.
If users would really install every Software as Appimages, they would waste insane amounts of storage space.
Then it’s a good thing that they don’t right? What’s the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn’t really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn’t be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn’t be using Flatpaks either.
Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don’t even need to do anything special to get AppImages integrated nicely in your system, and there’s nothing stopping other distros adding these packages as optional dependencies - but it’s kinda moot at this point I guess since Flatpak has already won the war.
Personally, I’m pro-choice. If AppImage doesn’t work for you, then don’t use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it’ll die a natural death and you don’t have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution…
I agree with you on all but one point: I detest the argument that “storage is cheap”.
While true, it’s of no value to have 10 times the storage when all your apps grow 10 times in size. You can still only do as much as before but had to upgrade in between. This also means, it leaves behind people who simply can’t afford an upgrade and who have an otherwise running system.
On top of that, we live in a time where we should not waste resources, since the world already suffers enough.
I am therefore still a fan of optimizing software to be as efficient as possible.
That being said: carefully used AppImages solve one such issue for me. Not every application I use needs constant updates. I want to stay at a specific version. That’s easy with AppImages.
GearLever
Download from Flathub
Hehe.
Duplicated libraries
This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.
“Bloat” is one big topic around these newer packaging formats so definitely not a pointless thing to bring up imo. I don’t think it should be as big of a topic as it is (the actual issue here is fairly minor imo) but it is definitely talked about.
And flatpak (and snap I think) have much better tools to mitigate the space use issues.
GearLever](https://github.com/mijorus/gearlever) solves all the problems mentioned.
Sceptical but I will try it for sure.
It makes appimages less worse than Flatpaks though, so its only “badness reduction” for me.
There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.
The first is what I mentioned, such updates can be perfectly done by a central package manager. Did you ever try to seal off a Windows install using Portmaster, where every installed app needed network access for their individual update services? Just no…
Ans to the repos, yeah maybe, havent looked if they are as secure as a linux repo. But the concept of “it is acceptable to download software from random websites” allows for malware to fit in there. Only if you will never find a .flatpak file it is possible to be sure its malware.
But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.
All worse than bubblewrap. Containers are either manual af (like with bubblejail) or if you refer to Distrobox/Toolbox, unconfined by default. They have no portal integration and no GUI configuration apps. So it may work somehow but probably worse, more resource heavy and there simply already is something better.
Same for VMs. Keep an eye on Kata containers, but this is about least privilege, not some QubesOS system that will not run in a tablet, for example. Android uses containers, is damn secure, and runs on phones.
[non executable stuff]
This is about protecting against malware. Linux Desktops are built on a different logic. Any unconfined software can download a binary to localbin, copy a random desktop entry from usrshareapps to your local folder, edit the exec line and add that binary to it.
Or just manipulate your .bashrc, change the sudo command to read input, save to file, pipe input to sudo. Tadaa, sudo password stolen.
That concept of “users can change their home but not the system” is poorly pretty flawed. So any directory that is writable without any priveges is insecure, if you dont trust every single piece of software you run.
Agree that Snaps are a problem. Its only really problematic when repackaging is illegal though, of course annoying but the Spotify flatpak is a repackaged snap. Same as with appimages.
I should write the same about snaps, but I feel they are covered WAY better.
This tool also good
Dont spam please
AppImages can be signed. Flat pak is the lesser option for security
Feather Wallet is a great example of AppImages done right
Eh, I’ve always felt these solutions are complementary, or supplementary, rather than a “versus”. Each one, in particular cases, covers gaps the others can’t cover. The only one that’s unneeded is Snap.
For example, I like Flatpak. I like that I can get software from an authorized hub, much like with a package manager. I like that the releases of the apps in the hub are mostly well documented.
But no matter how nice Flatpak seems to be, its overreliance on “portals” and “buses” and “seals” comes associated with trying to over-engineerize my system too much for its own good. Every app I have ever tried on Flatpak, for example, doesn’t support audio, apparently because I have the godly, eternal, battle-tested ALSA and not the manchild’s crap that is PulseAudio. But since apparently PulseAudio is the GNome / Microsoft approved way to do audio on Linux, I’m
supposedexpected to have it. What’s next? systemd-flatpakd?OTOH, I picked up the AppImage for Freetube and not only do I get audio but it loads and runs noticeably faster than the Flatpak version. And since it’s an official release I know where can I trustably get an update from. Literally no downsides!
But I sure as hell am not going to go for an AppImage for an app from which I expect more integration with my desktop activity, such as say a code editor or an advanced image / model viewer. Not if I can help it. Because I am going to be expecting to be able to stuff like drag and drop, have a correct tray icon, etc.
So that means I have to keep an eye on both solutions.
Hey, at least I’m avoiding Snap!
Now if there’s an AppImage for Steam somewhere… maybe…You got me in the first part XD
No joking, apart from that
But since apparently PulseAudio is the GNome / Microsoft approved way
I think I understand your point.
Pulseaudio is outdated, Pipewire AND Pulseaudio are now needed. Maybe also just Pipewire, and you can somehow fake Pulseaudio?
I never used a system without Pulseaudio, and Fedora has both (?) Or just Pipewire.
Pulseaudio is the old stuff that apps want to use, pipewire is the new cool stuff (I recommend qpwgraph) which allows like everything.
Aaand it is not overcomplicated, it isolated apps and introduces a permission system. Privileged programs that channel the requests and permissions, and sometimes need user interaction. Its actually less chaotic, the problem simply is that Flatpak ALSO tries to run all apps everywhere. And apps are mostly not up to date, so Flatpaks have randomly poked holes everywhere.
Today I worked on hardening configs for my apps. I maintain a list of recommended ones here. I will just put my overrides in my (currently still private) dotfiles, will upload them some day.
I am for example now Wayland only. Not all apps want to, but with the correct env vars (which I just globally set for all flatpaks, hoping it will not mess with anything), all apps use it.
This makes the system way faster, and applying different vars on the apps is very easy with Flatpak.
Literally no downsides!
Not true. It still has no updating mechanism, the binary may be official, but the rest are random libraries that may not be well versioned or controlled, etc etc.
The post is specifically about upstream supported Appimages, while Flathub is mainly maintained by the same 4 peolple (it is crazy). The request is for upstream devs to maintain Flatpaks.
But for sure not everything is nice. Runtimes are too huge, outdated apps cause huge library garbage, downloads are inefficient, …
I use Appimage this is a tool which make it easy to install Appimage and update it
AppImages are great and easy to use and they can be very easily archived. Today I tried to archive a Flatpak package (yuzu) and it was a pain, complicated and gave up in the end. I end up archiving multiple versions of the AppImages and continue using the Appimage for this emulator. Also sometimes Flatpaks do not work correctly, and I (and any other user) have to figure out what settings and configuration, rights and other stuff is needed to setup with Flatseal. Recently I solved the open links issue with Flatpaks, and found out a certain portal was required to be installed. Also sometimes the theming is not correct too.
All in all, I use Flatpak still and AppImages too, each for their own reasons. The lack of repositories and not needing an installation for being functional is not a problem with AppImages, because that’s the entire point of it. They can be automatically generated and ready for download, regardless of any repository, directly on Github from the developers. There is even a program, RPCS3 (a ps3 emulator), which can check and update itself and list all changes since last update.
If you download AppImages from shady places, then off course its shady and insecure. Just like installing any software without knowing what you are doing is insecure. So that’s not a point against the format itself. The argument “Duplicated libraries” is hilarious, if we speak about AppImages vs Flatpak, because Flatpak has duplicated drivers (especially with Nvidia, I know how bad it is because I had Nvidia cards before) and desktop environment versions, just because certain versions of the application needs it.
I don’t understand these evangelism for packaging formats. Flatpak, AppImage, native system packages and other formats have their own uses and are all useful and not bad.
I agree with this, but as an app developer, can I just say, Flathub’s documentation is an absolute abomination. It is so bad, that I’ve tried 3 times to publish an app and have given up each time. I can build a local Flatpak just fine, but getting it on Flathub is just so convoluted and bad.
AppImages are ridiculously easy to build and distribute, just a pain to actually use. And even then, they’re not that much of a pain.
Try getting Creality Print to run without manually updating components of the appimage. I’ll wait.
This has nothing to do with my comment.
Uhh ok pal, sure thing.
Bro, a developer (which I am not) voiced his opinion. What’s the need for the toxicity? Isn’t it better for everyone if we all ask questions or provide our opinions respecting others? This is the reason why ANY difference of opinion ends up turning into a heated and useless argument. If you have something to counter what he said, by all means, bring it to the table. @hperin didn’t say anything out of place.
I think you’re both on something either really good or really bad. I added to the sentiment about appimages and you’re both too busy sniffng your own farts too actually read the very short thing I wrote. You’d rather create a narrative in your own head about what a big meanie I am. So be in it then.
In conclusion, screw both of you, you’re blocked. I have only marginally more patience for stupid than Linus does and you’re both well past that. Have a nice day.
One specific implementation by a terrible company that can barely manage to check quality control on their actual products isn’t a very good example of appimage’s problems.
Not saying they don’t have problems. But having seen creality’s version of Marlin, I gotta say, I’d be willing to bet they rebranded something, but using vastly out of date versions.
Probably should switch to simplify3d, prusa or cura.
While you’re not wrong, the problem I was referencing is an outdated library embedded in the image. It makes the whole app crash and it could happen to any app.
