Samueru_sama

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

You know - when you list two points, and I refer to those two points in my response, maybe assume that I’m responding in the same order you listed?

Nothing was quickly caught and fixed, the bug report is 7 months old:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/13319

Ok fair, but I still think that “a few bugs that make it not act like i3” is quite different from “doesn’t have backwards compat with i3 right”.

There is way more, it also fails with my i3config.

So don’t use Sway, plenty of DEs are more polished.

If you are an i3 user the only solution is sway.

which is relatively new, has unresolved bugs that i3, which is older, does not have.

sway is 10 years old and they haven't gotten backwards compat with i3 right, let alone other wayland specific issues like not having fifo v1.

and one bug that was quickly caught and fixed

The performance regression? It hasn't been fixed.

Maybe don’t use a distro that is specifically known for shipping new software very quickly.

You will run into old wayland bugs lol, like GTK4 apps being totally broken on intel.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38373

and often structurally much better

On wayland even getting apps to draw their own icons is a total disaster, and doesn't help the constant sabotage from gnome of refusing to fix those issues, and don't get me started on the csd mess which is another source of nightmares.

Wayland suffers a lot of internal fragmentation, we didn't see these kind of issues in the move from pulseaudio to pipewire because there is really only one implemenation of pipewire, guess what would have happened a bunch of DEs decided to make their own implementations of pipewire instead?

lol

• 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

And I have amd btw (bought the gpu to try sway in specific).

Also nvidia in specific, the creator of i3 recently made this post detailing all the issues he has had switching to sway:

https://michael.stapelberg.ch/posts/2026-01-04-wayland-sway-in-2026/

edit: sway doesn't even support fifo v1 ffs.

Ah, if it’s not working right for you, it obviously means it’s not working right for 60% of people.

Actually that is not too far off from being true.

mesa right now has this massive regression on wayland: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14674

And not long ago all gtk4 apps were totally broken on intel with wayland, this was recently fixed on mesa but that change has only hit people using archlinux and other rolling release distros.

• 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.

dec05eba is a totally different person, it is the guy that makes gpu-screen-recorder which is amazing btw.

It is the person that made this PR that fixed a massive blunder by metux lol https://github.com/X11Libre/xserver/pull/56

Portals could have been much simpler like how xdg-open works.

I'm surprised it seems nobody has tried to write an alternative to portals that doesn't use dbus?

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