zlacker

I can recall any Linux distro or Unix variant setup in the way you describe. In addition, the Filesystem Hierarchy Standard disagrees with you.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

You may be thinking of the /bin and /usr/bin difference, though.

>>rascul+(OP)
I believe they're referring to the old SunOS (at least) convention that /sbin was for utilities that could be run during the boot process before /usr was mounted. These tended to need to be statically linked, as the .so libraries were all under /usr. SunOS was how I learned the Unix filesystem layout, but of course that means a lot of my ideas of what "should" be where are outdated at this point.

>>techno+a8
> I believe they're referring to the old SunOS (at least) convention that /sbin was for utilities that could be run during the boot process before /usr was mounted

My memory is hazy but I recall the distinction being / vs /usr not /bin vs /sbin.

>>rascul+W9
The article we're commenting on has that as the justification for /usr/bin and /bin in the second paragraph.

>>techno+a8
Rather, the convention was that /sbin was for static binaries so that the system could still be fixed online if the dynamic linker got hosed. It's not about /usr not being mounted, but /lib/ld-linux.so not functioning correctly. For that reason, glibc still ships (or used to ship) an sln binary (static ln), and Debian still offers sash (stand-alone shell): so you could at least try to restore the dynamic library link farm by hand.

But I have only ever seen historic references to that argument, from back when dynamic linking was scary and unreliable. I certainly have never encountered that situation in almost 25 years of using Linux.