Hacker News Reader

Comment by gjadi | Hacker News Reader

On OpenBSD the split is nicely described in https://man.openbsd.org/man7/hier.7

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

View on HN

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.

> It was discussed a few month ago: https://news.ycombinator.com/item?id=31336396

That just seems mostly BSD being silly stubborn to be honest.

> 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.

It makes sense for OpenBSD because:

- it separates /, /usr and /usr/local

- it has special mount options such as wxallowed which is usually enabled on /usr/local only

https://man.openbsd.org/mount.8 / https://man.openbsd.org/fstab.5

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.

Oh wow indeed!

I didn't follow the news, thanks for the update :)

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).

Curious, what are those reasons?

Package management. It's nice to only have to upgrade one for a system-wide change.

That's the common argument against static linking in general, it's not glibc-specific (or honestly very interesting).

Here's a description of it: https://stackoverflow.com/a/57478728

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.

Reply on news.ycombinator.com