Re: [gentoo-user] InitRAMFS - boot expert sought

[Michael Mol]

On Thu, Mar 29, 2012 at 10:43 AM, Neil Bothwick <neil@××××××××××.uk> wrote:
> On Thu, 29 Mar 2012 10:21:15 -0400, Michael Mol wrote:
>
>> > That, IMO, is the problem with the current filesystem layout. The
>> > split between / and /usr is anything but well-defined. Putting things
>> > in different boxes based on their function is good practice. Doing it
>> > based on some arbitrary size limit on the box is not.
>>
>> Except that's not what people are doing. According to what I've read,
>> that was the original rationale a couple decades ago, but that hasn't
>> been the driving case for it for a long time, and pointing to it in a
>> modern context is silly.
>
> No, that's not the reason for doing it now.

For the sake of sane conversation, then, don't use phrases like
"Putting things in different boxes based on their function is good
practice. Doing it based on some arbitrary size limit on the box is
not." unless it has present context. Referencing an environmental
constraint from twenty years ago in current-context discussion about
system engineering only clouds the issue.

This is part of the problem around this whole conversation dating back
to *last summer*; things are referenced outside of their useful
context, are presumed to be part of the current context, and get mixed
in. It all becomes a confusing mess.

> The reason for doing it now
> has been applied to the previous solution (generally a bad idea) and is
> aimed at making / a self-contained bootable system, which is a movable
> target as hardware evolves.

I don't think I've seen this adequately described or explained,
honestly. How is the target moving? If someone wants to put / on a
filesystem that the kernel doesn't have automagic support for, I can
see that. Otherwise...not really.

>
>> These days, you put things on different mount
>> points because you want different underlying characteristics either in
>> the filesystem or its underlying block device.
>
> And for the vast majority of use cases, separating /bin and /usr/bin does
> not make much sense.

For the vast majority of use cases, having more than one display or
keyboard doesn't make sense, either. For the vast majority of use
cases, one shouldn't need more than one desktop environment installed.
 For the vast majority of use cases, one shouldn't need more than one
optical drive, or more than one USB stick, or more than one
authentication backend.

That doesn't mean those use cases should be discarded. It means the
system should be designed to be flexible.

It makes about exactly as much sense for /bin and /usr/bin to be
separate directories as it makes sense to mirror the bulk of an OS
into a cpio blob that will be loaded into RAM. The initramfs likely
won't even fit into some production systems' RAM. I know a talented
professional sysadmin/IT guy who has most of his production VMs
running some variant of RHEL or CentOS, with only 64M of RAM apiece.
Because that makes *sense* when physical RAM may be cheap, but your
virtualization vendor bilks you for the difference.

So, OK. System bloats again, we can deal. We've been dealing with
increasing RAM, disk and CPU requirements for decades. We've even
stopped deriding Microsoft for having a bloated platform, given that
we can't fend off the bloat ourselves. We eat some crow and move on.
Apple and Android's lightweight-by-comparison 'our way or the highway'
platform mentalities gain traction and outperform us.

So where do we go from here? We have an initramfs which is painfully
difficult to keep up to date by hand, as more and more uber-cool
things will evolve dependencies on being present early-on. We'll
*need* an automated means of keeping the initramfs up-to-date, because
not everything supports static linking, and hand-walking the dynamic
linking chain is crazy talk.

Which means automated tools. These automated tools are going to have
to deal with at least as bad an issue of moving targets as keeping /
bootable was; they're a full layer of abstraction away from the main
system than / was.

>
>> The gripe about the filesystem layout strikes me as a "it works, but
>> it isn't clean or elegant" complaint. That means changing it is change
>> for change's sake. And we're going to experience these growing pains
>> tenfold as the consequences of that play out.
>
> It's never been clean or elegant, but it was tolerated and worked around.
> Now those that are trying to work around it have said they are no longer
> going to do so, which is their choice.

I love how this is described as "hey, the decision has been made. It's
here to stay." I love how the people described as They are treated as
infallible, and the decisions perfect and final.

There have been dozens of intelligent suggestions coming from
intelligent and well-meaning people, including people making arguments
in good faith. They were told they have to either bend over or code.
And when they started coding, they got mocked.

It's really only going to be upstream's choice until someone takes the
choice away from them, either from users migrating away to the point
where their paycheck is in danger, or the codebase forking and having
the stupid thing done *right*.

> If the separate /usr had been
> allowed to die when 20MB hard disks were around, this whole situation
> would never have arisen.

Perhaps. But then perhaps the dozens of incredibly useful systems and
new use cases would never have cropped up, either.

> The trouble with shit hitting the fan is that the longer you wait the
> more there is to spread around :(

It was all very nicely concentrated in one place. It could have been
dealt with in one place, where a bunch of people very aware of the
bulk of the picture could try to find a good solution to a sticky
problem.

Instead of cleaning up all the shit while it sat in a concentrated
place, it got flung out in all directions, increasing the burden on
everyone who's actively involved in the bleeding edge areas of system
usage and software development.

This is going to slow down use and development of anything that
depends on those bleeding edges, which is where interesting and new
things happen. This will definitely be killing off things which held
promise.

-- 
:wq