The points in the screenshot are just false and outdated, the guy even says that it doesn't work on every distro lol

This is signal made with sharun working on ubuntu 12.04 a 14 year old distro: https://imgur.com/a/1f5S0P7 The distro is so old that internet no longer worked lol, had to use a flash drive to transfer the appimage.

we use a lot less storage than flatpak and this comparison is outdated, we have reduced the size of a lot of apps since then.

I actually did a quick test installing an alpine linux container and about 10 GUI apps vs appimage and appimage used less storage, now this comparison was flawed because I later realized that the alpine stable repo was super old and for example GIMP was pulling the gtk2 version instead of the gtk3 one (which brings all of gtk2 into the system instead of sharing the existing gtk3) but you get the idea of how close we are.

For updates and desktop integration use AM or soar

but they will never replace native implementations.

Eden makes its appimage using sharun, they made it with PGO optimizations on it which has a ~10% increase in FPS.

native implementations wouldn't bother doing this, in fact PCSX2 had to tell people to not use the official archlinux package while it existed, because archlinux compiled it with generic flags which was horrible lol

https://www.reddit.com/r/linux_gaming/comments/ikyovw/pcsx2_official_arch_linux_package_not_recommended/

This is also the reason why this benchmark showed appimage performing much better, you are free to optimize your application, while distros packages, flatpak, etc you often have to deal with packaging policies that do not allow this:

https://www.reddit.com/r/linux/comments/u5gr7r/interesting_benchmarks_of_flatpak_vs_snap_vs/

The problem is that NixOS achieves all of this by breaking assumptions that almost all Linux software relies on. Most Linux binaries assume the Filesystem Hierarchy Standard exists, and they expect interpreters and libraries at fixed global paths.

This is a problem of those applications, we began to make appimages that do not make those assumptions and work in NixOS directly. (And this also means it works in places like alpine where a lot of those binaries wont either).

People like to throw the FHS around but the reality is that not a single distro follows it fully, I wouldn't rely on it to be the same in the near future at all.

Doesn't even mention deadbeef lmao

• https://github.com/swaywm/sway/issues/8000
• https://github.com/swaywm/sway/issues/8001
• https://github.com/swaywm/sway/issues/8002
• https://github.com/swaywm/sway/issues/8191

Also using the yuzu works (eden and citron) performance is awful, like half the FPS I used to get on i3wm, this also happens in hyprland but not in plasma, apparently this is because the two window managers lack fifo v1 (hyprland did add it a few months ago, I need to check if it works better now).

I bought an AMD gpu to use sway and it is still broken, don't use sway.

I make an appimage of this here

Just rename it to have photogimp in the title to enable it, otherwise it defaults to regular gimp3.

Well, upstream is now considering either merging or just pointing to the AM repository because it is bigger and better maintained.

https://github.com/AppImage/appimage.github.io/issues/3595

yet they still miss a central package repository, and that’s a big problem.

https://github.com/ivan-hc/AM

I don’t know where this myth about Flatpaks always being gigabytes in size originates from or why it’s so persistent, but it’s wrong.

Alright, here is ~25 GUI apps flatpak vs appimage:

• 6 GiB flatpak.
• 2.7 GIB appimage.

This is if you have a filesystem with transparent compression, If you do not have such filesystem (ext4), then it is more like 15 GIB vs 2.9 GiB lol.

This comparison is missing the flatpak equivalents of kdeconnect, deadbeef and a few CLI tools that I have on right btw, flatpak-dedup-checker for some reason doesn't check the /var/lib/flatpak/repo directory which is usually another +1GiB in best case scenario.

[ "$age" \< 18 ] && {
	echo "I'm not an adult yet"
} || {
	echo "I'm an adult"
}

if you want to be using braces in if statements lol

My most recent Bash mistake was misusing test -n and test -z. In Amber, I can just use something == "" or len(something) == 0

test -n can be [ "$something" ] and test -z can be [ "$something" = "" ]

And this applies to posix shell, not just bash.

https://github.com/pkgforge-dev/Cromite-AppImage

i was talking about the risk of a Flatpak which has access to user home and therefore could for example access $HOME/.firefox and steal session cookies.

Okay that makes sense.

Also I based my assessment of use FUSE2 for normal AppImages on the security hardening used by Secureblue, mentioned here under the section “Filling known security holes”

Remove the unmaintained and suid-root fuse2 by default.

kek they got it wrong. Also:

Mitigate LD_PRELOAD attacks via ujust toggle-bash-environment-lockdown.

Interesting, I wonder if they prevent executing the ld-linux.so as well.

There is two ways to preload libraries without having to modify the binary, the first is using LD_PRELOAD, the second is less well known but you can run binaries by calling the dynamic linker first (internally this is actually how all dynamic binaries you execute work btw) and then use the --preload flag to load a library.

That is instead of:

LD_PRELOAD=./kek.so /path/to/bin

you do:

/lib64/ld-linux-x86-64.so.2 --preload ./kek.so /path/to/bin

I'm going to take a wild guess and assume the second is still possible in secureblue 👀

AppImage is just a format, nothing is stopping distros from adding a binfmt_misc rule that makes all appimages be sandboxed with any tool. (this also means you can set this up so that they get executed inside a flatpak env btw)

They also rely on the deprecated SUID-root binary FUSE2.

There is no such thing as a suid fuse2, you are talking about suid fusermount, and libfuse2 which hasn't been true for 3 years the runtime is now static and doesn't depend on any libfuse (or any library) to work.

And even back then it wasn't a hard dependency either, you could still run appimages by setting APPIMAGE_EXTRACT_AND_RUN=1 which makes them run without FUSE.

The runtime still depends on a suid fusermount in PATH (it checks all the way to fusermount99 lol), however there is a much better runtime that does not FUSE to work at all since it can use mount namespaces instead.

Meanwhile flatpak has a hard dependency on fusermount, it actually broke recently on ubuntu because they wanted to restrict access to fusermount.

but if given access to the “home” permission they can read and write to anywhere else in the user home, so stealing session cookies from a browser or ransomware could still be possible given the right permission.

web browsers (and electron apps) already have their own internal sandbox, which actually gets weakened by flatpak so it is actually not a good idea to be running those things with flatpak 1 2 3

firefox recently finally got a fork server in linux, which means it is possible to at least get the zypack hack working with it, no idea if it has been implemented yet though.

You also can sandbox appimages with bubblewrap, which is the very same sandbox flatpak uses, I wrote this tool used by AM for that.

Apps will also have access to the portals, although I don't like this and looks like there is no easy way to disable access to portals other than disable all access to dbus which is bad.

We already had an incident where someone thought there was a sandbox escape when it was just the app opening the portal xd

they are not following the spec if this is the solution.

• data files (like extensions, sessions, etc) need to go in XDG_DATA_HOME.

• config files (user preferences) need to go in XDG_CONFIG_HOME.

• cache files need to go in XDG_CACHE_HOME.

• log files need to go in XDG_STATE_HOME.

also hopefully they do check the variables and not just hardcoded ~/.config, ~/.local/share, etc

but problem with appimages is that there are no repositories

• https://github.com/ivan-hc/AM
• https://github.com/pkgforge/soar

and they rely on older fuse implementation.

• The official AppImage runtime has been static (no longer depends on any libfuse) and built with fuse3 since 3 years ago. Only electron builder remains with this nonsense of using the old runtime.

• Also DWARFS AppImages that also do not need FUSE at all to run.

Recently I have been using language specific package managers more - cargo (and cargo binstall) to get most of rust stuff. And since I like new stuff, I happen to have quiet a few (~20) packages from it. binstall allows to fetch binary releases. Only major problem with it is that cargo has limitations in it’s pacakaging, and effectively only /bin parts of package is installed

• https://github.com/pkgforge/soar !!!

Sure, you can enable it. That doesn’t solve the problem. The problem is that you cannot execute the app directly and need to use a wrapper script. steam-run and the like are hacks to get things working.

Do you know how binfmt_misc works? It makes it so that when you execute the appimage it automatically runs it with appimage-run, both flatpak and snap work in a similar matter, flatpaks need to be launched by flatpak run and snaps by snapd, however with binfmt_misc it removes the need to manually have to use appimage-run and it instead does it automatically for you.

So this makes no sense.

it’s still entirely author-dependent whether the app will work across different distros. The list of projects that use those tools is also quite small right now. Meanwhile, pretty much every flatpak I’ve tried has not been an issue.

Welcome to the world of centralized packaging systems that have requirements before running. flatpak or snap do not have this issue because they need runtime dependencies and setup before you can even try to launch any, you also likely get your flatpaks from flathub and I assume they at least test them once before publishing them.

probono once tried to enforce people to build their appimages on old systems to guarantee some quality and this was met with backslash. 😹

steam-run and the like are hacks to get things working. They shouldn’t ideally be needed, especially with a format that is meant to work without issues across distros.

FYI, AppImage itself is older than NixOS and MUSL, the whole tooling is also controlled by boomers that want standards to follow and what not.

Basically AppImage was based off the idea of executable directories of MacOS, on those systems there is a some basic set of dependencies that will always be there.

AppImage instead tried to target the most common linux systems, which back then 99.99% of the time was going to be an FHS filesystem with glibc. glibc guarantees backwards compatibility*** so they made the rational decision (back then) of relying on some host dependencies and what not.

Fast forward to 2025 and now linux is no longer that, you cannot even expect a system to be GNU/linux at all, nobody follows the FHS fully anymore. So the only thing you can complain about here is that appimage hasn't moved fast enough to these changes but this is just a 100% community project, I think only KDE has contributed to appimage meaningfully in the past, there is nothing the likes of Red Hat or Canonical behind the project unlike flatpak and snap.

***Even this crap has had a ton of exceptions years later btw.

I meant if you enable flatpak in your nix config, it works without issue.

And this cannot be enabled in the nix config?

Basically every appimage needs to be run through a wrapper executable that I’m guessing patches the paths

It does not patch paths, it makes an FHS env with basic dependencies that the appimage can then use, NixOS also offers something similar for other apps called steam-run.

And once again you don't need it for every appimage, hopefully in the near future that will be all appimages.

https://github.com/pkgforge-dev/Anylinux-AppImages

https://github.com/VHSgunzo/sharun

EDIT:

It also hardcodes paths so it doesn’t work on things like NixOS or Guix System out-of-the-box.

Also this take makes no sense, flatpak nor snap work on NixOS or Guix out of the box unless the user installs and configures them with all their dependencies, and that usually includes a reboot to make sure the flatpak exports get added to XDG_DATA_DIRS.

Meanwhile appimage can be made to work out of the box in those systems and for those that don't NixOS offers an FHS wrapper to run them.