Slashdot Mirror
Red Hat Developing Early Login with gdm
hey writes "Red Hat has been working on
early login because, among other reasons, 'If we start GDM sooner, the system will "feel" faster because the user
will see a login screen sooner.' Very cool."
← Back to Stories (view on slashdot.org)
... before it becomes a Microsoft 'feature'.
I tell yah, if there's one thing I love more than making my software, simpler, faster, and more effective, it's making it *appear* to be simpler, faster, and more effective. ;-)
'If we start GDM sooner, the system will "feel" faster because the user will see a login screen sooner.'
Yeah, let's all take a page out of the Windows book and fool our users... bleh.
Why don't we try to make the system really boot faster instead?
"Total destruction the only solution" - Bob Marley
Does it matter that the system will feel slow as a dog as services are lauching concurrent with your login? On the popular non-open-source server platfom, I quite frequently let it sit at the login prompt for five minutes. Then the login feels fast.
Randy Hall
Maybe if RedHat didn't start so much extraneous crap at startup, they wouldn't need to screw around with this. How about actually working on improving the boot time, and not relying on Microsoft-like tricks to fool the user?
This space intentionally left blank.
Wait... are you talking about graphical login? Just boot don't load X on default, that will *seem* a lot faster.
I do it out of habit. But if you want to make it into a "go faster" feature, then pretend away!
http://monkeyserver.com --- weeeeee
make, make, make
Starting up a Linux system requires satisfying some dependencies. You don't want to try mounting nfs disks until after bringing up the network. You don't want to start the X server until after the X font server is running.
But why, exactly, must gpm not start until sendmail is finished? Just because some Red Hat employee decided that sendmail should be numbered 80 and gpm numbered 85? It's not his fault, anyway, since starting them the other way around would be just as bad.
The underlying speed problem isn't what order Linux services are started in, it's the fact that they're only allowed to start one at a time. There's a reason why you're recommended to compile with "make -j 2" even on uniprocessor machines: even when an individual program is running as fast as it can, odds are it's I/O bound often enough that the CPU can profitably do something else at the same time. Even multiple programs waiting for the hard drive can start faster if they're started simultaneously: the drive controller can pick up whichever data is closest to the read head first, instead of being forced to data in some arbitrarily chosen order.
I know I'm not the first person to realize this; although I can't find a web page at the moment I recall reading about someone doing this long ago. What I don't recall reading is any reason not to make your distribution start up this way. Backwards compatibility could be easily satisfied by adding phony dependencies for S01 through S99 (which in turn would depend on all the services which were listed earlier). Bloat is a concern, but even GNU make is a fraction of the size of the initscripts package on my system. If you start background and interactive services concurrently you have to worry about responsiveness, but that's what the "nice" command is for.
An IBM researcher has a sample implementation of a dependency system for standard SysV init scripts. It uses 'make' to provides deps instead of the crude, standard ordering system. Search the article for the word "dependencies" and start reading there toward the bottom if you already know how SysV init works.
It's not always a bad thing to fool the user if you can get away with it. Jef Raskin's Canon Cat system did exactly that. On starting up it would show the user a bitmap of what the user was last working on while it loaded up the actual data in the background. Then when it's ready, it would replace the bitmap with the actual display. The thing that Raskin figured out to make it work was that it took users a couple of seconds to reorient themselves and recall what they were doing, so they would just sit and stare at the screen for a bit. And the Cat can *always* load up the real data and be ready for input before the users themselves were "booted up."
But from TFA, it doesn't sound like the redhat guys are going to do it the right way, which means the users will figure out they've been fooled and you've just gone through all that trouble to piss them off.
Sys V init scripts are just archaic and are showing their age and preventing more sophisticated forms of startup. Why doesn't RedHat investigate replacing Sys V init with a new, dependency-based, parallelizable startup system like Mac OS initialization system or Seth Nickell's proposed "SystemServices" init system:
http://www.osnews.com/story.php?news_id=4711
http://www.gnome.org/~seth/blog/2003/Sep
This could easily be backwards compatible such that there are services defined which are simply one-to-one mappings to scripts. Once it's dependency based, you don't have to worry about assigning hardcoded priorities manually and then writing dock gadgets that tell the user when the services are done "starting". As a user I couldn't care less that the services are done starting. Programmers have a futuristic technology called semaphores that can be used to block until a required dependency is fulfilled. If you want to print, and the print spooler hasn't started, instead of blowing chunks, you just implicitly start it. Magic! Ideally, ALL services would be lazy by default unless specifically told by the user to start up automatically (i.e. ssh server, web server, etc.)
It's 10 PM. Do you know if you're un-American?
If you read the thread on redhat, you will find out that the early-start gdm can shorten the boot process by a dozen seconds. It is not just feel.
this post contain no useful information, no need to mod it down
Not to mention people with laptops.
Kudzu, which does hardware detection, is one of the worst offenders. Removing it shaves almost ten seconds off of boot time for me, on a 1Ghz box.
Kudzu is also, however, integral to RedHat's "Stateless Linux" system, which reduces maintenance and increases security by booting from centralized disk images. This process is aided by Kudzu's "on-the-fly" hardware detection.
So it's a tradeoff that RedHat seems willing to make: ease of hardware support for slightly longer boot times. I'm willing to bet many large corporate customers are willing to make the same tradeoff, so long boot times must be "worked around" instead of eliminated.
"I assumed blithely that there were no elves out there in the darkness"
I would. I last booted 25 minutes ago. Power usage and fire risk are concerns for me.