Talk:Features/SbinSanity

Are there any drawbacks to putting  in  ? Some things ( is one example) will never be run by normal users and are not used in typical system administration. These things should not be in the PATH for normal users, if it can be avoided.

Doesn't  already exist to contain binaries that are never run by users? Technically  is for binaries that are never run by humans - they're designed to be spawned by other processes. if  existed, that would be a good place for something like.

Alternate approach: couldn't we just symlink commonly-used binaries into  or  ? Yes, but this requires editing and rebuilding dozens of RPMs and constant argument about which binaries deserve special treatment. Lots more work for very little actual improvement.

MatthiasClasen: I don't have any strong opinion on this proposal, but I have to wonder what definition of 'normal user' includes 'regularly uses ifconfig and route'... In that context, "normal user" meant "non-root user".

What is sbin for, anyway?
"sbin" originally stood for "static binaries" - these were statically-linked programs that you could use in case your system completely freaked out.

The binaries in /sbin are not statically linked these days, so that's not the point of the split.

Some people argue that /sbin is for "system binaries", except this is hopelessly vague. runs fine and provides useful information for non-root users, but  is worthless to non-root users since they can't write to   or load modules.

The only real value we get out of the sbin split is the way that  works, which this feature preserves.