Software deployment that tackles dependency hell in a secure fashion while providing repeatable, atomic updates and rollback.

AppImage doesn’t even provide a proper update system.

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…

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.

Flatpaks have the concept of runtimes; instead of downloading the entire qt tooling for a qt app the app could just use the KDE runtime same goes for GTK with the Gnome runtime. Flatpaks also have dependencies which can be shared between multiple apps even when they are not part of their runtimes, they are called “baseapps”. Flatpak apps still use double the space my normal apps take on a fresh install, so I assume using appimages to replace them will leave no space on my SSD.

Before deciding to settle on using Flatpak I tried to search for appimage permissions and how to set them, but it seems there is no such thing? If that’s true then there’s another advantage for Flatpaks and Snaps.

Also with all due respect: Flatpak and Snap tooling are not maintained by Probonodb.

The best of them all, αcτµαlly pδrταblε εxεcµταblε.

Build once, run natively on literally any PC OS including Windows and MacOS!

openSUSE’s Richard Brown has given multiple talks over the years comparing these three. I’d suggest anyone to look at those for a great rundown on how these universal package managers compare to one another. His most recent talk can be found here; in which he actually does some kind of recap as well.

• ruins single source of truth over installed state
• thus kills validation and thus consistency and thus repeatability (the holy trifecta of release management)
• promotes dependency hell
• promotes redundant installs
• ‘hides’ installs from enterprise management (eg snmp)
• you will fail the audit

But other than being redundant and risky, totally cool.

Flatpak works like a package manager but has program isolation as well.

Just download .exes for windows and run them with WINE. Don’t have a single snap or flatpack application. If it doesn’t run then u didn’t need it in the first place 👉😎👉

Edit: someone DMed me and took this comment seriously. Bless ur heart

AppImages suck because I can’t pin them to my dashboard, can’t set them to open at startup and can’t set them as default apps for the appropriate filetypes.

I hate all three. Why do we need to the same dependencies in a thousand different places? There’s gotta be something better between typical software repos and these stupid packed applications.

My problem with appimage is that they never work. Every time I tried one, best case scenario it crashed with a random error message. All attempts to fix them were damn near impossible to debug.

It honestly felt like they were not universal enough and still relied on certain libraries being available on OS. Hopefully I’m wrong because that would completely defeat their purpose. I stopped wasting time on them after Plex and VLC both failed to run reliably and switched to flatpak that “just works” 100% of the time.

To be honest most of the time I look for an rpm anyway. Flatpaks are always a last resort. I’m on OpenSuse Tumbleweed.

Removed by mod

Flatpak provides updates, management tools, an ecosystem of common components that don’t need to be repackaged with every executable, dependency management, cleaning up unused dependencies, warnings when you are using obsolete packages, and so on