> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng