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?

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.