Faster login

David Zeuthen davidz at
Mon Nov 15 15:48:43 UTC 2004

On Mon, 2004-11-15 at 00:01 -0500, Bill Nottingham wrote:
> David Zeuthen (davidz at 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.


> 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

> >  - 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:/
> > 
> > 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

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


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



More information about the desktop mailing list