I just start AppImages from the command line and put them in my /home/$username/bin that seems to take care of most of the annoying edge cases. Snaps are ridiculously hostile abusing the mount system and polluting all kinds of places where they have no business going, I've completely purged the whole snap subsystem from my machine. Flatpak I've managed to avoid so far.

I unpack them because the app runs faster, no container/fs problems, and I use apps where I want to access the files in the app. Kicad in particular has a load of component files that I always want to copy from /usr/lib into each project so that the project is fully self contained and in a nicer way than the way kicad does it itself.

freecad has a problem where it uses python, and python3 defaults to shitting turds (pycache directories) everywhere it's executed. There is a way to tell python not to do that, but that mechanism is not possible when the app is an appimage. But is possible if the appimage is unpacked.

It's a simple, but totally manual process to unpack and integrate into the desktop fully so that file types autolaunch the app and displays the icon in the file manager. I started to write a script to automate it but there is just enough variation in the way appimages are constructed that it's annoying to try to script even though it's pretty easy to do manually.

If you look at Apple / Google mobile platforms, these are the requirements for modern desktop apps:

1. providing a build environment for app developers to build something that can run on any distro

Both Flatpak and Snap solve this by providing a SDK; for Snap there is one SDK built out of Ubuntu packages, for Flatpak there is a choice of various options, most built on the Freedesktop.org SDK (Gnome/KDE), plus some independent ones. AppImage provides nothing to solve this problem.

2. providing a runtime environment that conveniently integrates the app on users' desktops

Flatpak and Snap solve this via integration into Gnome Software, KDE Discover and similar UIs; AppImage also solves it in a way by being just a single file that the user clicks on.

3. sandboxing to keep users safe

Flatpak provides sandboxing via Bubblewrap, which works on any Linux distro. Snap provides sandboxing mostly via AppArmor, which requires (last I checked) out-of-tree Linux patches, and only works fully on Ubuntu. AppImage does not provide sandboxing, but the expert user can manually run an AppImage with firejail to sandbox it.

4. a convenient way for users to find applications to install

Flatpak has Flathub as a vendor-independent central app store with volunteer reviewers, and also provides the option to self-host apps conveniently. Snap has Snap Store as a central app store that is run and monetized by Canonical, and it's not possible to set up an independent alternative. AppImages are typically hosted directly by the upstream project, but now there is also an AppImageHub.

5. automated updates

Flatpak and Snap provide this automatically from Flathub/Snap Store; AppImages may be auto-updatable in several different ways but it requires the application author to implement support for it.

A few years ago I read this small post[0] that talks about Flatpak and it's use of OSTree[1].

It doesn't exactly compare it to the other formats, but still interesting on its own.

[0]: https://blogs.gnome.org/alexl/2017/10/02/on-application-size...

[1]: https://docs.flatpak.org/en/latest/under-the-hood.html

AppImages are just a portable packaging format while Flatpaks and Snaps also offer sandboxing, and Flatpak is more distro-independent than Snap which is developed by Canonical. Ubuntu used to be extremely pushy about Snap which turned me off and now Flatpak just seems a lot more popular.

Ubuntu is still pushing snap - they still kept the practice of silently replacing apt packages with snaps, I think the default Firefox is still a snap, and so is node.

I'd love to see snap go the way of upstart...

The Ubuntu defaultism still puzzles me to this day... Canonical has been shown to subject users to its horrible science experiments pushing broken software on its users sometimes even persisting for half a decade or more (see pulseaudio, it was shipped in ubuntu for literal years, and it never worked...). Snap is their latest science experiment.

Though Im not sure what should be the default, as I can think of disadvantages to several alternatives.

I've generally preferred AppImages because they're just a single-file (in appearance) binary I can put in a ~/bin folder and run. Flatpaks require using an external tool to run them, and update them, and there's confusion whether you need the --user flag or not, and after every graphics driver update on the main OS you need to upgrade all the flatpaks again... It's so much of a hassle. The permissions isolation is nice in theory but firejail works for that too, arguably better in some ways.

In the space of retro gaming, the DuckStation devs recently had some drama (I think primarily with Arch users) and it resulted in purging the flatpak builds, now there's only an AppImage. I'm sure much righteous rage etc. like this post but against Flatpak or who knows.

My only experience with Flatpaks is on Fedora Kinoite and Silverblue, so YMMV.

Flatpaks are updated at the same time as the system with the GNOME and KDE update GUIs, or in one step from the command line with "flatpak update" (or "sudo dbus-launch flatpak update" when running outside a graphical environment), and I've never run into problems with graphics drivers, though I've admittedly only used them on systems with Intel and AMD GPUs supported by in-tree drivers (but what you're saying makes sense because Flatpak runtimes do bundle user-mode graphics driver components).

While you're not wrong that running Flatpaks requires an external tool, installing them creates both symlinks to wrapper scripts in a common directory that can be added to your PATH and launchable desktop application icons in GNOME and KDE that work no differently than those for applications installed through other means.

The wrapper scripts and symlinks have qualified names, e.g. "io.mpv.Mpv", but that's trivially fixed with an alias or additional symlink if desired.

The only problems I've run into with Flatpaks are limitations due to sandboxing, e.g., the Wireshark Flatpak can't capture packets, which makes it useless in common scenarios.

"--user" is for working with per-user Flatpaks, rather than system-wide Flatpaks, which I've personally never had any reason to use since all my Fedora systems are personal, but it doesn't seem any more confusing than similar switches in other package management systems.

Generally speaking, between flatpaks and appimages, flatpaks are actually a lot easier to make and get out to people. The thing you're talking about here, not being able to easily run or get them, is kinda the core issue with appimages.

I've never actually worked with snaps before, but they're Canonical's format, somewhat? specific to Ubuntu. I can't say too much about them.

Flatpak gives me one package to install and a little bit of a minor security boundary around the application.

Out of Appimage, snap, and flatpak, flatpak has been the only one after years that seems sane.

It also works really well with atomic desktops tbf.

Fuck snap, fuck snap so hard.