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

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?

Re:Not very cool

[BovineSpirit]

I imagine that their market research has shown that users don't like to wait, and that they're not bothered by the way Windows tricks them. It would be good for my 500MHz K6 because I tend to switch it on, wait an age for the login screen, then wait again for X windows to start up. If they could move some of the initial startup(httpd, mysql etc) to after Gnome is running then that would only give me one wait.
Of course you are welcome to make whatever improvements you like, and we would all appreciate it if you shared them.

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.

Boot times...

[avalys]

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?

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.

And this is needed for what reason exactly?

[PenguinBoyDave]

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.

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.

Re:Hmmm...

[tchuladdiass]

Not to mention people with laptops.

Re:Hmmm...

[peterpi]

You wouldn't.

I would. I last booted 25 minutes ago. Power usage and fire risk are concerns for me.