1 |
Mike Frysinger posted on Mon, 19 Sep 2011 12:05:39 -0400 as excerpted: |
2 |
|
3 |
> On Monday, September 19, 2011 11:35:09 Michał Górny wrote: |
4 |
>> On Mon, 19 Sep 2011 11:11:31 -0400 Mike Frysinger wrote: |
5 |
>> > > > by that token, i'll go ahead and remove glibc's static libraries |
6 |
>> > > > since upstream doesn't even support static linking |
7 |
>> > > |
8 |
>> > > I'm probably ignorant so you'd have to elaborate more on that to |
9 |
>> > > make me see a problem there. |
10 |
>> > |
11 |
>> > think about it a little bit. your system is using static binaries |
12 |
>> > right now, and considering you like to push systemd + initramfs so |
13 |
>> > much, i would have thought you'd realize the implications more |
14 |
>> > quickly. |
15 |
>> |
16 |
>> Hm, I seem to fail to notice other static binaries than busybox. And I |
17 |
>> don't think I use any specific configuration which makes me need static |
18 |
>> binaries; |
19 |
> |
20 |
> by default, tools that are needed to easily recover a system |
21 |
> (busybox/cryptsetup/lvm/etc...) are IUSE=+static, and every binary that |
22 |
> goes into initramfs is statically linked. |
23 |
|
24 |
By default? That's begging the question (logic sense) and consequently |
25 |
does not properly support your blanket "your system is using static |
26 |
binaries right now" statement. |
27 |
|
28 |
That doesn't mean the statement is incorrect. I may well be using static |
29 |
binaries of some sort, but I'm not aware of any (save for grub-static, |
30 |
since I run amd64/no-multilib), and I'd love to know more about which |
31 |
binaries they are, and whether static linking is really necessary for |
32 |
them. Feel free to post a link as I've a feeling this is reasonably |
33 |
basic, but evidently I'm not the only one who would find such info |
34 |
educational and likely useful. |
35 |
|
36 |
FWIW, no busybox here. It wouldn't build when I installed back in 2004, |
37 |
so I package.provided it for later. I tried it again a couple times but |
38 |
by then it was quite clear that it really was NOT needed, so eventually I |
39 |
decided I had better things to do than tilt at that windmill. (I use a |
40 |
second root image, updated AND TESTED when the system appears to be |
41 |
working well, as my emergency recovery solution, thus don't need busybox.) |
42 |
|
43 |
I run (partitioned) md/raid because I can feed appropriate assemble |
44 |
instructions on the kernel command line, no initr* needed. I do NOT use |
45 |
lvm because it would require either an initr* for the root and root- |
46 |
backup images or keeping them separate, needlessly increasing complexity |
47 |
now that md/raid handles partitions transparently, and triggering an |
48 |
answer I simply was not not comfortable with to the "Am I comfortable |
49 |
enough with my setup to be reasonably sure I can recover it without fat- |
50 |
fingering and breaking it instead, under the far higher stresses of a |
51 |
recovery situation?" question. |
52 |
|
53 |
USE="-static -static-libs", no package.use exceptions for them. |
54 |
|
55 |
So what sort of static binaries am I running (other than the pre-packaged |
56 |
grub-static as already mentioned), and are they really necessarily so? |
57 |
|
58 |
>> I'm following the _original_ *nix idea of keeping it simple. |
59 |
> |
60 |
> you're confusing the notion of tradeoffs. the amount of tooling that |
61 |
> shared libraries take to work at all let alone being stable is |
62 |
> significantly higher than a single static binary. |
63 |
|
64 |
Point well taken. There are indeed tradeoffs. |
65 |
|
66 |
I'm choosing ease of administration and a second root image, partly in a |
67 |
deliberate attempt to avoid unnecessarily increasing my chance of fat- |
68 |
fingering a recovery, over the rather more straightforward for the |
69 |
computer, but significantly more complex for the admin, static linking |
70 |
and limited recovery tools strategy. I guess I trust that the computer |
71 |
side, once a backup is tested and found to work, is far more reliable |
72 |
than the human/admin side under stressful-for-humans recovery scenarios, |
73 |
so am deliberately choosing my tradeoffs. |
74 |
|
75 |
-- |
76 |
Duncan - List replies preferred. No HTML msgs. |
77 |
"Every nonfree program has a lord, a master -- |
78 |
and if you use the program, he is your master." Richard Stallman |