GitHub - boredsquirrel/dont-use-appimages: Appimages are an insecure packaging system with very limited use cases. Please use Flatpak instead!
github.com
Appimages are an insecure packaging system with very limited use cases. Please use Flatpak instead! - boredsquirrel/dont-use-appimages

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.

  • d3Xt3r@lemmy.nzMEnglish
    0·
    4 months ago

    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/bin is recommended by the XDG standard as a place to store executables. As long as $HOME/.local/bin is 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…