5 ms·

On OpenBSD the split is nicely described in https://man.openbsd.org/man7/hier.7 https://man.openbsd.org/man7/hier.7 The main difference is about static linking

by gjadi 4y ago

On OpenBSD the split is nicely described in https://man.openbsd.org/man7/hier.7 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 https://news.ycombinator.com/item?id=31336396

mort96 4y ago
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).
- asymmetric 4y ago
  Curious, what are those reasons?
  - nousermane 4y ago
    Package management. It's nice to only have to upgrade one for a system-wide change.
    - mort96 4y ago
      That's the common argument against static linking in general, it's not glibc-specific (or honestly very interesting).
  - mort96 4y ago
    Here's a description of it: https://stackoverflow.com/a/57478728 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.
    - deleted 4y ago
      [deleted]
xani_ 4y ago
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 https://news.ycombinator.com/item?id=31336396 That just seems mostly BSD being silly stubborn to be honest.
- AshamedCaptain 4y ago
  > 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.
- gjadi 4y ago
  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/mount.8 / https://man.openbsd.org/fstab.5 https://man.openbsd.org/fstab.5
ben_bai 4y ago
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.
- gjadi 4y ago
  Oh wow indeed! I didn't follow the news, thanks for the update :)

by gjadi 4y ago

mort96 4y ago

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

asymmetric 4y ago
Curious, what are those reasons?
- nousermane 4y ago
  Package management. It's nice to only have to upgrade one for a system-wide change.
  - mort96 4y ago
    That's the common argument against static linking in general, it's not glibc-specific (or honestly very interesting).
- mort96 4y ago
  Here's a description of it: https://stackoverflow.com/a/57478728 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.
  - deleted 4y ago
    [deleted]

xani_ 4y ago

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 https://news.ycombinator.com/item?id=31336396 That just seems mostly BSD being silly stubborn to be honest.

AshamedCaptain 4y ago
> 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.
gjadi 4y ago
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/mount.8 / https://man.openbsd.org/fstab.5 https://man.openbsd.org/fstab.5

ben_bai 4y ago

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.

gjadi 4y ago
Oh wow indeed! I didn't follow the news, thanks for the update :)