Comment by lamontcg

> Also /bin vs /sbin believe is that the latter is meant for statically linked binaries such that if your system is corrupted these at least will keep working.

I think that became the rationale for /[s]bin vs. /usr/[s]bin (although based on the linked article, that may have been retconned a bit).

You were supposed to keep your root/boot filesystem very small and mostly read-only outside major updates. That meant that you could boot to a small amount of utilities (e.g. fsck) that would let you repair /usr or any other volume if it became corrupted.

I think the other poster is correct that stuff like fsck is supposed to go into /sbin because it is a "system" binary (but also statically linked since /usr/lib isn't mounted yet) and doesn't make sense to have in user $PATHs since nobody other than root should really be running that one.

Regardless, this is all deeply meaningless these days, particularly if you are running "ephemeral" infrastructure where if anything goes that wrong you just repave it all and start over.