Joshua Kinard posted on Tue, 13 Mar 2012 20:16:10 -0400 as excerpted:
> On 03/13/2012 07:54, James Broadhead wrote:
>> I believe that the Art of Unix Programming* says that /usr was the
>> result of the original UNIX 4MB hard disk becoming full, and that they
>> chose /usr to mount a second one. Every definition since then has been
>> an attempt to justify preserving the split.
> Sounds like how a lot of UNIXy things came into being. This is why I
> think /usr should be merged back into /, not the other way around.
> Although, both approaches essentially achieve the same effect in the
> end, once you move /etc and a few other bits, then point the kernel at
I've seen it pointed out that in initr* based systems anyway, the "new"
rootfs is effectively taking the role the old initrd tmproot did, it's
only there in a bootstrapping role, no "running system" content at all,
except that instead of using pivot_root or whatever to get off it once
the system early bootstrap is done, it remains the mountpoint used by
everything else on the running system.
That's rootfs's only modern role, according to these folks, providing the
mountpoints for everything else.
And with an assumed initr* based setup, it all "just works". Rootfs can
in fact be entirely virtual, tmpfs or squashfs or whatever, setup only in
the initr*, with only a few minimal early-boot config files, the modules
necessary to boot the rest of the system, etc, as content, and those
quickly over-mounted with the "real" system -- note that /usr/etc can be
bind-mounted over the boot-time-stub /etc too, so literally, post-initr*,
the ONLY part of rootfs operationally visible is the mountpoints used by
THAT is why they're moving /bin, /sbin and /lib to /usr rather than the
other direction. rootfs will be ONLY a mountpoint, with even /etc/ being
bind-mounted from /usr/etc, and all system data unified on /usr,
Viewed from that perspective, the direction of the "unification",
everything formerly on rootfs moving to /usr, so rootfs' only function is
providing the mountpoints for everything else, has a certain logic to
And they don't care about non-initr* based systems any more than they
care about non-Linux systems or for that matter, non-systemd Linux
systems. That's outside their operational universe. Other people are
welcome to continue working with "legacy" systems if they want, but Linux-
only, systemd-based, initr*-based systems are the only thing they're
interested in supporting, themselves.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman