[gentoo-dev] Re: Re: eselect init

[Steven J. Long]

On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote:
> On 06/01/2013 11:23 AM, Steven J. Long wrote:
> > That's not an argument for using a symlink switcher or the
> > equivalent across the board, by any means.
>
> Your opinion.

That's not an argument for it either.
 
> > Firstly, we should be recommending people install Gentoo with enough
> > flexibility to configure and use their system how they choose. In the
> > UEFI arena, why not simply recommend something like rEFIt instead of
> > making everyone go through a load of development effort, to restrict
> > us all to a crippled use-case?
>
> Beside rEFIt being deprecated and rEFInd being in early stage of
> development (thus working great on some platforms and not working at all
> on some other) and with a good chunk of documentation to read before
> being able of deploying it?

The typical thing Gentoo users get told is "this is a new thing, it will
take some time to work out, bear with us" as their production servers go
tits-up around them. So in this case too, work with upstream to implement
better solutions you, and the wider ecosystem, can all use.

And in the meantime:
 
> > NOTE: If you still wish to pursue a fixed config, then it's easy
> > enough to build it with init=/sbin/einit since presumably you want
> > that setup for your users.
>
> Had been considered

And STILL the best interim solution till your EFI setup has a bootloader.

"Your opinion" of rejection is just that: your opinion.

You're free to work on whatever you want. You just haven't made any
case for why the rest of the ecosystem should be crippled to allow for a
use-case that would be better served by an existing, far more robust
solution.

> > All I'm saying is: can we please stop trying to reinvent the kernel,
> > which accepts a bootloader parameter from initramfs as well, and
> > focus instead on the difficult part: making sure the system is in a
> > fit state to switch in the first place.
>
> ...
>
> > That's where the development effort is needed, if you are to provide
> > a mechanism to switch. The symlink and hooks etc is a total dead-end,
> > imo. It's simply reinventing the wheel using octagons instead of
> > circles.
>
> IMHO you hadn't read enough about it.

Believe me I've read lots. And you _still_ are not presenting any arguments.

There are 6 options to hook in an init, and to fallback in case of error,
already.
 
> > There's nothing to stop systemd being the default init, should you
> > want to put the install together like that. Because let's be honest:
> > someone has to put this install together, irrespective of how
> > incapable the end-user is of editing a file by themselves. And just
> > because the user can do it simply, that's no reason to make our
> > method to do it any more complex (I've never heard such a bizarre
> > argument.) Just edit the file via script.
>
> I do not care about systemd.

Then it can be runit or whatever else takes your fancy. You are ignoring
the point of that paragraph though: someone has to put the install together.

Or it isn't a Gentoo install.

So given that you're putting it together, or it's an automated script
to do the same, you can hook in an init wrapper or alternative wherever you
want, without needing anything from anyone else.

> > FOCUS on getting the system safe to switch. Not on reinventing
> > init/main.c, badly.
>
> You should read the whole thread before commenting like this that late.

I have actually. I responded to WilliamH a while back, CC'ed to him since he
prefers that, but the mail didn't get through to the list. It was marked
TLDNR so no doubt it hit a filter somewhere, and I didn't see the point in
reiterating it.

I've seen two weeks of discussion about how to reimplement init/main.c
with "ooh it needs to be early in init" and "what about fallbacks", interleaved
with less and less discussion of the actual problem: making sure the system is
safe to switch in the first place; sine qua non.

Wrt to the first, funnily enough the kernel developers have been here before,
just like they had with ethN and wlanN. It's a basic requirement for developing
an OS that you be able to switch init and fallback to other options.

You should consider the points made, and whether you really need to implement
this part of the setup at all. Your premise is still flawed, however long
you've been discussing the implications of working round it. Stuff happens.

Honestly, my goal is a saving of time so people can focus on making the
eselect module work properly, and be of real value to an end-user who wants
to switch init.

The whole symlink/boot/fallback thing is simply a waste of technical effort.
And blanket "your opinion" and "you didn't comment a week ago, so I don't
have to deal with the substance of your points" don't change that.

Please, make a better case next time.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)