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 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/bindirectory is recommended by the XDG standard as a place to store executables. As long as$HOME/.local/bindirectory is recommended by the XDG, I’ll continue to store 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 it 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 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.
Ate em up
(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.
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.
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! ☺️
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
This is how you bring your thoughts to the table. Awesome information that I certainly did not have. Thanks man.
AppImage is a nice way to have an app on an USB stick, remote server or for archival. But for normal app usage, why?
I want to find a way to do this with flatpaks too.
A small GUI tool (a statically linked binary lol) that can be placed on that stick
- copy the flatpak app and runtime stuff to a folder
- copy the desktop entry over
- copy app data when chosen
And the same thing to copy it from the stick to a live system. Should work, probably not haha
TIP: Flatpak have a build-in way for creating USB, check out the “flatpak --help”.
But the point is with Appimage all that have to be installed is FUSE, which is expected to be installed on most installs when you go to a friend or work where Linux is used.
Oh nice!
Flatpak also works everywhere and appimages are not ported to fuse3…
I mean I want to think Appimages where nice, and they are kinda, but no.
I hate them both, give me a .Deb (or equivalent) if you’re gonna package it. And get off my lawn! 🤣
Installing .deb files from random sources is also very insecure and not reliable for updates.
Less secure than blindly installing flatpaks or appimages?
Appimages work “everywhere” so they are better for distributing malware.
Flatpaks are normally not installed from random sources and I hope it stays like that.
So yes and no.
(Also Flatpaks are, at least in theory, sandboxed and can’t mess with your system stuff unless you allow them to)
Not yet.
The permissions are too comlicated (unlike “allow documents access” on Mac for example)
And there is no Desktop GUI integration for opt-in to permissions. So install, open Flatseal / KDEs settings, harden, then run.
Ah, got it.
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.
Nextcloud, Balena Etcher, Lunar Launcher and more are exclusively supporting Appimage, thats the big problem.
Feather Wallet is a great example of AppImages done right
AppImages can be signed. Flat pak is the lesser option for security
We’re also regularly debating Flatpak here. That password managers don’t tie into the browser and the desktop themes don’t apply. It’s also not the best solution and regularly confuses newer users.
Flatpak is the best solution.
Password manager is usualy an add on.
Themes not applying is wrong packaging, not flatpaks fault.
Flatpaks limitations are real but you should install as flatpak first and if not working, then use the native package or nix. And limitations in flatpaks should be advertised.
Hehe, No. It’s the sandboxing.
But with this approach you take over the answering questions to newbies… Why doesn’t the webcam show up in the videoconferencing? Why doesn’t my GTK / QT themes apply to some software and it’s a 2 page tutorial with lots of command line commands to fix that? Why can’t I install Firefox add-ons and on Windows and MacOS everything just works? Why is Linux so complicated and regularly stuff doesn’t work?
I had this argument multiple times now. There is an easy solution: Do it the other way around until you know what you’re doing and about the consequences. Distributions are there for a reason. They put everything into one package and do testing to make sure everything works together. They provide you with security patches if you choose the right distro. LibreOffice and a Browser even come preinstalled most of the times. If you do away with all of that, it’s now your job to tie the software into your desktop, your job to handle the sandboxing if there is addons that need to pierce the sandbox. Your job to make sure the Flatpak publishers do quick updates and keep the runtimes up-to-date if a security vulnerability arise within an used library…
I’m not directly opposed to using Flatpak. I’m just saying there are some consequences that aren’t that obvious. In my experience hyping some of the newer technologies without simultaneously explaining the consequences is regularly doing a disservice to new users.
Do you mean fedora not installing codecs by default and the flatpak version of firefox has it bundled, i.e. just works?
I don’t want to argument with you about that. If something doesn’t work as expected or intended, you’ve done a bad job. Stuff not working on linux isn’t exclusive to flatpak. It’s the fault of maintainers if people complain about a flatpak version compared to distro package.
More people have to use flatpak and report the bugs they experience. The more people focus on flstpak the less infancy bugs will appear.
I’ve got only recent runtimes installed. There’s no old runtime. I understand your concern though, but it’s less of a problem for maintained software. Moreover, you’ve got the same problrm for other package manager. Flatpakcan even improve upon this because it’s bundled.
There’s also a distinction to be made if it’s an official distribution channel or if someone else packaged it.
That native messaging portal is probably developed somewhere. But for sure, also apps installing themselves “partly” as an extension of another, like Zotero and Libreoffice. This could be done though, okay.
Themes generally just work on KDE at least. At least light/dark themes, which may not really be the fanciest of choices
I’d be happy if people just cut down on advertising Chrome/Firefox and LibreOffice via Flatpak to new users. They should use the packaged version. That’s why we have distributions, to make the whole system a smooth experience and everything tie together.
Flatpak is slowly getting there and I think at least some distros have it preconfigured so the default GTK themes are in place.
Ultimately, I’d like sandboxing to be available natively in Linux, at least for desktop applications. And we can talk about a packaging format that is available to the user, allows pulling software directly from the upstream project, includes libraries and runtimes.
Yes SELinux confined users or apparmor could allow sandboxing apps the same way as flatpaks.
On 2GB of RAM systems that would make a lot of sense.
Chromium cant use its native sandbox, Firefox supposedly can.
But Librewolf and more should be used as Flatpak, unless you need multiple apps to chat between (native messaging) which doesnt work yet, its way more stable.
Yeah, I think we should extend on the sandboxing features like AppArmor, SELinux and Flatpak for desktop use. Look at MacOS and Android and what they’re doing for desktop users. That is currently not the Linux experience. Ultimately I’d like my system to have an easy and fine grained system to limit permissions. Force third-party apps to ask permission before accessing my documents or microphone. have sane defaults. make it easy to revoke for example internet access with a couple of clicks. make it so I can open an app multiple times. and have different profiles for work, private stuff and testing. This should be the default and active in 100% of the desktop applications. And apps should all use a dedicated individual place to store their data and config files.
Librewolf and more […] used as Flatpak, […] its way more stable.
That’s just not true. I’ve been using Linux for quite a while now. And I can’t remember my browser crashing in years, seriously. Firefox slowed down a bit when I had 3000 tabs open, but that’s it. How stable is your Flatpak browser? Does it crash minus 5 times each year? How would that even work? And what about the theming and addons like password managers I talked about in the other comment? Use the distro’s packaged version. It is way more stable. And as a bonus all the edge-cases will now work, too.
Most things already work. You know, desktops need to start with that, they need to implement popups for these permissions. And I guess apps also dont ask for permissions yet (like they do with Pipewire access), they just take it or fail.
So its again a problem of adapted apps.
Storage is all stored in
~/.var/app/and could be duplicated etc if you really want to. That would require some hacking, but you could have multiple profiles for apps. Tbh this is not hard to do at all, just rename the app folder to “appname-profile” and rename the active folder back to the apps name.A GUI for that would be interesting.
Browsers are a big example of good native packaging, as they get most attention. But for example on Debian, or Ubuntu, or many other platforms, I would prefer to use Flatpak Firefox (if firefox didnt have their deb repo now).
Chromium is hacky as Flatpak as the Sandbox is imcompatible and needed to be replaced.
For firefox there is no statement about this, hopefully soon. I use native browsers for the same reason as you.
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, …
Get FUCKED
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.
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?
You can, but it seems to be not documented how to get a .flatpak from an installed app.
Yea im pretty sure flatpak suports bundles that you can install directly, just like an appimage
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.
Oh look, another Linux user whining about a binary distribution method they don’t like. If you don’t like Appimages, don’t use them.
On the one hand I am entirely sick of how people will keep wasting keystrokes on this kind of discourse when the whole point of Linux is that you can choose which one you like best.
On the other, someone on a different community said it best: “Hey, if Linux users didn’t fight about what thing they want to make standard, what ELSE would we meme about?”
How Windows is shit? How Manjaro didn’t renew their web certificate that time years ago? Whether or not it’s Gnu/Linux or just Linux? There are so many “issues” to obsess over!
Why not the death of IRC and xmpp? Or are only other folks’ complaints a problem? (Not stalking, just wanted to see what you were even doing here aside from complaining about Linux users’ complaining. Turns out it’s complaining.)Update - Eh, sorry for being so damn grumpy.
Np, I’m pretty damn grumpy lately as well. I also apologize.
As a user, I can’t choose, if a dev only releases an appimage. Then it’s a real pain or I skip the app.
Developers of often proprietary software think its a good format and only support that. This is a problem
Well then, what text editor do you use then?
/s
flatpak?
Frying pan, meet fire.
Odd, this random github rant didn’t seem to sway my opinion.
To hell with user choice, only flatpak
I’m not going to weigh in on the specifics of Flatpak vs AppImage, because I don’t know enough about the particulars.
However, I think the “user choice” argument is often deployed in situations where it probably shouldn’t be.
For instance, in this case, it’s not the user’s choice at all, but a developer’s choice, as a normal user would not be packaging their own software. They would be merely downloading one of a number of options of precompiled packages. And this is the thrust of the argument. If we take the GitHub rant at face value, some developers seem to be distributing software using AppImage, to the exclusion of other options. And then listing ways in which this is problematic.
I, for one, would be rather annoyed if my only option were either AppImage or Flatpak, as I typically prefer use software packaged for my package manager. That is user choice, give me the option to package it myself; hopefully it’s already been done for me.
There are some good things to be said about trust and verification, and I’m generally receptive to those arguments way more than “user choice.”
Thanks. Also, afaik lots of software is not legal to redistribute as Flatpak.
It’s thanks to user choice that we aren’t all stuck on proprietary operating systems, so saying that isn’t great.
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.
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.
If worst comes to worst you can just distribute your .flatpak file directly, as you would with your app image
This would tick a lot of issues but please dont do that. People will get used to it and suddenly malware is possible again.
Totally understand that. Development docs are so needed.
what are flathub issues? IMO it’s easier than putting your app in Debian…
