Linked by Thom Holwerda on Wed 2nd Nov 2011 23:17 UTC
/usr/bin, and all libraries to /usr/lib and /user/lib64.
Thread beginning with comment 495436
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Root could be small, readonly, and always there as a failsafe.
These days, we call that "initramfs". Because if you already have a small readonly version of the system that's sophisticated enough to mount root from a network filesystem or an encrypted device, there's not much value in the separate root device at all...
RE[2]: Giving up on recovery
by sorpigal on Thu 3rd Nov 2011 11:40
in reply to "RE: Giving up on recovery"
[...] the whole point of a separate /usr is to enable the system to boot and be repaired without depending on all of the "applications" to be available.
Root could be small, readonly, and always there as a failsafe. [...]
Root could be small, readonly, and always there as a failsafe. [...]
My feelings exactly. The result of moving /bin and /sbin to /usr will be a major clusterfuck. The OS graveyard is full of Unices which did that. Think HP-UX. Oh, and it will make mounting /usr from NFS even more nightmarish than it is now. So I say first implement union directories a la Plan 9 (aufs is fine but doesn't come anywhere close to that) and improve u9fs, and then screw with the filesystem layout as much as you wish.





Member since:
2005-12-04
It makes sense in the context that Fedora requires /usr to be populated in order to boot today, but the whole point of a separate /usr is to enable the system to boot and be repaired without depending on all of the "applications" to be available.
Root could be small, readonly, and always there as a failsafe. Becoming more monolithic really makes it harder to recover when things go wrong - if your openoffice install corrupts some part of the filesystem tree, you'll need more dramatic recovery options (eg. boot from CD/DVD.)