On Mon, 2004-11-15 at 00:01 -0500, Bill Nottingham wrote:
David Zeuthen (davidz(a)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
> 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
I think so, it's pretty fast in the laptop case anyway; couple of
> - we don't get service startup notification, but, uhmm, is
> useful learning that the "Console Mouse Service" or "Printing
> 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.'
> and you should be set to go! If it breaks you get to keep both pieces;
> e.g. try this at your own risk .
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
c) take out xfs and shoot it. The X server should be fixed so that
can handle startup without it, and any old-school fonts will only
be available once xfs starts up at some point later.