My dear friend, this is (again!) some beautiful art you got there ! This could easily be the artwork for openbsd 7.6 ! If you don’t mind me I’d like to mention it on /c/openbsd so your work doesn’t go unnoticed? :D
I cannot speak for prahou, but I’m fairly sure we both agree on this:
We call them crowdstals down there. They used to only target ancients NT kernels but apparently they evolved to infect other environments. Eh, nature.
Nope. But I’m eager to know how you can be so confident saying that ? (FYI the WiFi is served by a hotspot from my phone, which uses a randomized MAC address)
Oh I love this style <3 It’s refreshing and yet so comforting because it’s still girl :D
You don’t have any plugins on surf. I personally use a DNS based ad blocker.
It is usable for me, I don’t have issues.
Gotta punch holes in the screen and hammer the keyboard a bit haha. But remember friends, Hardware is forever.
Easy, become a Magnetic Nymph today !
Une dictature, comme vous y allez !
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 use LD_LIBRARY_PATH
too, or literally any env variable)
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.
I’m not saying we should get rid of $PATH
right now. My point is that it was created to solve a problem we don’t have anymore (not enough disk capacity), but we still keep it out of habit.
As a reminder, the discussion is about what should be rewritten from scratch in linux. And IMO, we should get rid of $PATH
as there are better options.
Today’s software would probably break, but my point is that $PATH
is a relic from ancient times that solved a problem we don’t have anymore.
You missed my point. The reason $PATH exists in the first place is because binaries were too large to fit on a single disk, so they were scattered around multiple partitions (/bin
, /sbin
, /usr/bin
, etc…). Now, all your binaries can easily fit on a single partition (weirdly enough, /usr/bin
was chosen as the “best candidate” for it), but we still have all the other locations, symlinked there. It just makes no sense.
As for the override mechanism you mention, there are much better tools nowadays to do that (overlayfs for example).
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.
$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.
Historically, /usr
was created so that you could mount a new disk here and have more binaries installed on your system when the disk with /bin
was full.
And there are just so many other stuff like that which doesn’t make sense anymore (/var/tmp
comes to mind, /opt
, /home
which was supposed to be /usr
but name was already taken, etc …).
C’est pas illégal de le demander à ton/ta collègue cela dit.