FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 03-29-2012, 02:21 PM
Michael Mol
 
Default InitRAMFS - boot expert sought

On Thu, Mar 29, 2012 at 5:02 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 28 Mar 2012 22:21:11 -0400, Michael Mol wrote:
>
>> There is so much BS being spewed around this topic, I'm genuinely
>> disgusted. It's enough to lead me to suspect that Linux, as a
>> platform, is *dying*.
>
> It's not dying, it's evolving - with the associated growing pains. Of
> course, that's not to say it couldn't evolve the way of the dodo.

The problem is the lack of engineering sense.

>
>> The "true UNIX way" is about KISS philosophy. Keep it Simple, Stupid.
>> Keep things small, well-defined and modular. Break things into
>> components, keep the components small and relatively well-defined.
>
> 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. These days, you put things on different mount
points because you want different underlying characteristics either in
the filesystem or its underlying block device.

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. If I was comfortable
with *any* other platform as much as I've been with Gentoo these past
couple years, I'd be jumping ship immediately.

>
> It makes me think of Ubuntu's insistence on fitting their installer on a
> single CD, even if it means omitting useful software or having the
> installer sneakily download components in the background.

--
:wq
 
Old 03-29-2012, 02:43 PM
Neil Bothwick
 
Default InitRAMFS - boot expert sought

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. 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.

> 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.

> 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. If the separate /usr had been
allowed to die when 20MB hard disks were around, this whole situation
would never have arisen.

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


--
Neil Bothwick

Oxymoron: Clearly Misunderstood.
 
Old 03-29-2012, 03:58 PM
Michael Mol
 
Default InitRAMFS - boot expert sought

On Thu, Mar 29, 2012 at 10:43 AM, Neil Bothwick <neil@digimed.co.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
 
Old 03-29-2012, 04:47 PM
David W Noon
 
Default InitRAMFS - boot expert sought

On Thu, 29 Mar 2012 10:08:40 -0400, Doug Hunley wrote about Re:
[gentoo-user] InitRAMFS - boot expert sought:

> On Wed, Mar 28, 2012 at 19:20, David W Noon <dwnoon@ntlworld.com>
> wrote:
[snip]
> > The Gentoo developers have been discussing just that. *The reason is
> > that many of the daemons that can be started by udev scripts require
> > work files on /var, so we could well need /var mounted too.
>
> But wait, that's what having /var/run being a link to /run was all
> about. This problem is supposed to be *solved* already, damnit

That's okay for PID files, but udev scripts are supposed to be allowed
to run *anything*.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 
Old 03-29-2012, 05:14 PM
pk
 
Default InitRAMFS - boot expert sought

On 2012-03-29 01:20, Neil Bothwick wrote:

> I'm in favour of /bin and /lib, and I see the pros and cons of
> /sbin and am not too bothered about how that is done. But having
> two (or more) of each of these is an artificial mess that is a
> solution to a problem that

As I said, it's a matter of taste.

> Red Hat employ devs working on many aspects of Linux, and we
> should be grateful for this (or do you prefer the Ubuntu approach
> of taking with little giving back?). One of the reasons Greg K-H
> left SUSE to work for

I did say that my writing was speculative? And I never claimed Greg
K-H is/was working for Redhat. Anyway, for the record I have always
had a great respect and admiration for both Redhat and Greg K-H (which
I see as a very good and knowledgeable kernel hacker) but this latest
debacle has taken it down a few notches... On the other hand I would
prefer Ubuntus approach to someone (anyone) pushing bad designs any
day ("speaking" hypothetically and generally without pointing out
anyone or any company). But this is quite pointless (my whining)
since, as someone else mentioned, "code talks...". Perhaps some day I
can find the time to hack my own solution (which of course will be
perfection ;-) ).

:-)

Best regards

Peter K
 
Old 03-29-2012, 05:36 PM
Dale
 
Default InitRAMFS - boot expert sought

J. Roeleveld wrote:
>
> On Wed, March 28, 2012 12:49 am, Mark Knecht wrote:
>
> <snipped>
>
>> Do nothing. Just read, watch, learn but most important don't do
>> updates. Just wait. Patience is a virtue!
>
> I wonder how many threads we'll get with "I haven't updated my Gentoo for
> over a year, how do I best do the upgrade?" from people following this
> advice?
>
> --
> Joost
>
>
>


I was thinking about that. My system works right now. I could just not
update for a good long while before doing any updates. Maybe the udev
dev will do like the hal guy, admit he screwed up and fix it so that it
runs as it should and leave it like it used to be.

Also, it is getting warm here. I don't need the extra heat from
compiling anyway. ;-)

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
 
Old 03-29-2012, 06:06 PM
Neil Bothwick
 
Default InitRAMFS - boot expert sought

On Thu, 29 Mar 2012 19:14:31 +0200, pk wrote:

> But this is quite pointless (my whining)
> since, as someone else mentioned, "code talks...". Perhaps some day I
> can find the time to hack my own solution (which of course will be
> perfection ;-) ).

I wait with bated breath. Even if less than perfect, it will be better
than mine


--
Neil Bothwick

Found my .sig, it was in behind the cushion on the settee.
 
Old 03-29-2012, 06:54 PM
pk
 
Default InitRAMFS - boot expert sought

On 2012-03-29 20:06, Neil Bothwick wrote:

> I wait with bated breath. Even if less than perfect, it will be
> better than mine

I'll be sure to let you know if I find "perfection"... Perhaps an AI
system that takes care of it self and serves me drinks (with or
without an umbrella) while I lay on my couch doing whatever I see fit
(since the bots controlled by the AI have taken over the boring chores
I have all this free time)? On the other hand such a solution would
most likely malfunction and hit me on the head with the shaker, pour
it's contents all over me and chase me around with something sharp... ;-)

Best regards

Peter K
 
Old 03-29-2012, 08:55 PM
Alan McKinnon
 
Default InitRAMFS - boot expert sought

On Thu, 29 Mar 2012 14:05:30 +0200
Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

> The 29/03/12, Alan McKinnon wrote:
> > On Thu, 29 Mar 2012 00:20:04 +0100
> > David W Noon <dwnoon@ntlworld.com> wrote:
>
> > > The Gentoo developers have been discussing just that. The reason
> > > is that many of the daemons that can be started by udev scripts
> > > require work files on /var, so we could well need /var mounted
> > > too.
> >
> > Which begs the obvious question,
> >
> > Why on earth is udev launching daemons in EARLY BOOT?
>
> udev launches nothing. udev scripts do. These scripts are not part of
> udev.
>

OK, semantics. Let me re-phrase:

Why is a third party script, running in the context of the udev
universe, indiscriminately allowed to launch daemons at early boot
time?

I don't think I agree with Neil in that this is a udev design flaw (as
any "fix" will be worse than the "flaw"). Instead it looks to me like
a classic case of

"You are free to do anything you want but if you break it you keep the
pieces. If you do something stupid, it's not my problem and you're on
your own."

I see nothing wrong with udev applying some reasonable constraints such
as clearly documenting at what point in the boot process udev is in a
position to arbitrarily run anything. Earlier than that point,
"anything" does not actually apply.


--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-29-2012, 08:58 PM
Alan McKinnon
 
Default InitRAMFS - boot expert sought

On Thu, 29 Mar 2012 13:01:49 +0100
David W Noon <dwnoon@ntlworld.com> wrote:

> On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
>
> > On Thu, 29 Mar 2012 00:20:04 +0100
> > David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
> > > The Gentoo developers have been discussing just that. The reason
> > > is that many of the daemons that can be started by udev scripts
> > > require work files on /var, so we could well need /var mounted
> > > too.
> >
> > Which begs the obvious question,
> >
> > Why on earth is udev launching daemons in EARLY BOOT?
>
> Your guess is as good as mine!
>
> At present, the first thing I see when udev starts is a failed attempt
> to run /usr/sbin/alsactl to restore the audio levels on my sound card.
> This occurs before localmount or any other services in the sysinit
> run-level have been started. Just why anybody wants sound before the
> disk volumes have been mounted baffles me; I guess people are just
> desperate for the comforts of stereo.

Perhaps the ability to hear the computer go "bing" when volumes
mount is a killer marketing feature....

Reminds me of Sigourney Weaver's character in Galaxy Quest - she was
the bimbo who announced to the room whenever the computer went bing


> Perhaps my mind simply lacks
> the sophistication to understand the design of udev.
>
> I guess I'll just stick to my 80-column Hollerith cards. ... :-)



--
Alan McKinnnon
alan.mckinnon@gmail.com
 

Thread Tools




All times are GMT. The time now is 09:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org