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.
One of the complaints I hear from Windows people is how long it takes to actually start working once the login has taken place. I know my WinblowsXP partition on my company laptop takes friggin' forever to get going because of all the crap that Winblows starts at boot time. Red Hat has gotten worse and worse as they release newer distros. Hello...Red Hat...are you in there? Screw it...I'm going back to my Debian box.
I'm not a troll, but I play one on Slashdot.
Making GDM load sooner will definitely make the system seem to "boot" faster. However, if once GDM is up, and it takes 15 seconds before you can begin to login while the other services start, then what at once "seemed" faster, is now slow.
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
Just so long as they hold to this one principle:
If you show me a login prompt, you'd damn well better be ready for me to log in.
I don't like the statement "We can allow the user to input their name and password, so long as we don't process it until the system is stable."
BZZZT! WRONG ANSWER!
I don't mind bringing up X, and showing the boot process info, but do NOT give me a prompt for my username until you are ready for me to log in.
Personally, I think the whole way init works needs to be revisted - it would be better if you could start all the init processes at once, with each having its standard input, output, and error going into init. If startup script FOO requires service BAR to be active before it proceeds, then BAR ought to provide a means for FOO to check if BAR is ready (and block if not).
init would then display the different output streams "as needed" (if an init script runs to a successful completion then who cares to see the output - ideally only if anything appears on stderr would init show the messages from a script), and would allow the administrator to interact with a failing init script as needed.
www.eFax.com are spammers
By launching them concurrently (subject to dependency constraints) the startup time can be shortened to a small fraction of the current time needed.
There are articles on how to do this and not get bitten by the dependency issues: http://www.google.com/linux?num=100&hl=en&lr=lang_ en&safe=off&q=parallel+boot+processes&lr=lang_en
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.
when was the last time I booted this system???
some 20 days ago...
20:33:27 up 20 days, 23:41, 2 users, load average: 0.31, 0.35, 0.29
when was the last time I botted my other system???
20:34:40 up 293 days, 7:25, 7 users, load average: 0.25, 0.17, 0.10
why the F would I ever need an early logon to GDM???
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
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.
The wife's and daughters' MS-Windows boxes go through regular b0rk-and-reboot cycles, so boot time means something to them - but not to me.
I wonder how many people with DSL households shut down their machines between uses?
(My machines aren't entirely idle while we're gone. There's a web and mail server, a firewall, and some folding-at-home, so we're not burning electricity just for the hell of it.)
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.
Sun has already taken this track on Solaris 10 with their Service Management Facility. See SUN's quick summary of SMF
I am still getting used to SMF, and luckily they also keep backwards compatability with the rc.d init scripts.
Provided SMF isn't under 100 patents, maybe LINUX can pickup a few of Sun's good ideas once OpenSolaris comes out later this year.
I don't want to bash RedHat on it, but I already have it: Ubuntu Hoary starts GDM before some stuff (I could see the startup of ACPId after the "starting GDM" message and before the GDM really appeared).
One point to them is that they were the first trying such things, IIRC.
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?
It depends what you mean by "boot". Ubuntu has had a very similar thing for a long time, and I find the computer perfectly responsive, if a little slower than usual while things finish loading in the background.
:)
I've actually gone even more extreme on my computer, by starting apache, sendmail, my ftp and ssh servers 10, 15, 20 and 25 seconds after I've finished logging in. By that time all of the various background services have started, and loading them at that point is not noticable at all.
Of course, my mac is able to get from turning on to a working desktop in about 9 seconds, nothing else even comes close
Combination - fun iPhone puzzling
A five second boot-up time will make things a LOT faster for real, not just "apparently".
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
This is one of the features I detest in Windows XP. The login screen appears early but the desktop crawls and splutters while loading, due to all the background activity as services start. The taskbar noticeably renders itself; green bar first, then the outline of some buttons, then the systray slowly loads a few icons. Argh. Click on the Start button and the gigantic Start Menu appears, but it randomly DISAPPEARS before I get the chance to pick a program. Even worse is when you're 3 levels deep in the Programs menu and it decides to throw the Start Menu away for some unknown reason. The mere act of starting Outlook has a 10-20 second pause before the interface slowly renders.
I've clocked the machine and it takes 5-6 minutes after logging in with my smartcard before the machine stops paging. This isn't a slouch of a machine either. It's a P3-700 with 512MB RAM.
Recently I noticed that Ubuntu (I run a hybrid of Debian and Ubuntu) has been loading gdm early in the boot sequence. It's similarly painful. I've got autologin turned on and I can now see Gnome Terminal and the Panel rendering while my desktop loads. It used to be *BANG* there it was. If it pisses me off enough I'll change the priority for the init script. In my opinion, it's a regression from the way things used to be.
Solaris 10 already solved problems like this with SMF:
e v_ intro.html
:)
http://www.sun.com/bigadmin/content/selfheal/sd
I can login to my JDS 3 Desktop and have everything up *much* faster than I ever can with RedHat Enterprise Linux 3.0 WS (which I also have installed).
Nice to see RedHat catching up finally
Gentoo's init system uses dependencies already. They already have a flag for parellization. It doesn't seem to actually parellize anything, but it would seem that they are working on it.
Me, I improve my boot time by using suspend2 instead of shutting down. If I limit the amount of stuff copied to disk, I can avoid thrashing on boot but still have a wicked quick startup, especially with the lzo compression.
Don't thank God, thank a doctor!
Check out the Gentoo init script dependencies. And they are working on parellizing. I'm not sure if it's done yet, though.
/etc/init.d/sshd start
For instance, to add sshd to the default runlevel, I just do:
rc-update add sshd default
The scripts will most likely place it towards the end, but they make sure it goes after networking, because sshd obviously depends on networking. Should the network fail to come up, sshd won't be attempted.
Also, if I want to start sshd manually:
will automatically start networking if needed.
Don't thank God, thank a doctor!
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"
Personally, I use GDM to make it easier for my girlfriend to log onto my computer and use X (plus man, its always nice to turn on your computer and see a sweet looking picture of a Portugal Beach warming your screen).
remember playing the quake3 demo on a couple of p3 500z me and a friend borrowed from work for the weekend.
heh
seriously the init script system is just one of the many killer features. redhats choice to stay with the sysV idea reeks of micro$oftie corporate legacy issues from windos