On Thu, Aug 11, 2011 at 2:04 AM, Dale <rdalek1...@gmail.com> wrote: > I understand that Fedora is wanting to do this. What I don't understand is > why. It seems it is udev that is wrecking this havoc.
Well, the answer is a bit more nuanced. First, keep in mind that in a "typical" linux distro the end user does not build their own kernel (sure, there is usually a way to do it, but the distro doesn't encourage this). Instead you get a one-size-fits-all kernel with just about everything compiled into modules. This invariably requires an initramfs to boot, since you can't tell what drivers will be needed to mount root. So, anybody with a mainstream distro already has an initramfs. Now that you have everything in modules, how do you figure out which modules to load/etc? Well, in the end udev becomes the best tool for this. Then the question comes up, if you're going to use udev to configure your mouse, why not use it to configure even the most essential boot-time devices and avoid re-inventing the wheel? So, now the big distros are in the state they're currently in - they end up needing /usr mounted anyway due to the evolution of udev. It sort-of crept up on them. Now, what Fedora is currently proposing is to turn this from a "bug" into a "feature." As long as we need to have /usr around anyway - why not get rid of /bin, /lib, and so on. What they plan to do is move all these files under /usr, with compatibility links in the other root directories. Then you can mount /usr as read-only (or maybe even run it from nfs), and every single executable/library on the system is better protected from accidental modification. This requires initramfs support, but they already have an initramfs and so they just have to add a few lines to mount it (dracut already parses /etc/fstab to mount root and has just about all the userspace logic in place to do what mount already does on a booted system, so it can probably just do little more than a mount /usr to accomplish this). Since most distros are already using an initramfs, they also have leveraged this to add additional features, like identifying root devices by UUID, allowing root on LVM+raid or NFS, or iSCSI, or whatever. Also, LUKS support is pretty common - you can install Ubuntu and check a box and everything gets encrypted. So, basically other distros already need to support initramfs, and they just keep going down a path of leveraging this further. It all stems from their original decision to make one kernel to rule them all, and make it modular so that it doesn't eat up half of RAM in doing so. > I saw it mentioned somewhere that a /run directory can be created. Since it > would likely be small, I wouldn't mind that. I'd be fine if the same files > were installed in both /usr/*bin and /run. So, I believe the purpose of /run is to be a future location for what currently goes in places like /var/run - this is state information, sockets, etc that have no meaning after a reboot. Most likely it would be implemented as a tmpfs or something along those lines. It would not contain copies of anything in /usr/bin/etc. Then /var becomes a place for caches that have meaning between reboots (spools, etc). Rich
