zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. M95D+qx[view] [source] 2026-01-04 17:18:58
>>csmant+(OP)
Sometime around 2000 someone decided that /bin and /sbin isn't enough to boot and mount the rest of the system, so they added further complexity: an initrd/initramfs that does the basic job of /bin and /sbin. They had to complicate the kernel build process, the kernel update, the bootloader, the kernel command line and for what? Just because they didn't want the kernel to have the storage drivers built-in?

So the /bin /sbin became redundant.

Sometime around 2020 someone observed that no current Linux can boot without /usr anyway. So what did they do? Move everything from /usr to / and drop the whole /usr legacy? Noooo, that would be too simple. Move / to /usr. And because that is still too simple, also move /bin, /sbin and /usr/sbin to /usr/bin, and then keep symlinks at the old locations because who's gonna fix hardcoded paths in 99% of all Linux apps anyway??

Oh, how I wish I was born in the '60s, when the world was still sane.

◧◩
2. mjg59+FK[view] [source] 2026-01-04 18:36:43
>>M95D+qx
/ has to be writeable (or have separate writeable mounts under it), /usr doesn't. The reasons for unifying under /usr are clearly documented and make sense and it's incredibly tedious seeing people complain about it without putting any effort into understanding it.
◧◩◪
3. M95D+kS[view] [source] 2026-01-04 19:27:49
>>mjg59+FK
Documented where?
◧◩◪◨
4. mjg59+FZ[view] [source] 2026-01-04 20:17:12
>>M95D+kS
https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor..., for example
◧◩◪◨⬒
5. M95D+MK3[view] [source] 2026-01-05 18:07:58
>>mjg59+FZ
OK, there are 4 reasons listed there:

> Improved compatibility [...] That means scripts/programs written for other Unixes or other Linuxes and ported to your distribution will no longer need fixing for the file system paths of the binaries called, which is otherwise a major source of frustration. [..]

Scripts authors should use the binary name without a path and let the user's $PATH choose which binary to use and from where.

This union denies me the choice of using the statically linked busybox in /bin as a fallback if the "full" binaries in /usr are corrupted or segfaults after some library update.

> Improved compatibility with other Unixes (in particular Solaris) in appearance [...]

I don't care about appearances and I care even less about what Solaris looks like.

Did they take a survey of what Linux users care about, or just imposed their view on all of us because they simply know better? Or were paid to "know better" - I never exclude corruption.

> Improved compatibility with GNU build systems. The biggest part of Linux software is built with GNU autoconf/automake (i.e. GNU autotools), which are unaware of the Linux-specific /usr split.

Yeah, right. Please explain to me how GNU, the userspace of 99% of all Linux distributions isn't aware of Linux-specific /usr split.

And how is this any different from #1 ?

> Improved compatibility with current upstream development

AKA devs decided and users' opinion is irrelevant. This explains why GNU isn't aware of Linux /usr split - they simply don't want to be aware.

[go to top]