> Back in the what, 1970's, the Unix guys
> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
> by separating out statically compiled stuff used in the earliest boot.
Close, not restricted to statically linked, but not dependant on
anything not available in /lib (which were very few) so many binaries
were static.

The *original* purpose was to be able to boot a machine to a state where
it supported network file systems (yes typically nfs, but also others)
and then mount /usr from the network.

In a typical organisation only one server would have very expensive
large hard disk capacity of 20MB or so which would be brought up first
to share its local /usr filesystem read-only to all other nodes.
This server would typically also be the only host with the application
software installed on it.

> But then initramfs made these separate directories unnecessary, so why
> in the world would we continue the split?
Eh? initramfs was originally introduced to provide kernel file and
driver *module* support to allow the kernel to control the hardware
device and read the root file system containing /etc /bin /sbin /lib.

> Well, maybe because initramfs is a PITA many people choose to avoid.
Trivial to work with, no different to the debootstrapping and chrooting
you are familiar with using looped files as devices.

> When things go wrong....SNIP...
Agree 100%

>
> I vote against "the merge"
I also vote against the merge.


The concept of which is at fault anyway, if root file system network
support no longer required the merge should go the other way in any
case, it is /usr/{bin,sbin,lib} that is depreciated.

/usr/bin > /bin
/usr/sbin > /sbin
/usr/lib > /lib

with the exception of special cases which are frequently abused by
distros but are not supposed to be a part of the standard OS and should
stay under /usr.
e.g.

/usr/local
/usr/share