[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Faster login



On Mon, 2004-11-15 at 00:01 -0500, Bill Nottingham wrote:
> David Zeuthen (davidz redhat com) said: 
> >  - With this hack we shave twenty secs of the booting time (e.g. from
> >    GRUB until you can use your PC) but booting still feels much quicker
> >    because of the interaction with gdm in the middle (YMMV; e.g. placebo
> >    effect etc.)
> 
> I'm guessing most of this is the lag in starting up RHGB and then
> killing it to start a second X server. But ICBW.
> 

Dunno; hopefully someone will do the boot time poster framework that Own
proposed on fedora-devel. Until then, I'm not sure we have enough hard
data to tell.

> >  - we don't get the kudzu screen nor the fsck screens or any other
> >    console interactions. However, IMHO, such screens are not good UI
> >    in the first place - we should instead have GUI replacemnts that
> >    possibly notifies you when you log into the desktop session (stuff
> >    like NetworkManager and HAL alleviates such problems for networking
> >    and storage devices)
> 
> An error after you've logged in telling you 'oh, btw, your FS has errors
> and is screwed'?
> 
> I'm assuming this is not what you mean.
> 
> The kudzu stuff should be fixed (in general, everything should
> just be configured w/o dialogs; anything that can't be configured
> can wait), but filesystem errors need to take precedence over
> getting you logged in quickly.
> 

Yes.

> Of course, in your example, you're not starting anything until
> after fsck has long since finished. Which is probably the route
> to go.
> 

I think so, it's pretty fast in the laptop case anyway; couple of
seconds.

> >  - we don't get service startup notification, but, uhmm, is it really
> >    useful learning that the "Console Mouse Service" or "Printing Sub-
> >    system" have started? Instead, this stuff could just be put in gdm
> 
> It should mainly just be logged. /etc/rc can either throw crap on dbus,
> or you could just read the syslogs.
> 
> If you're *really* bored, you can pop up the old-school MacOS icons
> for each service. 

Heh :-)

> But the rhgb-style 'randomly increment the progress
> bar at predefined services X, Y, and Z has got to go.'
> 
> >  si::sysinit:/newinit.sh
> > 
> > and you should be set to go! If it breaks you get to keep both pieces;
> > e.g. try this at your own risk [1].
> 
> xinetd? Whatever for?
> 

Checking that someone read the changes? :-) - no, seriously, a moment of
weakness from my side; I don't know why I put that in, sorry.

> Looking at integrating this stuff in a maintainable manner, the
> following needs done:
> 
> a) move a chunk of this crap to the root fs
>    - or -
>    make sure any networked /usr is mounted

Well, I suppose that starting gdm early is only really useful for
laptops. If you have a networked /usr the odds are that this is a
desktop box that is always on, so why not just postponing launching the
stuff from /usr you need? 

(perhaps a reworked init system could have the dependency '/usr is
mounted').

> b) start making 'fundamental' services non-optional (things like syslog,
>    dbus, etc.)

Right. 

> c) take out xfs and shoot it. The X server should be fixed so that it
>    can handle startup without it, and any old-school fonts will only
>    be available once xfs starts up at some point later.
> 

Indeed.

Cheers,
David



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]