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.

You can have universal packages separated from the system that use very little space. That is known as AppImage

And now it is possible to make them truly universal, before appimage sucked since they had a dependency to libfuse2 and glibc, that’s not needed anymore.

they make more sense than appimage because they can deduplicate dependencies

mmm

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

Wouldn’t mind basically adding to a command or cron for something like apt-get get upgrade && flatpak update && something

iirc topgrade has support for AM, so you can do all at once with AM included.

Well if you still insist. Just went to check how big is the GNU coreutils as a single static binary, it is 2.3 MiB in size

check it out: https://pkgs.pkgforge.dev/repo/bincache/x86_64-linux/coreutils/nixpkgs/coreutils/

The overall uutils suite is faster then GNU Coreutils already and will only get better

just did a quick benchmark.

uutils cat is 2x slower.

This is the unknown-linux-gnu release, the musl one is likely slower but didn’t check.

fair, in that case the comparison is even since busybox provides a shell, awk, grep, wget among other 395 utils, uutils it is 115.