zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. EdScho+Oa[view] [source] 2022-05-11 07:57:55
>>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.
◧◩
2. tremon+Jj[view] [source] 2022-05-11 09:28:48
>>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.

◧◩◪
3. crypto+182[view] [source] 2022-05-11 19:24:27
>>tremon+Jj
> the value in having a bin vs sbin split is in keeping system binaries (daemons, root-only tools) off the user's path

I think it's nice to be able to keep admin utils out of an admin's PATH when the admin isn't intending to use them.

It's much less interesting to me to keep daemons and such out of anyone's PATH if running them can't do much, though usually those things really belong in a libexec directory and should be exec'ed intentionally only.

[go to top]