zlacker

>>taubek+(OP)
I've read this explanation a couple of times, and if you go all the way back to PDP-11 the split does indeed sound ridiculous. I had my first contact with Linux from some magazine CDs in the late 90s, I think it was Red Hat or SUSE based. The documentation there had a much clearer explaination:

/sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash.

The paths without /usr - /bin and /sbin - are available from the get go. It is the very first partition that is mounted, and what is guaranteed to be available if you do "init 1" or boot in single user mode. You can also do fsck from there (assuming the boot partition is not damaged). I don't know how this integrated with initrd (initramfs wasn't a thing yet). I think there was only one "base system" - either initrd was very basic, or the whole base was in initrd, or something similar.

The paths with /usr were managed by the package manager. Word of mouth was: don't install anything manually there. If you do (via make install), keep around the source so you can do make uninstall. But better install to /usr/local or /opt.

>>captai+Nf
> /sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash.

I also got this explanation, but it never made much sense to me. First of all, the binaries there are executable by everyone anyway. Second, it really doesn't matter that they show up during completion. Third, many of them work fine and are quite useful without root! I don't recall the specific examples that bothered me (/sbin and /usr/sbin have been in my PATH forever now), but I think it was something like ifconfig or ping.

>>Athas+Ug
Yes, but you are effectively turning your box into a single user system. And that's fine if you are happy to work that way, but the origins of the directory structure is of course in multiuser UNIX. As a sysadmin, I would not want my /bin /sbin exposed to everyone. In your example I question the security implications of being able to run those binaries outside of root anyway (esp. in a professional environment) if you have your box exposed on a network.

>>digita+Rl
> As a sysadmin, I would not want my /bin /sbin exposed to everyone.

Why not? It's not like most of them are suid (right?). Most Unix systems I've used allow any user to peruse /sbin at their leisure and run whatever they want.

>>Athas+6u
Apologies if I'm missing your point, but yikes - any user on your system can run /sbin/shutdown?