Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)S
Posts
0
Comments
84
Joined
1 yr. ago

  • 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

  • Several New X.Org Libraries See 2026 Releases

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

  • Several New X.Org Libraries See 2026 Releases

    Jump
  • 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?

  • Several New X.Org Libraries See 2026 Releases

    Jump
  • Several New X.Org Libraries See 2026 Releases

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

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

  • Deleted

    Permanently Deleted

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

  • Deleted

    Permanently Deleted

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

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

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

  • 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