On Thu, Mar 29, 2012 at 2:11 PM, Neil Bothwick <n...@digimed.co.uk> wrote: > On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote: > >> On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick <n...@digimed.co.uk> >> wrote: > >> >> I'll articulate a few. (i) The initramfs involves having two copies >> >> of lots of software around. >> > >> > Lots? For most people busybox is enough! If you want encrypted >> > filesystems on LVM over RAID that rises to a total of four >> > executables. >> >> And anything they might conceivably link to. Not everything supports >> static linking. > > Those four all have static version, there are no libraries in my > initramfs.
Which is good. > >> Don't forget boot-time X-based animation, too. That's an >> extraordinarily common feature of mainstream desktop distributions. >> And there will be other things, I'm sure. > > I don't get involved with those, but I'd hope something intended to be > run so early would have minimal dependencies, if any. There's a pretty firm distinction between what things get used for, and what they're intended for. The udev developers presumably were reacting to this when they decided to support an "anything goes" policy regarding plugscript behavior. And while I'm generally the kind of person to find unintended (but perfectly compatible with their spec) uses for things, I don't figure on being one to do so in my init sequence. That said, someone else will. That's been a long tradition in open source software and hacker culture. In short, depending on things only being used when they're intended to be used, in the circumstances they're intended to be used in, is sticking one's head into the sand. Workarounds will always arise to break such expectations and assumptions. > >> >> (ii) What's more, these two copies are often >> >> different, one being built with static libraries, the other with >> >> dynamic ones. (iii) This situation is not (as far as I know) yet >> >> handled by Portage, which means in building such software >> >> statically, you've got to save the dynamic version somewhere else >> >> whilst you're doing it. >> > >> > That's wrong. For example, LVM builds dynamic executable plus the >> > lvm.static file for use in the initramfs. >> >> That's exactly what Alan just noted in (ii), but perhaps portage >> handles (iii) in the case of LVM. > > Exactly, there are static and dynamic files, all handled by portage. > >> >> (iv) >> >> The initramfs requires a potentially long script to make it work. >> > >> > Mount /proc, /sys and /dev. >> > Mount root >> > Unmount /proc, /sys and /dev. >> > switch_root >> >> Things look much simpler when you abstract away the details. You still >> have to manage lvm, mdraid and whatever else is necessary for mounting >> things. That's where 'potentially long' came from, I expect. >> >> >> I think that qualifies the initramfs solution as ugly. >> > >> > Only if you build the initramfs with USE="fud". >> >> FUD: "Fear, uncertainty and doubt" >> >> In short, three things which are important to rationally examine and >> deal with on a case-by-case basis. > > Yes, ideally before you start spreading them instead of vague handwaving > about initramfs being ugly and using "lots of files" (four only counts at > lots when applied to wives). Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security auditing. Virtualization tools. Perl, python or whatever is necessary to handle some case which required scripting. X. Graphics loading libraries. Cupsd, because some graphics library required by a bootsplash expressed a dependency on cairo, which expressed a dependency on something else, which expressed a dependency on cups. Perhaps crypto required a crypto daemon to be loaded, which required a smartcard, or required auth from a serial port or network connection. Perhaps an accurate clock is needed. Or perhaps a network policy demands that a machine be authorized to boot, so an LDAP client is required. It's easy to imagine entirely plausible circumstances which would bloat initramfs size and maintenance. At some point in time, these various things would normally be the simplest and most straightforward way to reach a quick end to some problem or another for some poor guy stuck in a private hell. And this initramfs crap increases the amount of work he has to do to solve his unique case. -- :wq
