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

Re: Faster login



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.

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

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

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

Bill


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