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…
This is how you bring your thoughts to the table. Awesome information that I certainly did not have. Thanks man.
I agree with you on all but one point: I detest the argument that “storage is cheap”.
While true, it’s of now 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.
(any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes)
While I overall do prefer Flatpak over AppImage these days, the sandboxing has indeed been giving me more trouble than I think it is worth so far.
Ate em up
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
Oooh yes, let’s throw some mud in the gaping holes of this packaging solution, spit and tape the rest to make it do something it was not designed to do. Brilliant idea! ☺️
AppImage is great at what it does - provide an ultra-low effort packaging solution for ad-hoc app distribution that enables a developer who won’t spend the time to do rpm/deb/flatpak packaging. There are obvious problems, security and otherwise, that arise if you try using it for a large software collection. But then again some people use things like Homebrew and pacstall unironically so …
Great, now tell me why your appimage is complaining about not having some .so file on my system
The developer made extra low effort and missed a lib. 😅
But then again some people use things like Homebrew and pacstall unironically so …
Thank you for mentioning this! Unfortunately a quick search on the internet didn’t yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!
Post about homebrew by Jorge Castro
I am not sure how secure it is.
I am aware that Homebrew has become the go-to solution for installing CLI applications on Bluefin. Which is exactly why I feel compelled to ask the question in my previous comment.
Btw, I don’t really understand why you felt the need to share Jorge Castro’s blog post on Homebrew? AFAIK it doesn’t go over any security implications. Sharing the article would only make sense if Jorge Castro is regarded as some authority that’s known to be non-conforming when security is concerned. While I haven’t seen any security related major mishaps from him or the projects he works on, the search for the CLI-counterpart to Flatpak seemed to be primarily motivated by facilitating (what I’d refer to as) ‘old habits’; which is exactly what Homebrew allows. It’s worth noting that, during the aforementioned search process, they’ve made the deliberate choice to rely on Wolfi (which is known for upholding some excellent security standards) rather than Alpine (which -in all fairness- has also been utilized by Jorge for boxkit). IIRC, people working on uBlue and related projects have even contributed to upstream (read Distrobox) for patches related to Wolfi. So, there’s reason to believe that the uBlue team takes security seriously enough to work, contribute and deliver on more secure alternatives as long as it doesn’t come with a price to be paid by convenience. Which, in all fairness, is IMO exactly why Homebrew is used for in the first place (besides their recent utilization of technologies that have similarities to the ‘uBlue-way’ of doing things)…
I’m not a security expert but I do know that the Homebrew is working with openssf on security: https://openssf.org/blog/2023/11/06/alpha-omega-grant-to-help-homebrew-reach-slsa-build-level-2/
Boxkit predates wolfi so it’s still alpine, I’ll probably replace it at some point but most of the forks of boxkit are because people want the premade github actions and they end up replacing it with whatever distro they want anyway. The wolfi connection is because I know the people who work there (including a ublue maintainer) and we have similar goals/ideas on how linux distros should be put together. My ideal dream is a wolfi userspace systemd-sysext on top of fedora base, then we can have our cake and eat it too!
We’re not security experts but lots of us work in the field and that gives us access to peer review from experts when we set things up. We sign every artifact with sigstore so users can verify that the code used in github is what’s on their image, that sort of thing. And most of our practices utilize CNCF governance templates that lots of other projects use.
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.
Totally understand that. Development docs are so needed.
If worst comes to worst you can just distribute your .flatpak file directly, as you would with your app image
what are flathub issues? IMO it’s easier than putting your app in Debian…
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.
You too bud. A great week actually.
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.
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 don’t get why we didn’t just do it macOS style; bundle everything into one directory with a standardised structure and wire up file managers etc. to run the correct executable inside it.
Because the FHS is a more sensible organization of files. Not every user needs to have their own executable for each program, that’s a mess.
I use Appimage this is a tool which make it easy to install Appimage and update it
When the description of a program on gh gives you more headache…I think its not doing a good job.
I do not agree. AppImages can be double clicked and executed. They are not a pain to use. I have a few dozen AppImages besides a few Flatpaks and plenty native packages on Debian. Comfortable setup that carried over from Ubuntu LTS.
This poster advertises GrapheneOS propaganda, and I never take those security weirdos seriously anyway, so either way I do not consider their security arguments as valid. All of these people have a common theme – pushing people towards becoming dependent on them, their “repositories” and apps, forming cults around it and becoming self-approved security gurus and dishing out moronic advice.
If there was a way for these people to be able to rebrand one of the non-native packaging formats, they would shill the fuck out of it, just like GrapheneOS.
AppImages can be double clicked and executed. They are not a pain to use.
i can understand that, but flatpaks are easier to upgrade and automatically integrated into your package manager, which (i believe) isn’t as straight forward for appimages. also there’s one major repo where you can find most apps (flathub) making app-hunting less daunting i feel like.
also, once your app is installed, it’s always in your system menu, so that doesn’t change much in the long runComfortable setup that carried over from Ubuntu LTS.
can’t you carry over flatpaks as well? you can probably copy /var/lib/flatpak or wherever they store their stuff from one system to another, or failing that, save all the app IDs you have installed, and re-install them onto your new system, backing up ~/.var to keep all your data!
Flatpack puts all app data in
~/.var?? Ewww! No thanks.
AppImages as a universal packaging format seem fun in that I’ve had loads of issues getting them to run properly on different systems. I’m sure they’re handy for some stuff but haven’t personally enjoyed them.
Does flatpack finally let me choose an alternative to
~/.var?The only use case for Appimages
If users want to carry applications around on a thumbdrive, or run on a fully immutable system like TAILS, Appimages may be needed. But this is the only target, and it is not a standard use case.I guess I agree. This is precisely the case where I have ever used them. Namely to have a portable executable of my password manager on a stick together with a backup of the password database.
I had no idea they were being used elsewhere.
Some of these apps can’t work as flatpaks at all, because they require more access to the system, e.g. Davinci Resolve. AppImage allows that. I mean, heck, even Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives “outside” its sandboxing. So, yes, there are cases where AppImages do serve a purpose. Not most cases, but a lot of cases.
Are these access problems not solvable with XDG portals?
because they require more access to the system
afaik, you can allow more system access to flatpaks
Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives “outside” its sandboxing
i believe flatpak also does that, you can specify some paths from the host to be available to the flatpak
As a humble linux user of the last year or two my experience has been that anything that is not in the Debian repo is a confusing nuisance. Nobody told me how to get appimages to integrate with my desktop. I had to rummage the internet and learn how. Compare this to a single click in Gnome software or simple command in the terminal for apps in the repo. I also installed flatpak, so I could get programs that weren’t available in the repo but nobody told me I would have to install and rummage Flatseal to enable them to work properly, that it would make my backups and restores take 900% longer and would rinse my data when they need updating. It’s been annoying enough that I’ve ended up learning how to install from source as well. Maybe it’s cool that I’ve learned how to do all this new stuff but to be honest I just feel like I’ve had to do loads of extra head-scratching and unnecessary work. I did it willingly because I’ve been committed to not being held back from using open source software but I couldn’t expect my friends and family to do any of this, so if I do get them onto Linux I can’t recommend these programs to them.
Current tier list:
- Debian repo
- .deb downloaded from a website!
- Enjoy using application, go for a bike ride.
- Make sure I’m free for a couple of hours, install from source.
- Appimage
- Do without given application
- Flatpak
You shouldnt need Flatseal as Flatpaks should have as little restrictions as need to make them work properly.
This is an app problem, on Android all apps start with 0 permissions and many work completely without.
I maintain a list of flatpak apps following modern standards. Those dont just work because their sandbox is full of holes, but because they are adapted to use portals etc.
So Flatseal is used to harden flatpaks, not weaken them, normally.
that it would make my backups and restores take 900% longer and would rinse my data when they need updating.
You mean their storage space? Yes, biggest problem. Not very well solved tbh compared to android where all apps are also sandboxed but they have sizes of 30MB or something.
Flatpaks should be preferred over many other formats though, as they just work, dont touch the system and are more secure, unlike Appimages.
I highly recommend to watch this talk that some commenter mentioned
Thanks for the links. I really want flatpak to work for me because I like the sandboxing but the storage thing is a bit of a killer for me at the moment and I could not for the life of me get Digikam, Shotwell or Rawtherapee to hand image files over to GIMP with the flatpak versions, whereas the repo versions were fine out of the box. Also, I feel like flatpak programs are much slower to open but that might just be me.
Flatpaks will always be a little slower, notably if you are on slow storage media.
Yes this is all native messaging I suppose. Flatpak apps can query an app list, just look at flatseal. So I think querying the installed flatpaks and handing it over to the system portal where you then choose the desired app is the modern workflow for this.
You might want to request that Digikam etc. implement portals for this file opening. Firefox can do for example but of course these are limited as long as apps dont modernize their workflow
I do hope flatpak can solve these things. I have the deb installs all working harmoniously at the moment, so I don’t want to touch them but will have another look at flatpak versions at some point in the future.
Downstream Distribution is simply very very work intensive. By having the system and apps come from a downstream origin, packagers need to follow upstream and keep up with versions. And as upstream doesnt officially support these packages, many will have bugs. Or like on Debian, packages will be unusable as they are too old with unfixed bugs for years.
Neither Android, nor Windows nor any other big OS do things that way, for a reason.
deleted by creator
Now I WILL get judged for this but hear me out… AppImages are useful for apps that will not get on Flathub. If you have an app that cannot get on Flathub (like a pirated Minecraft Launcher), you will be thankful developers are using AppImages for them. In this case, they’re unlikely to use snaps (alt repos for snap are possible but difficult from what I’ve heard) and maintaining a flatpak repo just seems like overkill for a single program. So for cases like these, I’m glad to see these packaged as appimages
Okay fair point. Piracy, illegal content etc. will all get removed from Flathub.
Similar to another comment about archiving software that may get removed
Well you can just put a flatpac on a website and let download it from their right?
Yea im pretty sure flatpak suports bundles that you can install directly, just like an appimage
You can, but it seems to be not documented how to get a .flatpak from an installed app.
As far as I know flatpak applications can be distributed as a file without the need for a repository, just like .deb or .rpm files
Can they? I’ll be honest, I’m not that familiar with how flatpak works on a more technical level.
Counterpoint: I don’t like having more than one package manager on my system, which means things like Flatpaks and Snaps are out. With AppImages, I just double-click on the executable and off it goes.
I get that multiple package managers can be suboptimal (though I don’t have a problem with it as long as the integration is good).
But it still seems like a much, much better solution than just not having these applications managed by a package manager, as is the case with AppImages.
True. I would consider another package manager if it integrated into my system nicely and if I had more than a few applications outside my regular package manager. But I only have like two AppImages on my PC anyway, so I don’t mind updating them manually when I need to run them.
That is the case for me with Flatpaks. They integrate really well into Fedora Kinoite - you have OS updates and Flatpaks all in a central UI, everything works as expected from any “App Store”.
Most shortsighted answer of the day. Great now you have this outdated executable on your system and you mabye are not even sure this was installed through appimage, because how should you know when your launcher is not telling you anything? golfclap
