> /bin/ User utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
> /sbin/ System programs and administration utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
That distinction only matters when you have / and /usr separate, which basically never makes any sense in practicality.
There is some case to throw /usr/share on separate partition as some packages dump quite a lot data there (kicad for example dumps part libraries there which are like 5+GB), but that's the single case in "basically never" I had something mounted in or under /usr.
But honestly, if you have a case of "I REALLY need a rescue environment that's statically compiled".... just throw a busybox binary on your root partition somewhere. Most distros have it in "busybox-static" package.
> That distinction only matters when you have / and /usr separate, which basically never makes any sense in practicality.
No? The distinction could also be self-imposed, i.e. you just put statically linked "rescue" binaries in /sbin just for the sake of order/principle, even if it happens to be in the same disk or the same partition as /usr.
It may be absolutely pointless, but then so would be literally any other partitioning of files you can think about. E.g. what's the point of creating a directory for each program ala Windows/OSX? What's the point of making sbin vs bin? What's the point of putting data files in share instead of lib? What's the point of creating any hierarchy whatsoever instead of just throwing everything inside the same directory and let the package manager handle it?
You can find very thin arguments for all of these, most of them having to do with historical reasons or subjective reasons, like some human abstractly-defined sense of simplicity, "cleanliness" and order.
And in those months some /sbin programms are now dynamically linked (for security) and the quotes have changed
> /sbin/ System programs and administration utilities fundamental to both single and multi-user environments. Most of these programs are statically compiled and therefore do not depend on any system libraries to run.
That's a nice distinction, but it's not really practical on Linux. Statically linking glibc is explicitly not supported (and for arguably good reasons).
Basically, glibc uses dlopen to open certain shared libraries for things like nsswitch and locales. Using dlopen in a program that's statically linked to glibc causes all kinds of issues, as you'll likely end up with multiple copies of potentially different versions of glibc in the same process.
The main difference is about static linking.
> /bin/ User utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
> /sbin/ System programs and administration utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
It was discussed a few month ago: https://news.ycombinator.com/item?id=31336396