Skip Navigation

Flatpack, appimage, snaps..

Appimage for me ticks all the boxes for cross distro package as its very portable, simple to run, what are devs trying to do when creating snaps and flatpack?

53 comments
  • Appimages do not have repositories, unlike Flatpaks and Snaps. It's harder to install or update them since there isn't a package manager for the Appimages.

    I don't know about Snaps, but Flatpaks are sandboxed, which basically means more security, since apps won't get access to your system without permission. It's kind of like Android where apps have to ask for permission to things like camera access, filesystem access, etc.


    While I do use Appimages, they remind me of Windows and having to go to websites to download stuff.

    Personally, I prefer just installing software with my distro's package manager and resort to Flatpaks or Appimages when it's not available in the repos.

  • Distro packages and to some extent Flatpaks, use shared libraries which can be updated independently of your app.

    So for example, if a vulnerability is discovered in say, curl, or imagemagick, ffmpeg or whatever library an app is using: for AppImages, this won't be fixed until you update all of your AppImages. In Flatpak, it usually can be updated as part of a dependency, or distributed as a rebuild and update of the Flatpak. With distro packages, you can usually update the library itself and be done with it already.

    AppImages are convenient for the user in that you can easily store them, move them, keep old versions around forever easily. It still doesn't guarantee it'll still run in distros a couple years for now, it guarantees that a given version will forever be vulnerable if any of its dependencies are because they're bundled in, it makes packages that are much much bigger than they need to be, and you have to unpack/repack them if you need library shims.

    Different kinds of tradeoffs and goals, essentially. Flatpak happens to be a compromise a lot of people agree on as it provides a set of distro-agnostic libraries while also not shifting the burden entirely onto the app developers. The AppImage developer is intentionally keeping Wayland broken on AppImage because he hates it and wants to fulfil his narrative that Wayland is a broken mess that won't ever work, while Flatpak developers work hard on sandboxing and security and granular permission systems.

  • Aah yes, appimage, flatpak, snaps, progressive web apps, electron apps... The cross-compatibility of the lazy 21st century developer, where a simple IRC-like chat client comes with an entire operating system or an entire browser (which itself is an entire operating system too nowadays), takes up half a gig of disk space, and starts up in over 10 seconds with a multi-gigahertz multicore CPU.

    Just perfect...

  • My problem with all three is that trust, security, quality comes from package to package. There is no standard, and packages are isolated from each other. If there is an issue between multiple apps, developers just start pointing at each other. With distro like opensuse I know everything is tested properly including security bug coverage and package interoperability. I can even check it myself at openqa.opensuse.org

    With flatpaks I am at mercy of each developer not being lazy and well informed about all current issues.

  • This may be a little bias but this is my understanding:

    Flatpaks were the solution for reducing the duplication in Appimages and providing an automated way to do security updates. Flatpak got a chance to learn from Snap.

    Snaps are basically a proprietary approach to creating and distributing Appimages that were created prior to the current Appimage tooling. They got to learn from the first generation of Appimages and decided to deviate from them early on.

    Appimages were a stupid simple approach to a complex issue. Initial tooling was rough though and a lot of people, while they liked the idea, hated the requirements. Basically setting up an Ubuntu 18.04 environment for packaging was the only way to guarantee a truly portable image.

    It left room for improvement and so decisions were made to try and fill that room. They were never bad, and devs weren't really trying to do anything other than simplify the creation and distribution of existing Appimage functionality.

    I still think flatpaks are the closest to the ideal solution but again, I'm biased.

    • I suppose FlatHub is the primary repo for Flatpak and where the updates comes from?

      And also the Steam Deck natively supports them, which is noce.

  • I still prefer to run everything built directly from reliable deb sources.

    As an end user... sure, flatpaks and appimages and snaps are I guess neat if you are constantly distro hopping or something, at least in theory.

    But uh, I have already found the ability to play games, develop games and other software, use basic daily software for everyday needs, and have a stable and predictable OS that doesnt crash or have insane misconfigurations caused by some esoteric conflict by just basing everything directly off of deb sources.

    Every once in a while I will have to compile my own build, but this is rare and usually only occurs when trying out something experimental, or, also rare, something that doesnt have an actively and well maintained deb source. In that case its just a matter of doing a build from github when a new version comes out.

    And I can do builds from github because I have saved a lot of storage space from not using bundled installers for all my software, allowing me to store the sources. This is also neat because it allows me to quickly /use/ one of those sources in a project, after I have already seen that it is stable via the software I use that is built on it.

    Finally there is the security angle. Using a myriad of different containerized installers for everything is convenient in that you don't have to directly worry about source management... until you do, when a source lib is discovered to have a critical flaw.

    When a serious flaw is found in a source library... what's gonna get updated faster? A containerized installer that you have to wait for the devs, who are busy managing tons of cross platform dependency issues and have to do a new safe stable build everytime any of their many dependencies for their many supported platforms? Or an app specifically built from source libs that either doesnt focus on cross platform, or has different teams specific to maintaining its different supported flavors?

    In my experience, literally all of the time, the 'direct from source' software gets updated more quickly than the cross platform bundled installer.

    Further, this whole approach here gives you experience with software that is built on source packages that, as you become more familiar with, and tinker with yourself, gives you insight into what source libs are well coded in terms of cpu/gpu/ram optimization, and which are resource hogs and should be avoided if youre interested in promoting and using software built off of efficient code. I enjoy learning from the good coding techniques of stable, lean and fast programs, and avoiding code that is comparatively unstable, boated, or slow.

53 comments