1 |
On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick <neil@××××××××××.uk> wrote: |
2 |
> On Thu, 29 Mar 2012 15:56:28 +0000, Alan Mackenzie wrote: |
3 |
> |
4 |
>> > Well, for one, the initramfs solution is not generally considered |
5 |
>> > "ugly" except by a select vocal few who object to it on vague, |
6 |
>> > unarticulated grounds. |
7 |
>> |
8 |
>> I'll articulate a few. (i) The initramfs involves having two copies of |
9 |
>> lots of software around. |
10 |
> |
11 |
> Lots? For most people busybox is enough! If you want encrypted |
12 |
> filesystems on LVM over RAID that rises to a total of four executables. |
13 |
|
14 |
And anything they might conceivably link to. Not everything supports |
15 |
static linking. |
16 |
|
17 |
Don't forget boot-time X-based animation, too. That's an |
18 |
extraordinarily common feature of mainstream desktop distributions. |
19 |
And there will be other things, I'm sure. |
20 |
|
21 |
>> (ii) What's more, these two copies are often |
22 |
>> different, one being built with static libraries, the other with dynamic |
23 |
>> ones. (iii) This situation is not (as far as I know) yet handled by |
24 |
>> Portage, which means in building such software statically, you've got to |
25 |
>> save the dynamic version somewhere else whilst you're doing it. |
26 |
> |
27 |
> That's wrong. For example, LVM builds dynamic executable plus the |
28 |
> lvm.static file for use in the initramfs. |
29 |
|
30 |
That's exactly what Alan just noted in (ii), but perhaps portage |
31 |
handles (iii) in the case of LVM. |
32 |
|
33 |
>> (iv) |
34 |
>> The initramfs requires a potentially long script to make it work. |
35 |
> |
36 |
> Mount /proc, /sys and /dev. |
37 |
> Mount root |
38 |
> Unmount /proc, /sys and /dev. |
39 |
> switch_root |
40 |
|
41 |
Things look much simpler when you abstract away the details. You still |
42 |
have to manage lvm, mdraid and whatever else is necessary for mounting |
43 |
things. That's where 'potentially long' came from, I expect. |
44 |
|
45 |
>> I think that qualifies the initramfs solution as ugly. |
46 |
> |
47 |
> Only if you build the initramfs with USE="fud". |
48 |
|
49 |
FUD: "Fear, uncertainty and doubt" |
50 |
|
51 |
In short, three things which are important to rationally examine and |
52 |
deal with on a case-by-case basis. |
53 |
|
54 |
Fear of risk is healthy when trying to maintain something. |
55 |
|
56 |
Uncertainty is expected when you first launch into some brave, new |
57 |
world, and it's necessary to to learn things well enough to be able to |
58 |
rule out uncertain conditions. That's an intrinsic part of systemic |
59 |
stability. |
60 |
|
61 |
Doubt is another word for risk analysis. What are the chances this |
62 |
will fail, versus the chance that that will fail? What's the cost of |
63 |
each of these failures. |
64 |
|
65 |
-- |
66 |
:wq |