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.

  • drwankingstein@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    38
    arrow-down
    8
    ·
    8 months ago

    oh boy here we go I strongly disagree with this article

    While complex .tar archives (like firefox) may seem messy, they integrate many different things. An installer script takes care of placing a .desktop entry, you can have an updater script, a LICENSE, README and more. Those are all missing with Appimages.

    .tar ARE messy, sometimes they don’t work right, dep conflicts, etc. An installer script can be shipped with an appimage anyways. Moot point IMO

    Apps installed with the system package manager get their .desktop Entry in /usr/share/applications, installed Flatpaks get their entry linked to ~/.local/share/flatpak/exports/share/applications/, user overrides and other installs can be put in ~/.local/share/applications/.

    Appimages have no desktop entry, so they have (currently) no icon on Wayland and they don’t appear in your app list. Desktop entries are a standard, used by everytthing but Appimages.

    see above

    Instead users follow strange habits like placing the files on their desktop, which is a highly discouraged “Windows workflow” (symbolic image) and not even supported on many Desktop Environments, most notably GNOME.

    Who discourages it? I personally prefer this myself, lack of desktop icons is a common complain for stuff like GNOME…

    This is both a usability and a security issue. Traditional Linux apps, even if they are cross platform, don’t have updater services, as package managers are way better at doing that.

    I disagree that this is better. A personal issue but I Much prefer when apps can update themselves.

    This means, packing as an Appimage either requires to implement an updating service, on a platform that doesn’t need that, or to have no updates at all.

    Instead users need to follow an RSS feed, get a mail, or manually check for updates, which is horrible UX. Then how do they update?

    Is this really a massive issue? There have been appimage stores in the past. Self updating appimages really isn’t that hard either. If this was a massive issue, you could do something like obtanium for android which could easily automate the process.

    Appimages don’t even have a central place where you can find them, not to mention download them. This is extremely insecure. Modern Application stores and every well made Linux repository uses cryptographic (mostly gpg) verification, which secures the authenticity of the software. You can be sure you downloaded the real package.

    I’d argue it makes little difference. But yes, Downloading things from the internet is more unsafe then downloading from a repo or a “curated” service. So we can grant one here.

    There is no updating mechanism. On Android you may also update by downloading .apk files, but once installed, the .apk needs to be signed with the same key, otherwise updates are blocked. With Appimages… you just delete the old .appimage file, download the new one, change the name to remove the version and hope your .desktop entry didn’t break.

    This is how you get malware.

    the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.

    They are not well maintained

    There is a well known “bug” on modern Ubuntu, where Appimages lost their “works on every Linux Distro”, because they are built for the outdated libfuse2, while Ubuntu now uses libfuse3. The fix is to install the outdated version of libfuse (!), and this is still not fixed.

    An application format, that is incompatible with the latest version of its core dependency, is broken.

    This is a very minor issue, i’ve had way more issues with traditional repo packages then I have had with appimages.

    Lack of Sandboxing …

    I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything from devices not being recognized, weird storage issues and more.

    Random location …

    Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren’t “one of the major standards” this is just wrong. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

    Duplicated libraries

    Appimages bloat the system. They include all the libraries they need, and unlike system packages or Flatpaks, they don’t share a single libary. If users would really install every Software as Appimages, they would waste insane amounts of storage space.

    This also completely discourages efficient and up to date packaging, and the attached risk of outdates libraries is hidden away in that .appimage archive.

    and? When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.

    Appimages are not needed Flatpak solved many Linux desktop issues at once …

    None of these provide reasons as to why appimages aren’t needed. Appimages still offer a lot, for one I can just download and run it I don’t need to worry about installing and uninstalling application when I just want to try it, I don’t need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.

    Appimages also let me do fine grained control over the dependencies. No unexpected runtime updates, I can compile the deps with flags/features I want to support, and disable flags/features I don’t want to support, Users don’t need to download a stupid appstore or use CLI (not a single appstore i’ve used to date isn’t hot garbage, I hope cosmic-store will be different).

    • GenderNeutralBro@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      14
      ·
      8 months ago

      I agree with much of this. However, regardless of which platform you’re on. it’s best to follow the design patterns of that platform.

      Putting binaries on your desktop is not in keeping with Linux design patterns, nor are self-updating apps. I think those are fair points.

      Having dozens of apps all using their own update mechanism introduces unnecessary complexity, which can be exploited. This has been a problem on Mac and Windows over the years. On Mac, for example, a common solution to this is the Sparkle framework, which devs can use in their app to manage self-updating; but Sparkle itself has been exploited, so then you have apps out there running god-knows-what-version of Sparkle in their bundles, leaving users vulnerable with no good way to identify or remediate it. This is why I typically disable any self-updating feature in any apps I use.

    • Pantherina@feddit.deOP
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      edit-2
      8 months ago

      Dont know where user installed tar archives (with statically linked binaries or including deps) would have dep conflicts, maybe if they are not statically linked.

      The self updating stuff and desktop icons is personal opinion and not the common way on Desktop Linux, so I skip that.

      you could do something like obtanium for android which could easily automate the process.

      That is called a package manager, with a repo, with gpg signing etc. On Android (which I mentioned) updates are secure. Let alone the point that appimages are not updated in a regular way, they are just replaced.

      I’d argue it makes little difference. But yes, Downloading things from the internet is more unsafe

      No the difference is huge. If you are used to downloading software from websites, a faked website can easily lead to downloaded malware. Flathub can be added with a click and flatpak is included in distros, which means no hunting on the internet and no accidental clicks.

      And as I said, until nobody downloads .flatpak packages online, and there may be an occasion where this is normal behavior, people will believe malware links are legit.

      the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.

      Appimages are distributed everywhere, just as .exe files for Windows. This means they are favored by developers used to Windows and Mac, and those will not add them to a repo instead.

      So a faked website of whatever etcher or something is easy.

      The fact that Linux malware is not a thing, while Appimages clearly give the headstart for that, is a miracle.

      I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything

      Flatpaks are not secure because their sandboxes are weakened to not have such issues. This is due to apps not following secure standards, and until that is fixed they are insecure or broken or both. (Apps need to write configs in the container, they should use portals etc.)

      I maintain a list of flatpak apps following modern standards, which is a small portion but getting better.

      Linux is only somewhat secure because everything is FOSS and comes from repos.

      This is broken by appimages, that can easily distribute malware and thus fix the “my malware is not running on that distro” issue.

      Every software that can write to your .bashrc can easily catch your sudo password.

      Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren’t “one of the major standards” this is just wrong.

      Yes linux experts would put them there. As mentioned in that text malware would also install itself there, so on secure systems this should be only writable by root/ some elevated group privilege.

      But apart from that users put them on the desktop, or in some random folder, I mean that dir is hidden for a reason.

      Or put it in that PATH and then link to the desktop, resulting in a broken link when you remove the app.

      When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.

      If something is not scaleable its not a good concept. The fact that you will only install a couple of appimage apps is enough proof.

      On modern atomic distros users can rely purely on flatpak.

      Btw see the linked dedup checker. You may download more dependencies but they are linked between each other and not actually take up so much space.

      I don’t need to worry about installing and uninstalling application when I just want to try it

      We need to overthink those habits. You dont just “try an app”, you run unsandboxed code from an unverified origin. As mentioned above, this could be totally fine, and also add a function to your bashrc that catches your sudo password (the next time you use it) and sends it to a server.

      The secure way to do that is completely unpractical.

      1. Get a GPG app or use the cli, create a personal key. Secure the access permissions, as gpg always complains on Fedora for example.
      2. Hunt the internet for the gpg key of the dev
      3. Look for at least another source of that key like GrapheneOS does it
      4. Compare those keys hashes using cli or some app
      5. When correct, load the key into gpg/kleopatra/kgpg
      6. Verify the key with your internal key (yeah gpg is overcomplicated)
      7. Download the appimage, and a signed hash (most of the time its done like that)
      8. Verify the signed hash
      9. Sandbox the appimage using bubblejail (doesnt work) or firejail (no idea if it works, and its insecure)
      10. Repeat on every damn update (if it doesnt have a builtin updater)

      This is unusable. And repositories do this automatically without anything you need to do. For sure you could “extra check the website” and say "

      Also app data will be everywhere, often in its traditional location, while there is no package manager at all to delete them. Flatpaks store all their stuff (when devs care and not just ignore that, cough Cryptomator) in their container and data can be easily removed during uninstallation, GUI stores show a popup to delete data and I also made a small script to do that.

      And that “try it out” app will either have no desktop entry or that entry needs to be manually and will be still there after uninstalling.

      I don’t need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.

      This may be a reason, but this is only for testing then. But for sure, when its a small project, getting it on Flathub may be much efford.

      I can imagine the developer experience is easiser. Flatpaks are simply very “defined” and need all that metadata and more to be complete. But needing to use available runtimes is a good thing mostly, its basically supporting a specific distro.

      Flatpak through CLI is fine (I would like to have a standalone small store just for flatpak), Discover is nice too. The Linux Mint store also seemed fine but not much experience. (Linux Mint has some Wayland support now, so there is a secureblue Cinnamon spin, have to try that). The Cosmic store is just a stub currently, lets see!

      Cheers!