4 ms·

Someone decided to shoehorn Windows Program Files into Linux? Yikes. Jokes aside, this completely ignores the fact that there is a reason for /usr/bin and /usr

Someone decided to shoehorn Windows Program Files into Linux? Yikes. Jokes aside, this completely ignores the fact that there is a reason for /usr/bin and /usr/local/bin and /etc and the sbin directories. A lot of it has to do with permissions. If you've ever been a member of a multi-user server you might understand. I will grant you tho; a lot of people never bother learning and just shove binaries where ever they can get it to work first. In case anyone wants to know. Here is a good explanation: https://unix.stackexchange.com/a/8658 https://unix.stackexchange.com/a/8658

throwanem 3y ago
Nothing in that answer from 2011 even mentions permissions, and most of what it does discuss was pretty outdated even then.
- discardedrefuse 3y ago
  I thought it was implied that bin vs sbin is a permissions thing. What is outdated in that link? I use Fedora 39 Atomic and, as far as I can tell, even it follows these conventions (and even added /var/userlocal for themselves).
  - throwanem 3y ago
    Strictly, the difference between /bin and /sbin versus their siblings in /usr has to do with what you can fit on the RK05 disk pack that the system boots from. If it comes up too broken to mount the DECtape (or if you're lucky and your institution's not cheap, the second RK05) where /usr lives, you'd better be able to fix it with whatever's in /, because until you do that's all you've got. Hence keeping some binaries there, but not too many; your root volume is only a couple megabytes large. Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup. I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr. I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout conventions. Even I'm not old enough to have actually worked with such systems, although I don't miss it by much, and am certainly old enough to have studied a great deal more about them than some. edit: If you're really interested in the topic, then you should certainly spend some time with Rob Landley's collection of historical documents [1], which Google is apparently no longer competent to find based on their content - some of this I was actually looking for in the course of composing this reply, and only found it when I happened to search the name on a mailing list message linked in another reply here. So much for "information wants to be free" - apparently on today's Internet there's no money left in making information able to be found. [1] https://landley.net/history/mirror/index.html https://landley.net/history/mirror/index.html
ufo 3y ago
Sorry, I'm not sure if I get your point. Separating /usr and /usr/local doesn't have to do with permissions; it's just that package manager wouldn't be able to deal with users installing files into /usr and overwriting the package manager's stuff. The whole point of Gobolinux is to avoid this sort of problem. Because each package gets its own directory instead of all being stored in a central location, there's no risk of one package stepping on another package's toes, and it's also possible to install multiple versions of the same package.
- discardedrefuse 3y ago
  Yes, /usr/bin and /usr/local/bin is for the package manager vs user compiled. The link I posted mentioned it. But separating bin from sbin is more of a permissions thing. I suppose you could set permissions individually on each Program folder, but that seems like a pain. The multiple versions thing is pretty nice tho.
  - ufo 3y ago
    In all the distros I know, bin and sbin have the same permissions.
    - usr1106 3y ago
      But sbin is not always in an ordinary user's PATH. They were permitted to run something, but it does not run without an absolute path. (I don't remember in which distro it's in PATH and in which it isn't.)
      - ufo 3y ago
        That's just for convenience though. Users can edit their own PATH as they see fit.
yjftsjthsd-h 3y ago
> Jokes aside, this completely ignores the fact that there is a reason for /usr/bin and /usr/local/bin and /etc and the sbin directories. A lot of it has to do with permissions. If you've ever been a member of a multi-user server you might understand. I've administered multi-user servers and I can only guess at what you mean. Like... I've seen distros that default non-admin users to not having sbin directories in their PATH, but even then it's not like that's a security thing, it just makes your path a little cleaner. What security benefit do you see to the different directories? (In fairness, I can see non-security reasons to split things up - the traditional reason is that /bin is local, /usr is on NFS and shared between every machine in the lab, and /usr/local is non-packaged software built from source. But none of that is a security argument.)
naruhodo 3y ago
Someone else linked this[1] as well. You might benefit from reading it. [1] https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html "I am not clueless"

throwanem 3y ago

Nothing in that answer from 2011 even mentions permissions, and most of what it does discuss was pretty outdated even then.

discardedrefuse 3y ago
I thought it was implied that bin vs sbin is a permissions thing. What is outdated in that link? I use Fedora 39 Atomic and, as far as I can tell, even it follows these conventions (and even added /var/userlocal for themselves).
- throwanem 3y ago
  Strictly, the difference between /bin and /sbin versus their siblings in /usr has to do with what you can fit on the RK05 disk pack that the system boots from. If it comes up too broken to mount the DECtape (or if you're lucky and your institution's not cheap, the second RK05) where /usr lives, you'd better be able to fix it with whatever's in /, because until you do that's all you've got. Hence keeping some binaries there, but not too many; your root volume is only a couple megabytes large. Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup. I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr. I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout conventions. Even I'm not old enough to have actually worked with such systems, although I don't miss it by much, and am certainly old enough to have studied a great deal more about them than some. edit: If you're really interested in the topic, then you should certainly spend some time with Rob Landley's collection of historical documents [1], which Google is apparently no longer competent to find based on their content - some of this I was actually looking for in the course of composing this reply, and only found it when I happened to search the name on a mailing list message linked in another reply here. So much for "information wants to be free" - apparently on today's Internet there's no money left in making information able to be found. [1] https://landley.net/history/mirror/index.html https://landley.net/history/mirror/index.html

ufo 3y ago

Sorry, I'm not sure if I get your point. Separating /usr and /usr/local doesn't have to do with permissions; it's just that package manager wouldn't be able to deal with users installing files into /usr and overwriting the package manager's stuff. The whole point of Gobolinux is to avoid this sort of problem. Because each package gets its own directory instead of all being stored in a central location, there's no risk of one package stepping on another package's toes, and it's also possible to install multiple versions of the same package.

discardedrefuse 3y ago
Yes, /usr/bin and /usr/local/bin is for the package manager vs user compiled. The link I posted mentioned it. But separating bin from sbin is more of a permissions thing. I suppose you could set permissions individually on each Program folder, but that seems like a pain. The multiple versions thing is pretty nice tho.
- ufo 3y ago
  In all the distros I know, bin and sbin have the same permissions.
  - usr1106 3y ago
    But sbin is not always in an ordinary user's PATH. They were permitted to run something, but it does not run without an absolute path. (I don't remember in which distro it's in PATH and in which it isn't.)
    - ufo 3y ago
      That's just for convenience though. Users can edit their own PATH as they see fit.

yjftsjthsd-h 3y ago

> Jokes aside, this completely ignores the fact that there is a reason for /usr/bin and /usr/local/bin and /etc and the sbin directories. A lot of it has to do with permissions. If you've ever been a member of a multi-user server you might understand. I've administered multi-user servers and I can only guess at what you mean. Like... I've seen distros that default non-admin users to not having sbin directories in their PATH, but even then it's not like that's a security thing, it just makes your path a little cleaner. What security benefit do you see to the different directories? (In fairness, I can see non-security reasons to split things up - the traditional reason is that /bin is local, /usr is on NFS and shared between every machine in the lab, and /usr/local is non-packaged software built from source. But none of that is a security argument.)

naruhodo 3y ago

Someone else linked this[1] as well. You might benefit from reading it. [1] https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html "I am not clueless"