<p><br>
On Jan 5, 2012 7:10 PM, "Alan McKinnon" <<a href="mailto:alan.mckinnon@gmail.com">alan.mckinnon@gmail.com</a>> wrote:<br>
><br>
> On Thu, 05 Jan 2012 09:17:23 +0100<br>
> pk <<a href="mailto:peterk2@coolmail.se">peterk2@coolmail.se</a>> wrote:<br>
><br>
> > On 2012-01-05 08:43, Alan McKinnon wrote:<br>
> ><br>
> > > I fiddle around a lot with the hardware on those and udev deals with<br>
> > > that nicely considering udev is designed to deal with that nicely.<br>
> ><br>
> > I confess to being quite ignorant when it comes to what magic udev<br>
> > does behind the scenes but what makes it different to any other device<br>
> > manager (well, I don't know any other than mdev but...)? I.e. what<br>
> > technical problem(s) does udev solve that no other device manager<br>
> > can't? What is the technical need for something else than a device<br>
> > file under /dev that can be used to communicate with the kernel?<br>
> ><br>
> > What I mean is: If you say "... considering udev is designed to deal<br>
> > with that..." you seem to indicate that you know what it does and why<br>
> > it does what it does... and henceforth the technical reason why the<br>
> > rearrangements of the file system hierarchy is necessary...<br>
><br>
> I don't claim any special deep knowledge of these things, but a<br>
> superficial glance over the packages tells you a lot. udev is designed<br>
> to deal with any realistic device needs on modern systems - it's the<br>
> kitchen sink.<br>
><br>
> mdev has a much narrower scope where things are considerably more<br>
> static.<br>
><br>
> As for re-arranging the fs layout, I think it was Canek in the last<br>
> thread that gave an excellent example of why this is needed. When<br>
> devices hotplug, or need to become active early on in the boot process,<br>
> they need to run code that can be located almost anywhere. It wouldn't<br>
> be fun trying to get a wireless keyboard going when it's start-up<br>
> script needs to get into /usr/lib/firmware and /usr isn't mounted yet.<br>
><br>
> The example was something along the lines of a machine that has no<br>
> physical keyboard or a port for one, it uses a bluetooth keyboard. But<br>
> the main file systems are encrypted using a key that's on a smartcard.<br>
> To decrypt and mount the filesystems, the drivers for keyboard,<br>
> bluetooth and smart card, plus all firmware, needs to be loaded first.<br>
> This is actually not all that far-fetched, and it's a classic bootstrap<br>
> problem first solved in the 60s. It much more complex now than it was<br>
> then but the principles behind the solution are much the same.<br>
><br>
> I do agree with collapsing the executable code in /usr into /, or<br>
> having /usr on the root partition. A separate /usr/{,s}bin is pretty<br>
> pointless and was never done for safety or maintenance reasons. It was<br>
> done way way way back when disks were small and a convenient hack was<br>
> to keep the OS on the boot device and user apps somewhere else on<br>
> bigger but slower storage (which often was remote).<br>
><br>
> If /usr is local, what really is the point of having it separate<br>
> from /? Have you ever found a Linux system in any condition that could<br>
> not start just because the stuff in /usr was available? I haven't.<br>
><br>
> Even the split between bin and sbin is arbitrary. It's only there so<br>
> that users can take sbin out of PATH and not have the screen cluttered<br>
> with endless junk when they tab-tab. It makes much more sense to me to<br>
> just have one single bin and lib location and shove everything into it.<br>
><br>
> What I do object to is any possible idea that an initramfs will be<br>
> *required* regardless. I know this isn't on the table just yet, but<br>
> it's a very small amount of creep before it is.<br>
><br>
> ><br>
> > > Becoming rather lazy in my old age is getting to be a factor too<br>
> ><br>
> > Ho hum... so "you lazy old fart" is true then? ;-)<br>
><br>
> Dunno about lazy old fart, but splog (snarky pedantic lazy old git)<br>
> definitely is. I think we decided that Neil is the lazy old fart :-)<br>
></p>
<p>After some soul-searching (yes, I still have one despite learning from BOFH), I think I'll agree with Alan... with some caveats.</p>
<p>I have less resistance to requiring /usr to be part of /. The way I see it, I can still do some bind mount black magic to provide a minimal /usr for booting yet isolating the 'real' /usr to prevent it messing up the rootfs. </p>
<p>As to udev, I still think it's an overkill for a static server environment. With virtualization, I can *guarantee* that the (virtual) hardware environment will never change. For these environments, I much prefer mdev to udev. </p>
<p>Finally, regarding initramfs, I wholly agree. Don't force me to use one. A server is already a complex system, and adding complexity won't end up pretty. </p>
<p>Rgds, <br>
</p>