Interesting article on boot ordering

[Bryan W. Headley]

Enrico Scholz wrote:
> hp at redhat.com (Havoc Pennington) writes:
> 
> 
>>>>Some UI goals to keep in mind for reworking bootup include:
>>>
>>>For me, UI goals are nearly uninteresting. 
>>
>>If we're going to spend a lot of effort reworking the initscripts setup
>>it should solve the UI stuff as well, or we might have to rework again
>>in the future to meet the overall project goals.
> 
> 
> The main problem is to determine the 100% marker. Else:
> 
> * use framebuffer,
> * start very early a small program which
>   - takes progress-info (service-name, started or finished) on stdin
>   - displays a nice background-image
>   - shows the boot-stage information (services between start and finished
>     stage)
>   - shuts down when it gets the command in stdin (e.g. in X/gdm startup)
> * minit feeds this stdin with info about the current process/service
> 
> This does not exist in minit yet (and the author (Felix von Leitner)
> will probably never implement it), but it fits into the minit-concept.

This is sort of like what SuSE did with bootsplash. But they need to 
know how many sysvinit things you are going to run to be able to move 
the scrollbar.

It looks like what rhgb is doing is starting a minimal X server. Not 
good because of the time constraints of starting it; hell, you might do 
a better overall job in text mode, put up fake shadows, etc. and maybe 
that's the way to go.

Re: speed/quality of sysvinit versus minit or runit. The tradeoffs 
you're getting is that minit "knows" one of it's spawned services have 
stopped, and can react to that. sysvinit really doesn't know about errors...

I don't know what the speedup is with starting services in parallel with 
each other. Obviously you cannot start service x if it relies on service 
y being active, so there are wait constraints. Secondly, you're causing 
some thrashing by starting several services at once.

There's going to be some win, but how much is a good question...


____               .:.                 ____
Bryan W. Headley - bwheadley at earthlink.net