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.

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.

> 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.

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