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