1 |
On Thu, Mar 29, 2012 at 2:11 PM, Neil Bothwick <neil@××××××××××.uk> wrote: |
2 |
> On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote: |
3 |
> |
4 |
>> On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick <neil@××××××××××.uk> |
5 |
>> wrote: |
6 |
> |
7 |
>> >> I'll articulate a few. (i) The initramfs involves having two copies |
8 |
>> >> of lots of software around. |
9 |
>> > |
10 |
>> > Lots? For most people busybox is enough! If you want encrypted |
11 |
>> > filesystems on LVM over RAID that rises to a total of four |
12 |
>> > executables. |
13 |
>> |
14 |
>> And anything they might conceivably link to. Not everything supports |
15 |
>> static linking. |
16 |
> |
17 |
> Those four all have static version, there are no libraries in my |
18 |
> initramfs. |
19 |
|
20 |
Which is good. |
21 |
|
22 |
> |
23 |
>> Don't forget boot-time X-based animation, too. That's an |
24 |
>> extraordinarily common feature of mainstream desktop distributions. |
25 |
>> And there will be other things, I'm sure. |
26 |
> |
27 |
> I don't get involved with those, but I'd hope something intended to be |
28 |
> run so early would have minimal dependencies, if any. |
29 |
|
30 |
There's a pretty firm distinction between what things get used for, |
31 |
and what they're intended for. The udev developers presumably were |
32 |
reacting to this when they decided to support an "anything goes" |
33 |
policy regarding plugscript behavior. |
34 |
|
35 |
And while I'm generally the kind of person to find unintended (but |
36 |
perfectly compatible with their spec) uses for things, I don't figure |
37 |
on being one to do so in my init sequence. That said, someone else |
38 |
will. That's been a long tradition in open source software and hacker |
39 |
culture. |
40 |
|
41 |
In short, depending on things only being used when they're intended to |
42 |
be used, in the circumstances they're intended to be used in, is |
43 |
sticking one's head into the sand. Workarounds will always arise to |
44 |
break such expectations and assumptions. |
45 |
|
46 |
> |
47 |
>> >> (ii) What's more, these two copies are often |
48 |
>> >> different, one being built with static libraries, the other with |
49 |
>> >> dynamic ones. (iii) This situation is not (as far as I know) yet |
50 |
>> >> handled by Portage, which means in building such software |
51 |
>> >> statically, you've got to save the dynamic version somewhere else |
52 |
>> >> whilst you're doing it. |
53 |
>> > |
54 |
>> > That's wrong. For example, LVM builds dynamic executable plus the |
55 |
>> > lvm.static file for use in the initramfs. |
56 |
>> |
57 |
>> That's exactly what Alan just noted in (ii), but perhaps portage |
58 |
>> handles (iii) in the case of LVM. |
59 |
> |
60 |
> Exactly, there are static and dynamic files, all handled by portage. |
61 |
> |
62 |
>> >> (iv) |
63 |
>> >> The initramfs requires a potentially long script to make it work. |
64 |
>> > |
65 |
>> > Mount /proc, /sys and /dev. |
66 |
>> > Mount root |
67 |
>> > Unmount /proc, /sys and /dev. |
68 |
>> > switch_root |
69 |
>> |
70 |
>> Things look much simpler when you abstract away the details. You still |
71 |
>> have to manage lvm, mdraid and whatever else is necessary for mounting |
72 |
>> things. That's where 'potentially long' came from, I expect. |
73 |
>> |
74 |
>> >> I think that qualifies the initramfs solution as ugly. |
75 |
>> > |
76 |
>> > Only if you build the initramfs with USE="fud". |
77 |
>> |
78 |
>> FUD: "Fear, uncertainty and doubt" |
79 |
>> |
80 |
>> In short, three things which are important to rationally examine and |
81 |
>> deal with on a case-by-case basis. |
82 |
> |
83 |
> Yes, ideally before you start spreading them instead of vague handwaving |
84 |
> about initramfs being ugly and using "lots of files" (four only counts at |
85 |
> lots when applied to wives). |
86 |
|
87 |
Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security |
88 |
auditing. Virtualization tools. Perl, python or whatever is necessary |
89 |
to handle some case which required scripting. X. Graphics loading |
90 |
libraries. Cupsd, because some graphics library required by a |
91 |
bootsplash expressed a dependency on cairo, which expressed a |
92 |
dependency on something else, which expressed a dependency on cups. |
93 |
|
94 |
Perhaps crypto required a crypto daemon to be loaded, which required a |
95 |
smartcard, or required auth from a serial port or network connection. |
96 |
Perhaps an accurate clock is needed. Or perhaps a network policy |
97 |
demands that a machine be authorized to boot, so an LDAP client is |
98 |
required. |
99 |
|
100 |
It's easy to imagine entirely plausible circumstances which would |
101 |
bloat initramfs size and maintenance. At some point in time, these |
102 |
various things would normally be the simplest and most straightforward |
103 |
way to reach a quick end to some problem or another for some poor guy |
104 |
stuck in a private hell. And this initramfs crap increases the amount |
105 |
of work he has to do to solve his unique case. |
106 |
|
107 |
-- |
108 |
:wq |