Even if you have su privileges you aren't using them all the time. You may have scripts launched by an unprivileged user that in turn run as root. There are similar things that may happen on a shared system like a cluster. This is a regression in functionality for dubious benefits.
I didn't literally mean 'sbin is useless' -more that the days when we believed there was some constraint on being able to run some commands ended, when we stopped thinking those commands were run by other people, and instead run by ourselves.
Now, it has become routine to include /sbin and /usr/sbin in the PATH, and so we find ourselves having to su(do) thing, because we forget that it may look "runnable" and be found, but demands privilege to execute.
In days of yore when I started my journey, we didn't give ordinary logins these elements in PATH, and we believed in our UID/GID protection rings as well because sudo didn't exist. To be admitted to knowing the root password demanded you do the stonecutters walk of shame with the rock round your neck into the operations room at the end by the Dec-10. You also got the key to the cupboard where all the serial lines terminated, and access to a kettle and tin of bad instant coffee.
The feature of /usr/sbin is precisely that I can choose to put or not put it in my PATH. Sad to see it go away, as it removes user choice and I don't see what it yields. Why does everything needs to be under a single directory? Why can't there be classification?
The purpose of `/usr/sbin` does not seem to be understood here. It is (as far as I know) for statically linked binaries. If you use dynamically-linked libraries, those can potentially be manipulated via LD_PRELOAD or something. So admin software is probably something that should be in this category. There might be other reasons I'm not aware of for having a category for statically linked stuff. This means little if nobody is checking on the distro side to make sure that sbin is filled with statically linked stuff.
I don't want to attribute this change to malice because it is a rather arcane detail, but let's just say that I don't approve of IBM's recent activities related to Linux and FOSS.
> It is (as far as I know) for statically linked binaries.
No, it’s for system binaries or superuser binaries (depending on which you prefer, I’ve heard people say it both ways). I’m see people say it’s because they are statically linked but the Filesystem Hierarchy Standard says it’s “system” [0].
The path made sense when a system was run by people distinct from the ones using it. The death knell was workstations and giving us all su privileges.
In that world view, the death knell was sounded in the 1980s.
Even if you have su privileges you aren't using them all the time. You may have scripts launched by an unprivileged user that in turn run as root. There are similar things that may happen on a shared system like a cluster. This is a regression in functionality for dubious benefits.
I didn't literally mean 'sbin is useless' -more that the days when we believed there was some constraint on being able to run some commands ended, when we stopped thinking those commands were run by other people, and instead run by ourselves.
Now, it has become routine to include /sbin and /usr/sbin in the PATH, and so we find ourselves having to su(do) thing, because we forget that it may look "runnable" and be found, but demands privilege to execute.
In days of yore when I started my journey, we didn't give ordinary logins these elements in PATH, and we believed in our UID/GID protection rings as well because sudo didn't exist. To be admitted to knowing the root password demanded you do the stonecutters walk of shame with the rock round your neck into the operations room at the end by the Dec-10. You also got the key to the cupboard where all the serial lines terminated, and access to a kettle and tin of bad instant coffee.
The feature of /usr/sbin is precisely that I can choose to put or not put it in my PATH. Sad to see it go away, as it removes user choice and I don't see what it yields. Why does everything needs to be under a single directory? Why can't there be classification?
The purpose of `/usr/sbin` does not seem to be understood here. It is (as far as I know) for statically linked binaries. If you use dynamically-linked libraries, those can potentially be manipulated via LD_PRELOAD or something. So admin software is probably something that should be in this category. There might be other reasons I'm not aware of for having a category for statically linked stuff. This means little if nobody is checking on the distro side to make sure that sbin is filled with statically linked stuff.
I don't want to attribute this change to malice because it is a rather arcane detail, but let's just say that I don't approve of IBM's recent activities related to Linux and FOSS.
> It is (as far as I know) for statically linked binaries.
No, it’s for system binaries or superuser binaries (depending on which you prefer, I’ve heard people say it both ways). I’m see people say it’s because they are statically linked but the Filesystem Hierarchy Standard says it’s “system” [0].
[0] https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...