zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. captai+Nf[view] [source] 2022-05-11 08:45:07
>>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.

◧◩
2. pmoria+ww[view] [source] 2022-05-11 11:37:25
>>captai+Nf
"/sbin, /usr/sbin is for binaries that need root"

No, they're for statically linked executables.

◧◩◪
3. sph+J11[view] [source] 2022-05-11 14:20:04
>>pmoria+ww
The s stands for superuser, not static.
[go to top]