alt Hacker NewsOh thanks, I totally missed that distinctions. You’re right.
My first thought is to wonder: why would systemd care about this then? Any idea?
My second thought is: with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? My understanding is that sbin has historically been useful to have statically linked binaries that can be made available early during boot without needing various lib dirs mounted. But that need seems obviated by a unified /usr…
Replies
1718627440 • yesterday at 10:55 AM
sbin is for binaries intended for the superuser, so it is only in the PATH for root, but not for anyone else. This is useful as it doesn't bloat the completions with stuff I never care to run anyways.
> with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin?
There really isn't any, the sysmlink being for compat. Early boot is nowadays taken over by an initrd/initramfs. Some say what you say sbin was for were actually the root /bin (early boot) and /usr/bin (elsewhere) but it was all just so arbitrary and no-one could actually agree on what is for what actually.
Some say sbin is for static binaries, others for superuser binaries and either destinction really doesn't make sense nowadays as earlyboot is initrd and a lot of "superuser binaries" actually also are fine to use unprivlidged in certain scenarios (e.g. `mkfs.*` for making disk images) so having them in a separate dir is just arbitrary (e.g. `cat` can also fail if I cat the shadow file).