(New page: Are there any drawbacks to putting <code>/usr/local/sbin:/usr/sbin:/sbin</code> in <code>PATH</code>? Some things (<code>/sbin/start_udev</code> is one example) will never be run by norma...) |
(New section: What is sbin for, anyway?) |
||
| Line 11: | Line 11: | ||
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'... | 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". | 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. <code>/sbin/lsmod</code> runs fine and provides useful information for non-root users, but <code>/usr/bin/bcm43xx-fwcutter</code> is worthless to non-root users since they can't write to <code>/lib/firmware</code> or load modules. | |||
The only real value we get out of the sbin split is the way that <code>consolehelper</code> works, which this feature preserves. | |||
Latest revision as of 21:52, 6 August 2008
Are there any drawbacks to putting /usr/local/sbin:/usr/sbin:/sbin in PATH?
Some things (/sbin/start_udev 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 libexec already exist to contain binaries that are never run by users?
Technically /usr/libexec is for binaries that are never run by humans - they're designed to be spawned by other processes. if /libexec existed, that would be a good place for something like start_udev.
Alternate approach: couldn't we just symlink commonly-used binaries into /bin or /usr/bin?
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. /sbin/lsmod runs fine and provides useful information for non-root users, but /usr/bin/bcm43xx-fwcutter is worthless to non-root users since they can't write to /lib/firmware or load modules.
The only real value we get out of the sbin split is the way that consolehelper works, which this feature preserves.