I'm just a casual Linux enjoyer. From what I can see, the FHS states[1] the following for the /usr/sbin/ directory:
This directory contains any non-essential binaries used exclusively by the system administrator.
The only interpretation that makes sense to me is that the /usr/sbin/ directory should only contain executables which cannot be run as non-root at all.
So if a non-root user can launch the executable in any way that does not fail due to lack of root privileges, it's not exclusively for the system administrator and should go in /usr/bin/.
Again that's the only interpretation that makes any sense to me. And it would lead to executables potentially moving between them as they gain or lose non-root capabilities.
As such, it might make one wonder what the separation is for, and think the Fedora approach of just merging /usr/sbin/ into /usr/bin/ makes sense.
The history of /sbin and /usr/sbin goes back well before Linux even existed, and a Linux-only filesystem hierarchy convention really does not provide an adequate guide to it and the really complex way, which is not the same from operating system to operating system, that the world reached the way that things are today. There's no clue there, for example, to the history such as the /usr/etc to /usr/sbin move in AT&T System 5, or the /etc to /usr/etc move that preceded that.
A literal reading of this "cannot be run as non-root at all" interpretation would be: no commands ever should be in /usr/sbin, as a regular user might want to see their --help, and this doesn't require root privileges.
I'm just a casual Linux enjoyer. From what I can see, the FHS states[1] the following for the /usr/sbin/ directory:
This directory contains any non-essential binaries used exclusively by the system administrator.
The only interpretation that makes sense to me is that the /usr/sbin/ directory should only contain executables which cannot be run as non-root at all.
So if a non-root user can launch the executable in any way that does not fail due to lack of root privileges, it's not exclusively for the system administrator and should go in /usr/bin/.
Again that's the only interpretation that makes any sense to me. And it would lead to executables potentially moving between them as they gain or lose non-root capabilities.
As such, it might make one wonder what the separation is for, and think the Fedora approach of just merging /usr/sbin/ into /usr/bin/ makes sense.
[1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s10.htm...
The history of /sbin and /usr/sbin goes back well before Linux even existed, and a Linux-only filesystem hierarchy convention really does not provide an adequate guide to it and the really complex way, which is not the same from operating system to operating system, that the world reached the way that things are today. There's no clue there, for example, to the history such as the /usr/etc to /usr/sbin move in AT&T System 5, or the /etc to /usr/etc move that preceded that.
A literal reading of this "cannot be run as non-root at all" interpretation would be: no commands ever should be in /usr/sbin, as a regular user might want to see their --help, and this doesn't require root privileges.
Sarcasm of course.
/usr/sbin is a Chestonian Fence.
There are an unfathomable number of installed Linuxi.
Whatever assumptions one makes about /usr/sbin are not universal.
Ahhhh, more freedom for end-users to do root stuff.
Give a gun to a child, will ya?