Gentoo Archives: gentoo-user

From: Michael Mol <mikemol@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] InitRAMFS - boot expert sought
Date: Thu, 29 Mar 2012 16:01:14
In Reply to: Re: [gentoo-user] InitRAMFS - boot expert sought by Neil Bothwick
1 On Thu, Mar 29, 2012 at 10:43 AM, Neil Bothwick <neil@××××××××××.uk> wrote:
2 > On Thu, 29 Mar 2012 10:21:15 -0400, Michael Mol wrote:
3 >
4 >> > That, IMO, is the problem with the current filesystem layout. The
5 >> > split between / and /usr is anything but well-defined. Putting things
6 >> > in different boxes based on their function is good practice. Doing it
7 >> > based on some arbitrary size limit on the box is not.
8 >>
9 >> Except that's not what people are doing. According to what I've read,
10 >> that was the original rationale a couple decades ago, but that hasn't
11 >> been the driving case for it for a long time, and pointing to it in a
12 >> modern context is silly.
13 >
14 > No, that's not the reason for doing it now.
16 For the sake of sane conversation, then, don't use phrases like
17 "Putting things in different boxes based on their function is good
18 practice. Doing it based on some arbitrary size limit on the box is
19 not." unless it has present context. Referencing an environmental
20 constraint from twenty years ago in current-context discussion about
21 system engineering only clouds the issue.
23 This is part of the problem around this whole conversation dating back
24 to *last summer*; things are referenced outside of their useful
25 context, are presumed to be part of the current context, and get mixed
26 in. It all becomes a confusing mess.
28 > The reason for doing it now
29 > has been applied to the previous solution (generally a bad idea) and is
30 > aimed at making / a self-contained bootable system, which is a movable
31 > target as hardware evolves.
33 I don't think I've seen this adequately described or explained,
34 honestly. How is the target moving? If someone wants to put / on a
35 filesystem that the kernel doesn't have automagic support for, I can
36 see that. Otherwise...not really.
38 >
39 >> These days, you put things on different mount
40 >> points because you want different underlying characteristics either in
41 >> the filesystem or its underlying block device.
42 >
43 > And for the vast majority of use cases, separating /bin and /usr/bin does
44 > not make much sense.
46 For the vast majority of use cases, having more than one display or
47 keyboard doesn't make sense, either. For the vast majority of use
48 cases, one shouldn't need more than one desktop environment installed.
49 For the vast majority of use cases, one shouldn't need more than one
50 optical drive, or more than one USB stick, or more than one
51 authentication backend.
53 That doesn't mean those use cases should be discarded. It means the
54 system should be designed to be flexible.
56 It makes about exactly as much sense for /bin and /usr/bin to be
57 separate directories as it makes sense to mirror the bulk of an OS
58 into a cpio blob that will be loaded into RAM. The initramfs likely
59 won't even fit into some production systems' RAM. I know a talented
60 professional sysadmin/IT guy who has most of his production VMs
61 running some variant of RHEL or CentOS, with only 64M of RAM apiece.
62 Because that makes *sense* when physical RAM may be cheap, but your
63 virtualization vendor bilks you for the difference.
65 So, OK. System bloats again, we can deal. We've been dealing with
66 increasing RAM, disk and CPU requirements for decades. We've even
67 stopped deriding Microsoft for having a bloated platform, given that
68 we can't fend off the bloat ourselves. We eat some crow and move on.
69 Apple and Android's lightweight-by-comparison 'our way or the highway'
70 platform mentalities gain traction and outperform us.
72 So where do we go from here? We have an initramfs which is painfully
73 difficult to keep up to date by hand, as more and more uber-cool
74 things will evolve dependencies on being present early-on. We'll
75 *need* an automated means of keeping the initramfs up-to-date, because
76 not everything supports static linking, and hand-walking the dynamic
77 linking chain is crazy talk.
79 Which means automated tools. These automated tools are going to have
80 to deal with at least as bad an issue of moving targets as keeping /
81 bootable was; they're a full layer of abstraction away from the main
82 system than / was.
84 >
85 >> The gripe about the filesystem layout strikes me as a "it works, but
86 >> it isn't clean or elegant" complaint. That means changing it is change
87 >> for change's sake. And we're going to experience these growing pains
88 >> tenfold as the consequences of that play out.
89 >
90 > It's never been clean or elegant, but it was tolerated and worked around.
91 > Now those that are trying to work around it have said they are no longer
92 > going to do so, which is their choice.
94 I love how this is described as "hey, the decision has been made. It's
95 here to stay." I love how the people described as They are treated as
96 infallible, and the decisions perfect and final.
98 There have been dozens of intelligent suggestions coming from
99 intelligent and well-meaning people, including people making arguments
100 in good faith. They were told they have to either bend over or code.
101 And when they started coding, they got mocked.
103 It's really only going to be upstream's choice until someone takes the
104 choice away from them, either from users migrating away to the point
105 where their paycheck is in danger, or the codebase forking and having
106 the stupid thing done *right*.
108 > If the separate /usr had been
109 > allowed to die when 20MB hard disks were around, this whole situation
110 > would never have arisen.
112 Perhaps. But then perhaps the dozens of incredibly useful systems and
113 new use cases would never have cropped up, either.
115 > The trouble with shit hitting the fan is that the longer you wait the
116 > more there is to spread around :(
118 It was all very nicely concentrated in one place. It could have been
119 dealt with in one place, where a bunch of people very aware of the
120 bulk of the picture could try to find a good solution to a sticky
121 problem.
123 Instead of cleaning up all the shit while it sat in a concentrated
124 place, it got flung out in all directions, increasing the burden on
125 everyone who's actively involved in the bleeding edge areas of system
126 usage and software development.
128 This is going to slow down use and development of anything that
129 depends on those bleeding edges, which is where interesting and new
130 things happen. This will definitely be killing off things which held
131 promise.
133 --
134 :wq