I’m curious how software can be created and evolve over time. I’m afraid that at some point, we’ll realize there are issues with the software we’re using that can only be remedied by massive changes or a complete rewrite.
Are there any instances of this happening? Where something is designed with a flaw that doesn’t get realized until much later, necessitating scrapping the whole thing and starting from scratch?
Filesystem Hierarchy Standard
/bin,/dev,/homeand all that stuffWould be a crazy expensive migration though
Definitely. As nice as it would be, I don’t think it will significantly change any time soon, for several reasons. Not least of which is because several programs would likely just flatly refuse to implement such a change, judging by some of them refusing to even consider patches to implement the XDG Base Directory Specification.
So much of that is PDP-11 baggage or derived from it.
Or more generally Very Small Disk baggage.
What’s wrong with it?
$PATHshouldn’t even be a thing, as today disk space is cheap so there is no need to scatter binaries all over the place.Historically,
/usrwas created so that you could mount a new disk here and have more binaries installed on your system when the disk with/binwas full.And there are just so many other stuff like that which doesn’t make sense anymore (
/var/tmpcomes to mind,/opt,/homewhich was supposed to be/usrbut name was already taken, etc …).How would virtual environment software, like conda, work without $PATH?
Today’s software would probably break, but my point is that
$PATHis a relic from ancient times that solved a problem we don’t have anymore.$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.
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/binwas 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
$PATHbecause all binaries are in/binanyways. And to override a binary, you simply “mount” it over the existing one in place.Because a lot of shit would break if that wasn’t the case, starting with every shell script that has the typical
#!/bin/shor#!/bin/bashshebang.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).
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-launcherand call it a day 🙂Having multiple executables with the same name and relying on
$PATHand 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/binand/libscauses 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 likePATHwhich 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
$PATHwhich 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_PATHtoo, or literally any*_PATHenv variable)I’m not saying we should get rid of
$PATHright 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
$PATHas there are better options.