zlacker

>>taubek+(OP)
I once sent out a proposal on the FreeBSD lists to merge /sbin with /bin, and /usr/sbin with /usr/bin. People were concerned that this would slow down the system, due to PATH lookups taking longer. Even when I demonstrated the opposite was true (it being faster due to fewer directories needing to be scanned), I wasn't able to get consensus. What a shame.

>>EdScho+Oa
For me, the value in having a bin vs sbin split is in keeping system binaries (daemons, root-only tools) off the user's path. There's little value in a user starting inetd or apache2 from the command line, so why should those be present in the user's path? Same thing for system management tools that require root access for everything, such as dmsetup, blkdiscard, or shutdown (yes, Linux examples as I don't know FreeBSD).

Having only usable binaries in the path aids discoverability of the system.

>>tremon+Jj
There are many tools in sbin that should have been in bin instead. For example, there’s no need to run ifconfig as root if you only want to display the current set of addresses. Yet it lives in sbin.

This means that in practice people will just add sbin to PATH to get a somewhat usable system, which makes the division between bin and sbin useless.

Furthermore, on BSD derived systems binaries that should not be invoked by users directly (e.g., daemons) need to be stored in libexec.

>>EdScho+Ho
/sbin is for statically linked executables, while /bin is for dynamically linked executables. It has nothing to do with daemons vs non-daemons, nor with things having to run as root.

>>pmoria+vv
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+DB
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+NJ
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.