Cheating: Not just for Microsoft anymore

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