Samueru_sama

joined 1 year ago
[–] Samueru_sama@programming.dev 4 points 2 days ago* (last edited 2 days 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).

[–] Samueru_sama@programming.dev 4 points 2 days ago (2 children)

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

[–] Samueru_sama@programming.dev 12 points 1 week ago (5 children)

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

[–] Samueru_sama@programming.dev 2 points 3 weeks ago

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?

[–] Samueru_sama@programming.dev 3 points 3 weeks ago

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.

[–] Samueru_sama@programming.dev 1 points 3 weeks ago (1 children)

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

[–] Samueru_sama@programming.dev 1 points 4 weeks ago (3 children)

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

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

[–] Samueru_sama@programming.dev 1 points 4 weeks ago* (last edited 4 weeks 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.

[–] Samueru_sama@programming.dev 1 points 1 month ago
[ "$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

[–] Samueru_sama@programming.dev 3 points 1 month ago (1 children)

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.

[–] Samueru_sama@programming.dev 1 points 1 month ago

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 👀

view more: next ›