this post was submitted on 11 Apr 2024
166 points (95.1% liked)
Linux
48652 readers
1025 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
By mounting the binary over, I mean something like a bind mount. But in your case of a wrapper script, it doesn't apply indeed. Though in this case I would simply name the script
steam-launcher
and call it a day 🙂Having multiple executables with the same name and relying on
$PATH
and absolute paths feels hackish to me, but that's only a matter of preference at this point.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.
https://github.com/ValveSoftware/steam-for-linux/issues/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.
Do I need elevated privileges to do that?
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 likePATH
which let you move their location around.Right now overlays requires elevated privilèges, but ideally it shouldn't. Rewriting the Linux kernel to implement per user namespaces like plan9 does would allow unprivileged actions from any user (just like if any user was sitting in a container, overlayed from the base system).
I know we're not there, and that's not the direction development is going, but this thread is about dreams, right ? 😉
About the XDG specs, they serve a totally different purpose so they're out of the discussion IMO. I'm not advocating against env variables. Just
$PATH
which is a workaround as I see it, but your mileage may vary. As for your "issue" with steam, of course this is the best way to solve it. Because of today's OS limitation. My point is that with a better designed namespacing implementation, there would be more elegant solutions to solve it (and would get rid of the need to useLD_LIBRARY_PATH
too, or literally any*_PATH
env variable)