Cheating: Not just for Microsoft anymore

Well, if it's a sport - I agree, there should be the same rules for everyone :-)

However, otherwise I simply want to start working as soon as possible after I've logged in (as probably most people here, I seldomly boot). Obviously showing a screenshot of the desktop is just plain silly, but why should I have to wait for some network share to be mounted unless I really need it?

Applications will start slower, sure, but if the system is unusable because of I/O caused by daemons starting in the background I'd consider that a plain bug which should be fixed.

// Simon

What question are we discussing here? Are we discussing what some useful rules for an artificial game are, or what should normal system startup behaviour be?

Let's address the second of those first.

Note that what's been demonstrated isn't in fact "done" by 5 seconds: networking isn't up, bluetooth isn't up, various other services aren't up. Some users do want these services to be started at around boot time (e.g. maybe they can't get any work done until the network is up, or have only a bluetooth keyboard), but may nevertheless want to be able to start work before waiting for the some services to have started. In other words, they do want the system to be "putting up a desktop while still starting services behind the scenes" (or at least put up a desktop before all services have started, i.e. further delaying some services to reduce resource contention while the user starts some applications). Certainly many users would want to be able to enter their username & password while other things are still starting, as an instance of parallelization.

That still leaves various issues like avoiding bad behaviour when applications (including the one handling the login) don't have services they need, but we can at least say that in principle users would like to have a usable desktop as soon as possible even if some services that they want to be started around boot time haven't yet started.

On to the question of good rules for a game.

The idea of having such a game is for it to result in improvements to the systems that people actually run, where "improvements" is defined by what people actually care about.

If the game rules result in a system too distant from what will run on real systems, then it's harder to translate the game-produced system across to real systems, which may result in this transferral not happening. This suggests that the game rules should be such that the resulting system does start networking, avahi etc. (That's not to say that the goodness metric should be simply the time taken for all services to have started.)

Having game players spend time "do[ing] a lot of damage to X" or changes that break hardware that distributors want to support regardless of boot time, such work isn't useful unless someone does the remaining work of re-adding any of the lost functionality that the distributor considers more valuable than the corresponding reduction in boot time. If there's doubt as to whether anyone would do that work, then maybe the rules shouldn't reward optimizations that do more damage than most distributors would accept; whereas in cases where it is likely that someone else would do the work, then perhaps it's better to reward work on such damaging optimizations than not to have those optimizations.

Different users need different things started up before they can be productive with their machine. The goodness metric for the game can either go for simplicity (choose a common case and optimize that while ignoring all others' needs), or we can try to weight different cases according to their importance to most distributors (which is somewhat arbitrary in choice of weighting, but should result in improvements for more users). We don't have to choose the weights in advance, it's enough for game players to understand that it will be judged by a weighting of the value of the system for different types of users, and that the weighting and judgement of "system value" is intended to reflect real-world values. (Of course there's value in game players being informed about the relative importance of different use cases or how people value boot time compared to lost functionality, but we don't need to specify it all in great detail before a game can begin.)

On the question of delaying login to avoid applications misbehaving when services they need aren't started yet: Note that even the program handling the login might need the network up (for network filesystems or other remote databases) or need setroubleshootd running to debug a problem in that login handler. Maybe some upstart (etc.) ideas can be applied to user applications rather than just init scripts. (Some init replacements work statically, doing a topological sort to determine startup order, whereas other init replacements, possibly including upstart, allow for processes to be started but block on some service coming up.)

I really don't understand this argument. So the machine has not really booted, since network (for example) is not up yet? Well, why should it be? Because you want to use the network right after you get to the desktop? Well, think about it: You get to the desktop, but the network is not yet running. You then decide to launch Firefox. It takes you maybe 2-4 seconds to click the Firefox-icon, it takes anout 2-4 seconds for Firefox to launch, and then it takes you another 2-4 seconds to type in an URL in Firefox. That means that the system has 6-12 additional seconds to bring the network up before you actually NEED to have the network up&running. Network might not be running right after you get to the desktop, but it does not need to be, since it would take you several seconds to actually DO something with the network in any case! Do you need to have networking up if you are not actually using the network for anything?

People who complain about services that are not running right after boot, fail to understand the fact that it takes several seconds for the user to actually DO anything with the system in any case. And that means that the system has quite a bit of time to bring any missing service up before the user actually needs it. Whenever I log in to a machine, I do not launch apps in a split-second or start frantically working right away. No, it takes me quite a few seconds to get up to speed. And the system can use those seconds to load any needed services that are not yet up.

Of course there are wrong ways to do this, like what MS does with XP, where the system is actually un-usable for longish time after you get to the desktop.

The log-in screen should be shown as early as possible (before even X) and should not block the boot process. Thus the computer would be usable earlier, because the boot process would continue while the user is typing her password. This is especially important for users who are slow to authenticate -- some users take about 4 seconds. With a normal boot, they would wait n seconds to see the log-in screen, spend m extra seconds logging in, then wait d seconds till they can use the desktop. If they can authenticate after x second while the computer is booting, they only wait max(n - x, m) + d seconds to use the computer.

With a long boot, this also allows users to authenticate themselves whenever is convenient for them, rather than waiting to do it at the right time for the machine.

And, knowing which user is logging in will allow further parallelization of loading the user's desktop components and services. That will reduce the time "d" required to start up the desktop.