Hi,
So I had a brief look at shortening startup/login time and tried disabling rhgb in favor of starting gdm early. It looks pretty promising; here are some wall-clock numbers from two runs of each configuration:
| gdm_early | rhgb+gdm | ----------------------+------+-------+-------+------+ GRUB timeout | 0:00 | 0:00 | 0:00 | 0:00 | Starting udev | 0:13 | 0:13 | 0:13 | 0:14 | HW init done | 0:25 | 0:25 | 0:26 | 0:26 | rhgb visible | N/A | N/A | 0:36 | 0:35 | gdm login visible | 0:43 | 0:44 | 1:25 | 1:26 | gdm login entered | 0:52 | 0:52 | 1:31 | 1:32 | GNOME banner visible | 1:13 | 1:14 | 1:40 | 1:41 | Nautilus Background | 1:33 | 1:32 | 1:51 | 1:52 | Panel visible | 1:43 | 1:43 | 2:02 | 2:02 | HD activity off | 1:59 | 1:56 | 2:13 | 2:14 |
The milestones should be pretty self evident. This is on a stock FC3 system running on a IBM T41 1.6GHz (running on AC power), 512MB RAM without any services manually disabled.
In addition to starting gdm early, the modifications also start up a few services, D-BUS, HAL and NetworkManager, that is critical to the GNOME desktop.
Some random thoughts/observations:
- We get the gdm window 40 secs faster
- The 12 secs from "Starting udev" to "HW init done" can be mostly shaved away/run in parallel
- Kernel bootstrap time (13 secs) can probably be much shorter (that's what some kernel guys say anyway)
- 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.)
- rhgb+gdm spawns an X server each which is sort of stupid and unsafe (or so some Xorg guys tell me). This solution, per design, avoids doing that
- 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)
- 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 could be interesting to make /sbin/init own a D-BUS service that gdm and other stuff can query and interact with. Could also be fun to completely replace it with something a'la the SystemServices prototype that Seth did last year; links
http://www.osnews.com/story.php?news_id=4711 http://www.gnome.org/~seth/blog/2003/Sep/27
- Could be interesting to instrument the kernel with some pagefault counters etc. and attempt do more readahead on e.g. the GNOME libs (both Windows XP and Mac OS X does all that; I think we do too but I've been told it can be improved)
So, anyway, I think it could be interesting to discuss starting gdm instead of rhgb. If you want to try out my crude hack, grab the file here
http://people.redhat.com/davidz/newinit.sh
put it in on your system as /newinit.sh, chmod a+x it and change this line /etc/inittab
si::sysinit:/etc/rc.d/rc.sysinit
to these two lines
#si::sysinit:/etc/rc.d/rc.sysinit 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].
Cheers, David
[1] :if it doesn't work you can boot your kernel with init=/bin/sh, do a 'mount -n -o remount,rw /' and edit your /etc/inittab file to point to the original sysinit.
David Zeuthen wrote:
Hi,
So I had a brief look at shortening startup/login time and tried disabling rhgb in favor of starting gdm early. It looks pretty promising; here are some wall-clock numbers from two runs of each configuration:
| gdm_early | rhgb+gdm |----------------------+------+-------+-------+------+ GRUB timeout | 0:00 | 0:00 | 0:00 | 0:00 | Starting udev | 0:13 | 0:13 | 0:13 | 0:14 | HW init done | 0:25 | 0:25 | 0:26 | 0:26 | rhgb visible | N/A | N/A | 0:36 | 0:35 | gdm login visible | 0:43 | 0:44 | 1:25 | 1:26 | gdm login entered | 0:52 | 0:52 | 1:31 | 1:32 | GNOME banner visible | 1:13 | 1:14 | 1:40 | 1:41 | Nautilus Background | 1:33 | 1:32 | 1:51 | 1:52 | Panel visible | 1:43 | 1:43 | 2:02 | 2:02 | HD activity off | 1:59 | 1:56 | 2:13 | 2:14 |
The milestones should be pretty self evident. This is on a stock FC3 system running on a IBM T41 1.6GHz (running on AC power), 512MB RAM without any services manually disabled.
In addition to starting gdm early, the modifications also start up a few services, D-BUS, HAL and NetworkManager, that is critical to the GNOME desktop.
Some random thoughts/observations:
We get the gdm window 40 secs faster
The 12 secs from "Starting udev" to "HW init done" can be mostly shaved away/run in parallel
Kernel bootstrap time (13 secs) can probably be much shorter (that's what some kernel guys say anyway)
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.)
rhgb+gdm spawns an X server each which is sort of stupid and unsafe (or so some Xorg guys tell me). This solution, per design, avoids doing that
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)
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 could be interesting to make /sbin/init own a D-BUS service that gdm and other stuff can query and interact with. Could also be fun to completely replace it with something a'la the SystemServices prototype that Seth did last year; links
http://www.osnews.com/story.php?news_id=4711 http://www.gnome.org/~seth/blog/2003/Sep/27
Could be interesting to instrument the kernel with some pagefault counters etc. and attempt do more readahead on e.g. the GNOME libs (both Windows XP and Mac OS X does all that; I think we do too but I've been told it can be improved)
So, anyway, I think it could be interesting to discuss starting gdm instead of rhgb. If you want to try out my crude hack, grab the file here
http://people.redhat.com/davidz/newinit.sh
put it in on your system as /newinit.sh, chmod a+x it and change this line /etc/inittab
si::sysinit:/etc/rc.d/rc.sysinit
to these two lines
#si::sysinit:/etc/rc.d/rc.sysinit 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].
Cheers, David
[1] :if it doesn't work you can boot your kernel with init=/bin/sh, do a 'mount -n -o remount,rw /' and edit your /etc/inittab file to point to the original sysinit.
You're ideas sound very promising, as I myself have a strong opinion as to how things should be, however I do not yet have the expertise to implement them myself, and other seem to think such too complicated. You're ideas however are a good step. I would just like to raise to issues.
1) I am all for removing outputs of kudzu, fsck and init.d, esp. this makes potential convertees somewhat scared to put it one way. However I would hope that just as Fedora provides a 'Details' option, a 'Show' option should be enabled to allow output from these things.
2) I am all for speeding up the system starup/login (although I have a 750 Mhz Intel and it really doesn't bother me at all), but would this optimization be a Gnome only perk? Or would this be equally or at least similiarly beneficial to kdm (KDE).
Thanks
On Sun, 2004-11-14 at 05:18 +0000, Arturo wrote:
- I am all for speeding up the system starup/login (although I have a
750 Mhz Intel and it really doesn't bother me at all), but would this optimization be a Gnome only perk? Or would this be equally or at least similiarly beneficial to kdm (KDE).
I see no reason this should be GNOME specific at all; right now my hack just starts gdm, that could easily well be kdm, xdm or whatever.
Cheers, David
great job. gdm shows really fast. but of course it takes a while for login.
lør, 13 11 2004 kl. 21:24 -0500, skrev David Zeuthen:
Hi,
So I had a brief look at shortening startup/login time and tried disabling rhgb in favor of starting gdm early. It looks pretty promising; here are some wall-clock numbers from two runs of each configuration:
| gdm_early | rhgb+gdm |----------------------+------+-------+-------+------+ GRUB timeout | 0:00 | 0:00 | 0:00 | 0:00 | Starting udev | 0:13 | 0:13 | 0:13 | 0:14 | HW init done | 0:25 | 0:25 | 0:26 | 0:26 | rhgb visible | N/A | N/A | 0:36 | 0:35 | gdm login visible | 0:43 | 0:44 | 1:25 | 1:26 | gdm login entered | 0:52 | 0:52 | 1:31 | 1:32 | GNOME banner visible | 1:13 | 1:14 | 1:40 | 1:41 | Nautilus Background | 1:33 | 1:32 | 1:51 | 1:52 | Panel visible | 1:43 | 1:43 | 2:02 | 2:02 | HD activity off | 1:59 | 1:56 | 2:13 | 2:14 |
The milestones should be pretty self evident. This is on a stock FC3 system running on a IBM T41 1.6GHz (running on AC power), 512MB RAM without any services manually disabled.
In addition to starting gdm early, the modifications also start up a few services, D-BUS, HAL and NetworkManager, that is critical to the GNOME desktop.
Some random thoughts/observations:
We get the gdm window 40 secs faster
The 12 secs from "Starting udev" to "HW init done" can be mostly shaved away/run in parallel
Kernel bootstrap time (13 secs) can probably be much shorter (that's what some kernel guys say anyway)
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.)
rhgb+gdm spawns an X server each which is sort of stupid and unsafe (or so some Xorg guys tell me). This solution, per design, avoids doing that
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)
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 could be interesting to make /sbin/init own a D-BUS service that gdm and other stuff can query and interact with. Could also be fun to completely replace it with something a'la the SystemServices prototype that Seth did last year; links
http://www.osnews.com/story.php?news_id=4711 http://www.gnome.org/~seth/blog/2003/Sep/27
Could be interesting to instrument the kernel with some pagefault counters etc. and attempt do more readahead on e.g. the GNOME libs (both Windows XP and Mac OS X does all that; I think we do too but I've been told it can be improved)
So, anyway, I think it could be interesting to discuss starting gdm instead of rhgb. If you want to try out my crude hack, grab the file here
http://people.redhat.com/davidz/newinit.sh
put it in on your system as /newinit.sh, chmod a+x it and change this line /etc/inittab
si::sysinit:/etc/rc.d/rc.sysinit
to these two lines
#si::sysinit:/etc/rc.d/rc.sysinit 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].
Cheers, David
[1] :if it doesn't work you can boot your kernel with init=/bin/sh, do a 'mount -n -o remount,rw /' and edit your /etc/inittab file to point to the original sysinit.
Hi,
So I had a brief look at shortening startup/login time and tried disabling rhgb in favor of starting gdm early. It looks pretty promising; here are some wall-clock numbers from two runs of each configuration
Is it possible to have a very simple boot screen, ala Windows XP and MacOSX? It should be animated so that people can see if the computer is frozen?
Basically it would be very good if as soon as you went into grub, about 2 seconds later you had a graphical boot screen.
Can this be done without using X? Is there some sort of really simple X server-style application that could do this?
On Sun, 2004-11-14 at 13:28 +0000, Martin Alderson wrote:
Is it possible to have a very simple boot screen, ala Windows XP and MacOSX? It should be animated so that people can see if the computer is frozen?
Basically it would be very good if as soon as you went into grub, about 2 seconds later you had a graphical boot screen.
I personally think this would be nice, yeah.
Can this be done without using X? Is there some sort of really simple X server-style application that could do this?
I think there are kernel patches out there for doing this (though the framebuffer device) although I'm not sure if they are upstream nor what state they are in; I suppose the kernel dudes would know.
Cheers, David
On Sun, 2004-11-14 at 11:28 -0500, David Zeuthen wrote:
Can this be done without using X? Is there some sort of really simple X server-style application that could do this?
I think there are kernel patches out there for doing this (though the framebuffer device) although I'm not sure if they are upstream nor what state they are in; I suppose the kernel dudes would know.
IIRC the reason we did rhgb with X is that the kernel guys couldn't come up with any other approach that they would accept (or at least any other that they would accept and that was feasible to implement)
But yeah, with these gdm results rhgb is looking like a bad idea to me; as soon as we can get up rhgb, we could get up gdm, and so we may as well jump straight to gdm and possibly extend gdm to display boot progress/errors.
It might still be useful to get a non-X graphical display up earlier, before gdm/rhgb can start, though. Depending on how quickly we can get gdm up after a couple solid rounds of hacking on the boot time problem.
Havoc
On Sun, 2004-11-14 at 19:58 -0500, Havoc Pennington wrote:
IIRC the reason we did rhgb with X is that the kernel guys couldn't come up with any other approach that they would accept (or at least any other that they would accept and that was feasible to implement)
But yeah, with these gdm results rhgb is looking like a bad idea to me; as soon as we can get up rhgb, we could get up gdm, and so we may as well jump straight to gdm and possibly extend gdm to display boot progress/errors.
It might still be useful to get a non-X graphical display up earlier, before gdm/rhgb can start, though. Depending on how quickly we can get gdm up after a couple solid rounds of hacking on the boot time problem.
I just had a look at http://www.bootsplash.org/ and it appears that these patches do a lot of configurable stuff insofar that one needs to store the configuration and graphical assets in the initrd. This, IMO, pretty much defeats the purpose since it takes time for the kernel to boot (slightly more than 10 secs right now). I'm not sure the assets can be built into the kernel instead of using the initrd.
Ideally, IMO, all we need is a screen with a solid background colour (say, the same colour as in the gdm default theme) along with a small logo (e.g. a Red Fedora) and perhaps the twirling animation from rhgb. I'm pretty sure we don't need any progress bar and textual messages as we want gdm to appear within 10-20 seconds anyway (cf. my initial mail it's 43 seconds with my hack and 85 without the hack).
So, in fact, if I boot my laptop with the kernel option vga=0x0317 (1024x768x24), then right after grub, I get the Tux log in the top along with scrolling kernel messages. Almost there..
So, I wonder how much work there is in taking a static background colour along with a centered logo, disable the messages from the kernel and make the animation.. animate. I also wonder if something like this could be accepted into the upstream kernel.
Obviously, said assets (Fedora logo, animations etc.) will need to be compiled into the kernel proper as we need them before the initrd but, hey, everything has a price (the tux logo is already in there, so..). We would probably also need to select a more safe resolution e.g. max 800x600x256 or something in order to not destroy any monitors out there.
Cheers, David
On Sun, 2004-11-14 at 21:05 -0500, David Zeuthen wrote:
Obviously, said assets (Fedora logo, animations etc.) will need to be compiled into the kernel proper as we need them before the initrd but, hey, everything has a price (the tux logo is already in there, so..). We would probably also need to select a more safe resolution e.g. max 800x600x256 or something in order to not destroy any monitors out there.
... and fix bugs which crop up when you're using a framebuffer and X at the same time. I'd love to say they don't exist, but I end up telling people to use 'linux nofb' to fix problems they encounter in the installer far too often :(
Jeremy
David Zeuthen (davidz@redhat.com) said:
So, in fact, if I boot my laptop with the kernel option vga=0x0317 (1024x768x24), then right after grub, I get the Tux log in the top along with scrolling kernel messages. Almost there..
The question here is...
a) do you want to use vga16fb/vesafb everywhere (not portable to all arches) b) do you want to change the boot model depending on how supported someone's particular card is for fb mode in the kernel?
Not sure how useful this is just for hiding some kernel spew. :)
Bill
On Mon, 2004-11-15 at 00:03 -0500, Bill Nottingham wrote:
David Zeuthen (davidz@redhat.com) said:
So, in fact, if I boot my laptop with the kernel option vga=0x0317 (1024x768x24), then right after grub, I get the Tux log in the top along with scrolling kernel messages. Almost there..
The question here is...
a) do you want to use vga16fb/vesafb everywhere (not portable to all arches)
Well, if it's there we might as well use it.
b) do you want to change the boot model depending on how supported someone's particular card is for fb mode in the kernel?
Not sure how useful this is just for hiding some kernel spew. :)
Ideally the time from grub to gdm should be < 10 secs anyway, so a blank screen without progress bars will do I guess. I guess Seth, Bryan or Diana can tell us why kernel spew is bad from a UI point of view. They might even tell us we need the progress bar anyway, dunno.
Btw, it is my understanding that fb, drm and X (they all touch the hardware ) might merge in the future (which could give us oops() on top of X as in e.g. Solaris IIRC). Possibly far away. I could be wrong though. Ideally, it would be good if we could just setup the monitor to do the target resolution whenever the kernel boots and X will just take over from there. I'm sure some of the X guys can enlighten us here.
Cheers, David
Martin Alderson wrote:
Hi,
So I had a brief look at shortening startup/login time and tried disabling rhgb in favor of starting gdm early. It looks pretty promising; here are some wall-clock numbers from two runs of each configuration
Is it possible to have a very simple boot screen, ala Windows XP and MacOSX? It should be animated so that people can see if the computer is frozen?
Basically it would be very good if as soon as you went into grub, about 2 seconds later you had a graphical boot screen.
Can this be done without using X? Is there some sort of really simple X server-style application that could do this?
This would be my own personal favourite way of approaching the problem. By popping up a low res (say 640x480ish) screen like XP does, and having a crappy 16 color image with a simple scroller, it is an improvement over raw text mode visually, and lets the computer boot up fast which trumps any gui eye candy effects in my opinion.
It depends ultimately on wether users are more interested in seeing their desktops *now*, or if they're more interested in seeing GUI eye candy I guess.
For the sake of argument, lets say we honed booting to the point where what is currently rhgb - took 1 second to display. What would be the point of the eye candy displayed for 1 second then? Nothing really useful IMHO. Any eye candy is at best - only useful if there is a long wait.
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
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
David Zeuthen (davidz@redhat.com) said:
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.
Well, it's an obvious time savings point that starting the X server once is faster than starting the X server, killing it, and starting it again. It's just a matter of how much... :)
Bill
On Mon, 15 Nov 2004 12:58:15 -0500, Bill Nottingham wrote:
Well, it's an obvious time savings point that starting the X server once is faster than starting the X server, killing it, and starting it again. It's just a matter of how much... :)
This is one of the things I always hated about rhgb the most (still used it though ;)
The nVidia binary drivers take ages to initialize, as in 5+ seconds on my system: doing this twice just felt incredibly wasteful and definitely slowed things down.
Of course, starting services I don't need/want like cups doesn't help either ...
On Mon, Nov 15, 2004 at 09:07:21PM +0000, Mike Hearn wrote:
On Mon, 15 Nov 2004 12:58:15 -0500, Bill Nottingham wrote:
Well, it's an obvious time savings point that starting the X server once is faster than starting the X server, killing it, and starting it again. It's just a matter of how much... :)
This is one of the things I always hated about rhgb the most (still used it though ;)
The nVidia binary drivers take ages to initialize, as in 5+ seconds on my system: doing this twice just felt incredibly wasteful and definitely slowed things down.
try using an /etc/rhgb/xorg.conf without the nVidia binary drivers, this may work and may be faster,
Daniel
On Mon, 15 Nov 2004, Mike Hearn wrote:
Of course, starting services I don't need/want like cups doesn't help either ...
Now that somebody brought up the issue, this is one of the most unattentioned parts of FC IMO. Fedora Core is easy enough to install that anybody with a small knowledge of Linux can simply handle it well, but something nobody thinks about after installation is to check the running services, mostly because many people assume that the right set of services are running. But after installing, I've got to go uncheck more than half of default services. For example the Japanese stuff (don't know about FC3, but were in older versions), portmap stuff, humm, can't remember right now, but there are lot's of services that I've never chosen at install time and are just there to slow down the boot process, while chances are I never use them at all.
I agree that if one selects PostgreSQL to be installed, bringing it up by default is the better choice, but not many other services. Guess all I'm asking for is some kind of WinXP-like "start here" or tips like "configure services you need by running system-config-services"... after installation. No, I'm almost sure I'm not asking for more steps in firstboot :-).
It turned out like too much random thoughts, Sorry, --behdad
man, 15.11.2004 kl. 22.22 skrev Behdad Esfahbod:
On Mon, 15 Nov 2004, Mike Hearn wrote:
Of course, starting services I don't need/want like cups doesn't help either ...
Now that somebody brought up the issue, this is one of the most unattentioned parts of FC IMO. Fedora Core is easy enough to install that anybody with a small knowledge of Linux can simply handle it well, but something nobody thinks about after installation is to check the running services, mostly because many people assume that the right set of services are running. But after installing, I've got to go uncheck more than half of default services. For example the Japanese stuff (don't know about FC3, but were in older versions), portmap stuff, humm, can't remember right now, but there are lot's of services that I've never chosen at install time and are just there to slow down the boot process, while chances are I never use them at all.
I agree that if one selects PostgreSQL to be installed, bringing it up by default is the better choice, but not many other services. Guess all I'm asking for is some kind of WinXP-like "start here" or tips like "configure services you need by running system-config-services"... after installation. No, I'm almost sure I'm not asking for more steps in firstboot :-).
It turned out like too much random thoughts, Sorry, --behdad
I *think* most people would be very, very angry if you killed their ability to print...
On Mon, 2004-11-15 at 22:40 +0100, Kyrre Ness Sjobak wrote:
I *think* most people would be very, very angry if you killed their ability to print...
Of course, we shouldn't need a cups daemon for client-only machines in many cases - we can just talk IPP to the print server directly from the apps. You only need the spooler for a physically attached printer.
Similar with email, apps can connect to the server instead of spooling locally first.
Havoc
On Mon, 2004-11-15 at 18:06 -0500, Havoc Pennington wrote:
On Mon, 2004-11-15 at 22:40 +0100, Kyrre Ness Sjobak wrote:
I *think* most people would be very, very angry if you killed their ability to print...
Of course, we shouldn't need a cups daemon for client-only machines in many cases
Well, right now the CUPS server is also used to pick up IPP broadcasts. It would be nice to have an IPP notification only daemon for security reasons too though.
On Mon, 2004-11-15 at 18:14, Colin Walters wrote:
On Mon, 2004-11-15 at 18:06 -0500, Havoc Pennington wrote:
On Mon, 2004-11-15 at 22:40 +0100, Kyrre Ness Sjobak wrote:
I *think* most people would be very, very angry if you killed their ability to print...
Of course, we shouldn't need a cups daemon for client-only machines in many cases
Well, right now the CUPS server is also used to pick up IPP broadcasts. It would be nice to have an IPP notification only daemon for security reasons too though.
Regardless whether we use cupsd or a lighter replacement daemon, there should be no need to keep the user from logging in until that service is there...
Matthias
tir, 16.11.2004 kl. 00.14 skrev Colin Walters:
On Mon, 2004-11-15 at 18:06 -0500, Havoc Pennington wrote:
On Mon, 2004-11-15 at 22:40 +0100, Kyrre Ness Sjobak wrote:
I *think* most people would be very, very angry if you killed their ability to print...
Of course, we shouldn't need a cups daemon for client-only machines in many cases
Well, right now the CUPS server is also used to pick up IPP broadcasts. It would be nice to have an IPP notification only daemon for security reasons too though.
When you mention security: Try this:
Hook a computer which shares a printer up to a network. Make sure the host is named "localhost".
Cups will now broadcast that "localhost" is sharing printer "Überprinter3"
Now log in at another machine, and try to *print* to that printer. Make sure you DO have root access to the machine - you will have to stop cups and clear out its spool catalog.
What happens is that cups don't do any sanity checks on the recieved broadcasts - if it recives a broadcast from "192.168.0.5" saying that "localhost" is sharing "überprinter 3" it just stores that - no sanity checks such as trying to look up the hostname and seeing that it does resolve corectly. So it sends the job to itself, which is recived, sent to itself und zu weiter...
Behdad Esfahbod wrote:
On Mon, 15 Nov 2004, Mike Hearn wrote:
Of course, starting services I don't need/want like cups doesn't help either ...
Now that somebody brought up the issue, this is one of the most unattentioned parts of FC IMO. Fedora Core is easy enough to install that anybody with a small knowledge of Linux can simply handle it well, but something nobody thinks about after installation is to check the running services, mostly because many people assume that the right set of services are running. But after installing, I've got to go uncheck more than half of default services. For example the Japanese stuff (don't know about FC3, but were in older versions), portmap stuff, humm, can't remember right now, but there are lot's of services that I've never chosen at install time and are just there to slow down the boot process, while chances are I never use them at all.
I agree that if one selects PostgreSQL to be installed, bringing it up by default is the better choice, but not many other services. Guess all I'm asking for is some kind of WinXP-like "start here" or tips like "configure services you need by running system-config-services"... after installation. No, I'm almost sure I'm not asking for more steps in firstboot :-).
It turned out like too much random thoughts, Sorry, --behdad
I believe this, and many other issues might be minimized by a more inovative installer. I have never used or seen a Mac, farless to have installed one. And I have not used all the distros out there, so forgive me if this has been implemented somewhere else.
If think setting up the installer, Anaconda if I'm not mistaken, as follows might help alot,
Selection of user level (computer skills) - Expert Fedora User - Full customization (pc setup type, partion setup, hardware, packages, etc) - Power User - Educated guesses to be made by Anaconda of setup, with ability to customize generated setup (in an itemized, non-linear way) - Novice/First-Time User - Anaconda generated/guesses an appropriate setup asking only for localized information, window manager would give a sort of "Welcome to Fedora walkthrough" - Use istall preferences from install media (usb, floppy, ftp, etc) - Anaconda reads a file (possibly an xml file) which defines all the information it needs with the option to make changed after loading.
Based on this information, Anaconda would then only isntall what is necessary. For example, a First Time user in America won't need an ftp server, japaneese fonts, ssh server, etc, installed by default. This would give the ability to better lock down fresh installations so that people new to Fedora don't have unnecessary stuff that they will never need loading, but enthusists could have as much cutting edge as they may need. Such information I'm sure could be used in many other ways.
Just an idea I've had for awhile, I'm sure many will consider this to be not worth the trouble. But consider the possibilities such would add to the user experience.
Peace Arthur
Hi,
Am Montag, 15. November 2004 21:07 schrieb Mike Hearn:
Of course, starting services I don't need/want like cups doesn't help either ...
Suggestion: Most people probably need cups, but not right from the start (usually you first edit a document etc.)
What I do: I disabled all services that are not essential for login. Then I have a batch script that starts the rest when the load goes down, i.e. after login. So acpid, crond, cups, mysql, httpd, privoxy, wine ... get started while I'm already working. (It's a laptop, so I need to boot/shutdown several times a day; I need mysql and httpd for some of my databases). This way I saved something like 40 seconds startup time.
It would be nice if there was a recognized/official way to start non-essential services after the login. It could be a simple modification of the existing links in /etc/rc5.d/, like: S85httpd starts http immediately L85httpd starts it later as a batch job. There should also information which services depend on each other, and which are needed for X.
Cheers Stephan
tir, 16.11.2004 kl. 13.59 skrev Stephan Matthiesen:
Hi,
Am Montag, 15. November 2004 21:07 schrieb Mike Hearn:
Of course, starting services I don't need/want like cups doesn't help either ...
Suggestion: Most people probably need cups, but not right from the start (usually you first edit a document etc.)
What I do: I disabled all services that are not essential for login. Then I have a batch script that starts the rest when the load goes down, i.e. after login. So acpid, crond, cups, mysql, httpd, privoxy, wine ... get started while I'm already working. (It's a laptop, so I need to boot/shutdown several times a day; I need mysql and httpd for some of my databases). This way I saved something like 40 seconds startup time.
It would be nice if there was a recognized/official way to start non-essential services after the login. It could be a simple modification of the existing links in /etc/rc5.d/, like: S85httpd starts http immediately L85httpd starts it later as a batch job. There should also information which services depend on each other, and which are needed for X.
Cheers Stephan
Well - as long as it is predictable, all is fine. But you want to make sure that HTTPD and acpid actually WILL start asap. (but not before.) Think a machine with little RAM and no DMA. its load might not fall rappidly enough for those services to start, and it would make a debugging nightmare.
On Mon, Nov 15, 2004 at 12:58:15PM -0500, Bill Nottingham wrote:
David Zeuthen (davidz@redhat.com) said:
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.
Well, it's an obvious time savings point that starting the X server once is faster than starting the X server, killing it, and starting it again. It's just a matter of how much... :)
then we need an x.org x11 able to start from a read-only filesystem :-)
Daniel
On Mon, 2004-11-15 at 00:01 -0500, Bill Nottingham wrote:
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.'
This actually has lots of merits. If we put icons up for each service we started, this could start during the GDM login (across the bottom, lets say) and if the user logs-in before we're done starting services, the icons could be preserved and continued during the session init screen (where there are icons going across the bottom of the GNOME/KDE login banners) and the only "wait" point would be until the session init is done.
That way you could have "needs attention" GUI items run/addressed first- thing.
Ken
desktop@lists.fedoraproject.org
-
Alex Thomsen Leth -
Arthur Pemberton -
Behdad Esfahbod -
Bill Nottingham -
Colin Walters -
Daniel Veillard -
David Zeuthen -
Havoc Pennington -
Jeremy Katz -
Ken Crandall -
Kyrre Ness Sjobak -
Martin Alderson -
Matthias Clasen -
Mike A. Harris -
Mike Hearn -
Stephan Matthiesen