[–] 11 points 9 months ago*

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/

  • source
  • parent
  • context
  • [–] 22 points 9 months ago (5 children)

    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.

  • source
  • [–] 4 points 10 months ago*

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

  • source
  • parent
  • context
  • [–] 1 point 11 months ago*

    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.

  • source
  • parent
  • context
  • [–] 3 points 11 months ago (1 child)

    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.

  • source
  • view more: next ›