Samueru

@Samueru@lemmy.ml

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Samueru, (edited )

May I know why did you ask this?

Edit: Why didnt people like this comment lol

Samueru,

There is usually misunderstanding behind this type of questions. for example “why isn’t ilike on macos where it is ~/.Trash” and then one has to explain what XDG_DATA_HOME is and why it makes sense for trash to be there (And that it doesn’t have to do with the desktop environment as well).

Or op just lost something important thinking that the trash was somewhere else.

Samueru,

Poor soul

Samueru,

Interesting that manjaro got kernel 6.9 before arch.

Samueru, (edited )

Also endeavour is not really arch with a graphical installer, or that is what I’ve seen at least.

I tried to help someone once that installed endevouros and for some reason their kernel parameters were being overwritten every time they updated, turns out that was an issue because endeavour installed dracut instead of mkinitcpio by default? I don’t know wtf was that. They ended up switching to arch after that lol.

Also their /efi directory was set as read-only to the root user, meaning that to even see if their kernel parameters were there they needed sudo lol

Samueru, (edited )

You should be able to just switch mirrors, default apps and switch to arch while on endevour.

I know you can switch from arch to artix which is a lot more stuff being replaced, so it should be much simpler to switch from endevour to arch.

Samueru,

Btrfs

Samueru,

Isnt fedora like the last distro that doesnt symlink /bin and /sbin to /usr/bin?

Samueru,

In the old days distros used to separate the location of binaries in several places like /bin /sbin /usr/bin and /usr/sbin there was this idea that system binaries would go in /sbin while the rest in /bin and the similar dirs in /usr were so that you could mount a separate drive to store more binaries. This is from a time where storage was an issue.

These days distros usually just symlink all those locations to /usr/bin with the exception of fedora, which still keeps some split.

However it seems they will finally merge the remaining dirs in fedora 41: fedoraproject.org/wiki/…/Unify_bin_and_sbin

Samueru,

(once Flatpak get that too, there is no valid reason for snaps to exist).

They said they will not fix it due to “security concerns”

Samueru,

How are they going to stop using zenity? it is a dependency of steam. And right now the gtk4 version needs a bunch of hacks to follow the system theme as well.

Samueru, (edited )

bugzilla.mozilla.org/show_bug.cgi?id=259356

20 indeed

I use this script with librewolf, give it a try, simply place it in $HOME/.local/bin name it librewolf and export that location as first in $PATH:


<span style="color:#323232;">#!/bin/sh
</span><span style="color:#323232;">
</span><span style="color:#323232;">APPHOME="$XDG_DATA_HOME/librewolf/HOME"
</span><span style="color:#323232;">APPEXEC="$HOME/.local/opt/librewolf/librewolf" # Replace this with the path to librewolf
</span><span style="color:#323232;">
</span><span style="color:#323232;"># XDG Check
</span><span style="color:#323232;">if [ -z "$XDG_CACHE_HOME" ] || [ -z "$XDG_CONFIG_HOME" ] || [ -z "$XDG_DATA_HOME" ] || [ -z "$XDG_STATE_HOME" ]; then
</span><span style="color:#323232;">	echo "One or more XDG Base dir variables not defined, bailing out"; exit 1
</span><span style="color:#323232;">fi
</span><span style="color:#323232;">
</span><span style="color:#323232;"># MAKE FAKEHOME AND LINKS
</span><span style="color:#323232;">mkdir -p "$APPHOME/.local" "$XDG_DATA_HOME/pki" "$XDG_DATA_HOME/icons" 2>/dev/null
</span><span style="color:#323232;">[ ! -e "$APPHOME/.local/share" ] && ln -s "$XDG_DATA_HOME" "$APPHOME/.local/share"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.local/state" ] && ln -s "$XDG_STATE_HOME" "$APPHOME/.local/state"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.config" ] && ln -s "$XDG_CONFIG_HOME" "$APPHOME/.config"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.cache" ] && ln -s "$XDG_CACHE_HOME" "$APPHOME/.cache"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.icons" ] && ln -s "$XDG_DATA_HOME/icons" "$APPHOME/.icons" # Some apps have hardcoded ~/.icons path
</span><span style="color:#323232;">[ ! -e "$APPHOME/.pki" ] && ln -s "$XDG_DATA_HOME/pki" "$APPHOME/.pki" # Chromium/electron hardcode ~/.pki
</span><span style="color:#323232;">
</span><span style="color:#323232;">find "$APPHOME" -xtype l -delete
</span><span style="color:#323232;">for FILES in "$HOME"/*; do
</span><span style="color:#323232;">    FILENAME=$(basename "$FILES")
</span><span style="color:#323232;">    DEST="$APPHOME/$FILENAME"
</span><span style="color:#323232;">    if [ ! -e "$DEST" ]; then
</span><span style="color:#323232;">        ln -s "$FILES" "$DEST"
</span><span style="color:#323232;">    fi
</span><span style="color:#323232;">done
</span><span style="color:#323232;">
</span><span style="color:#323232;">
</span><span style="color:#323232;"># START APP AT APPHOME
</span><span style="color:#323232;">HOME="$APPHOME" "$APPEXEC" "$@" || notify-send "App not found"
</span>
Samueru,

What kind of non argument is that lol

Samueru,

About 20 xdg-open alternatives (which is, btw, just a wrapper around gnome-open, exo-open, etc.)

I use handlr-regex, is it bad? It was the only thing I found that I could use to open certain links on certain web applications (like android does), using exo-open all links just opened on the web browser instead.

Samueru,

$PATH shouldn’t even be a thing, as today disk space is cheap so there is no need to scatter binaries all over the place.

$PATH is very useful for wrapper scripts, without it there wouldn’t be an easy way to for fix the mess that steam does in my homedir that places a bunch of useless dotfiles in it. The trick is simply have a script with the same name as the steam binary in a location that is first in $PATH therefore it will always be called first before steam can start and murder my home again.

About /var/tmp, I just have it symlinked to /tmp, technically /var/tmp still has a reason to exist, as that location is use for temporary files that you don’t want to lose on power loss, but I actually went over the list possible issues and iirc it was mostly some cache files of vim.

EDIT: Also today several distros symlink /bin and /sbin to /usr/bin.

Samueru,

but we still have all the other locations, symlinked there. It just makes no sense.

Because a lot of shit would break if that wasn’t the case, starting with every shell script that has the typical #!/bin/sh or #!/bin/bash shebang.

This is what plan9 does for example. There is no need for $PATH because all binaries are in /bin anyways. And to override a binary, you simply “mount” it over the existing one in place.

Does that need elevated privileges? Because with PATH what you do is export this environment variable with the order you want, like this:

export PATH=“$HOME/.local/bin:$PATH” (And this location is part of the xdg base dir spec btw).

This means that my home bin directory will always be first in PATH, and for the steam example it means that I don’t have to worry about having to add/change the script every time the system updates, etc.

Also what do you mean by mounting a binary over? I cannot replace the steam binary in this example. What I’m doing is using a wrapper script that launches steam on a different location instead (and also passes some flags that makes steam launch silently).

Samueru,

Though in this case I would simply name the script steam-launcher and call it a day

The problem with that is that if another application tries to launch steam, it will bypass the script. And renaming the steam binary and give the original name to the script means that it has to be done every time steam is updated. Not to mention that if the script has a different name from the binary and I were to launch steam from the terminal to troubleshoot something it would also cause the issue again.

Having multiple executables with the same name and relying on $PATH and absolute paths feels hackish to me

github.com/ValveSoftware/steam-for-linux/…/1890

The last comment in that issue is mine, compare my solution to the other solutions that people came out with and you will see it is the least hacky one, before I was even trashing the steam files if it had been launched accidentally in the wrong location lol.

Also this is how snaps and appimages integrate into the system. You add their location to PATH and it is done. You don’t even need sudo to do these changes.

there are better options. I mean something like a bind mount

Do I need elevated privileges to do that?

I’m not saying we should get rid of $PATH right now.

I don’t think we should ever get rid of it, the reasons it may have been created may not be needed today, doesn’t mean it is no longer useful, like the several examples I just gave you.

Do you think the same of LD_LIBRARY_PATH? It is very useful for locally compiled applications, like i3 for example, which I compile and install into my system with a patch that is not merged into the released i3 package. Because installing it into the system /bin and /libs causes my package manager to complain that certain files already exist when updating/installing other applications.

Also do you feel the same about the XDG Base dir spec? like for example XDG_DATA_HOME, XDG_CONFIG_HOME, etc are environment variables like PATH which let you move their location around.

Samueru,

I do, and used it today as well. My AMD gpu sometimes when booting fails to set the correct resolution on the 3rd display, and that causes the graphical session to freeze for some reason and I have to force a restart with sysreq and start the graphical session with a weird script that sets a custom res lol.

Samueru, (edited )

I love Thunar, has a ton of features + plugin support and it is very fast when opening, here is a benchmark I did on the launch time:

PCManFM (the old one): 0.15 seconds.

Thunar: 0.36 seconds.

PCManFM-Qt: 0.39 seconds.

Nemo: 0.47 seconds.

Dolphin: 0.78 seconds.

mmmm: 1.73 seconds. (I feel like I don’t even need to say which one this is lol)

Samueru,

Lol you remind me of the people that get mad when someone talks badly about their favorite video game console.

Samueru,

Btrfs compression is filesystem wide, and it is usually zstd (the same compression that newer appimages are using, however appimages use zstd 15 by default while filesystem it is usually zstd 3 or less).

Yeah turns out that if I were to decompress all my appimages and run them that way, Btrfs filesystem compression would mitigate the issue of having several duplicated libraries.

I actually made a concept appimage for suyu that had the x86-64 v2 and x86-64 v3 binaries in it with a script that determined which binary to use depending on the system, and even though the appimage was shipping two 38 MiB similar binaries, the actual size increase in the resulting appimage was only 6 MiB thanks to the compression in the appimage.

Samueru, (edited )

Overall that also gives us ability to have multiple instances of the same app installed multiple times from different sources.

You can’t just type this like that while ignoring the fact that appimages also let you do that.

Flatpak is for desktop apps

Yeah and unfortunately I’ve already seen takes of people saying that snaps are better than flatpaks because snaps are CLI friendly and “why would I have two different systems when one does everything”, this was just a bad decision on flatpaks side.

Imo, nixos does what flatpak tries to do much better, and more importantly you can run nix alone as its own thing, while flatpak has to be on top of a existing distro.

Wayland support is intentionally broken by AppImage creator/maintainer just to be able to point finger at Wayland ecosystem and say: look - unfixable.

Link?

Also btw, wayland has been insanely broken for me, this is mostly because I’m stuck with sway as my only option though, I have 4 bug reports still open that came from two days of trying to use sway.

AppImage maintainers also showed their disappointing attitude when trying to get OBS to use it, assuming everyone will be interested in having that package format published on official projects website, while conforming to all requirements and doing the work of adjusting app to that format. To no surprise, OBS was horribly broken when built that way, and they demanded OBS devs to fix it, not getting how could they possibly not be interested in having app image, while already having well built (I use it myself, it’s great) Flatpak package.

I use OBS-studio as an appimage made by a guy that basically wraps the aur package in a junest enviroment. It is actually a whole distro in a small package at this point, the downside is that it makes this appimage 172 MiB. Which is meh. Could be better but it is better than either depending on my distro (I have ptsd from using voidlinux if you didn’t know lol) to provide me a obs-version that works, or install the whole flatpak and hope that the obs-flatpak doesn’t actually break (and this last step will be way more than 172 MiB due to the runtimes).

Flatpak does sandboxing with fine tuning abilities (using something like Flatseal or new KDE’s built-in KCM) + there is actual verification process at least for new apps on Flathub. I don’t say it’s 100% safe, but compare that to AppImages which is just running randomly downloaded binaries from the web with full filesystem access.

Cool, if only the rest wasn’t as bad.

Samueru,

I also was at the yuzu linux-support channel before they closed down, and you have no idea how many times I saw people complaining that yuzu was broken and when I told them to use the appimage it fixed their issue every single times, there was even one case where the person wasn’t even buying what I was telling them until the moment they noticed their crashing issue instantly went away with the appimage lol:

imgur.com/p6aby3Z.png

This is because the mesa version that flatpak uses was (and likely still is) too old, and specially with amd gpus that let to users running into bugs that had been fixed for over a year in other distros.

Samueru,

Might wanna improve the reading skills there, because I even mentioned here that appimages suck because the runtime doesn’t statically link glibc and that would improve their compatibility to 100% if they did (would work on musl distros).

going on all-caps rages

Yeah I can’t take blatantl lies like those that say that appimages bloat the system while promoting flatpaks, and I’ve already shared you enough info showing that is utterly false.

I’m considering calling you IMAX.

You’re funny lol.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • cubers
  • DreamBathrooms
  • InstantRegret
  • tacticalgear
  • magazineikmin
  • Youngstown
  • thenastyranch
  • mdbf
  • slotface
  • rosin
  • modclub
  • kavyap
  • ethstaker
  • provamag3
  • osvaldo12
  • khanakhh
  • cisconetworking
  • Durango
  • everett
  • ngwrru68w68
  • Leos
  • normalnudes
  • GTA5RPClips
  • tester
  • megavids
  • anitta
  • lostlight
  • All magazines
    •