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

Comments

awesome

[Anonymous Coward]

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

Not very cool

[stjobe]

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

Re:Not very cool

[kenthorvath]

Why don't we try to make the system really boot faster instead?

Three points:

First, the people who are doing this don't necessarily have the technical knowledge to make the system boot faster. Everyone has their specialties and interests. This is what would make them happy and they in turn are interested in sharing it with you. Don't like it? Don't use it. Why are you posting on slashdot when you could be making the system boot faster? See how that works? It doesn't sound like such a good argument now, does it?

Second, users take time to enter in information like logins and passwords. While they are doing this, the system can be processing other stuff and making the system come up. When the user and the system are working in parallel, things actually do get done faster.

Lastly, there is the fairness principle. It doesn't really matter which half of the candy bar is 'bigger' when sharing it so long as one person breaks and the other chooses. Each person feels that they haven't been ripped off without regard to actual physical realities. To this end, if the system feels faster, then why should I complain? It is the user experience that is being made to improve. What else really matters?

Is this progress?

[rthall]

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.

Three words:

[roystgnr]

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.

improve overall startup performance using 'make'

[dan_bethe]

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.

Fooling the user the right way

[Santos L. Helper]

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.

Re:Boot times...

[NonSequor]

You're being ridiculous. If something makes the user's experience less frustrating with no cost then how is it a bad thing? I recall an article some time ago where someone put together a proof of concept init system using make that showed that starting services concurrently can speed up boot time. The fact is, this is unlikely to increase the time that it takes to load all of the services and they may be able to reduce it.

I really can't see anything wrong with this.

Re:Hmmm...

[tchuladdiass]

Not to mention people with laptops.