> 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.
My understanding is that sbin for system binaries, not necessarily statically linked. Normally /sbin is only in root's PATH, not normal user's. They are likely world executable, but in many cases you cannot actually run them as non-root since they usually touch things only root can access without special access (e.g. raw devices, privileged syscalls, /etc/shadow etc.). Not always though, like you can run /sbin/ifconfig as normal user in read-only mode.
The 's' is for 'static' version of the explanation of the name of sbin is not actually supported by any 20th century Unix doco. The books on AT&T Unix System 5 (before which, things were in /etc) that actually give an explanation for sbin all say system binaries, or system administration commands; and none of them says anything about linkage.
The 'static link' story came from Linux people years afterwards. Here's Ian McCloghrie correcting this misconception in a Linux discussion back in 1993:
My understanding is that sbin for system binaries, not necessarily statically linked. Normally /sbin is only in root's PATH, not normal user's. They are likely world executable, but in many cases you cannot actually run them as non-root since they usually touch things only root can access without special access (e.g. raw devices, privileged syscalls, /etc/shadow etc.). Not always though, like you can run /sbin/ifconfig as normal user in read-only mode.