The return of devfs

A) It's documented

B) Tools to do things like rebuild the initramfs are easily accessable, documented.

C) The initrd scripts are init-like. They are modular, commented, and occupy a directory
structure in /usr/share/initramfs/ that makes sense according to their purpose and what part
of the boot process they are executed.

D) They have examples on scripts you can make on your own.

E) If you install packages that may impact boot-up proceedures, like maybe some hardware,
like LVM, then hooks are added to that directory structure. If you do not have packages for
LVM then support is not in the initramfs irregardless.

F) It's very easy to add busybox support so that you can do things like shove a 'sh' into the
boot procedure and get a shell to troubleshoot your scripts.

G) It's documented

H) The scripts have examples and decent comments.

It's certainly not perfect and there are better ways to do stuff. But most of the time dealing
with initrd scripts they are just monolithic and very unfriendly.

With a evenings worth of effort I've done things like devise a means to reliably network boot
the system using iSCSI software initiator. I've created layered root file systems using
compressed read-only file systems and things like AUFS, which I used on my EEEPC for a
number of montsh.

I did all this using my own hooks and add-on scripts that didn't affect the the existing Debian
scripts and didn't break when the system was updated.

Sure it ends up creating a little 'mini-linux-distro' that gets loaded into RAM and that ends up
making stuff slow as shit, during the initial boot process, but is actually something that a
experienced administrator can usefully use.

Every other distribution I've used always had the most horrid hacks and special-purpose
scripts that supported whatever configurations the installer supported, but were a pain to deal
with and customize.

Oh, and they were all poorly documented.