Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Cheating: Not just for Microsoft anymore
Posted Sep 22, 2008 18:58 UTC (Mon) by drag (subscriber, #31333)
What ends up happening is that the user is presented with something that looks like it's ready to be used, but isn't. You may be missing your networking or not have file sharing, plus your system is using up all it's I/O and cpu, which means that it's not going to be responsive or open up your applications quickly.
A extreme example of this sort of approach would be just posting a screenshot of the desktop as the splashscreen and let the parts fill in and replace bits of the screen as they are loaded. It could be a neat effect, but it would be a lousy way to hide the fact that it takes many minutes to boot up your system.
Plus the point is to have the system fully bootable. So it's a challenge, a sport, so you have to have rules so nobody tries to cheat. :) Now if you have a system that boots under five seconds, but shaves off a second or two by bringing up a fake-ish user interface then that may be something else.
Posted Sep 22, 2008 19:38 UTC (Mon) by SimonKagstrom (subscriber, #49801)
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.
Posted Sep 22, 2008 22:28 UTC (Mon) by drag (subscriber, #31333)
I figure the services your starting up are starting up for good reason and you'll probably have applications that depend on them. Otherwise, on a desktop, what is the point of starting them? :)
Posted Sep 23, 2008 7:35 UTC (Tue) by michaeljt (subscriber, #39183)
Posted Sep 23, 2008 15:14 UTC (Tue) by macc (subscriber, #510)
It's either there or not after
boot ( server on remote host ).
Though an easy way to _really_
flush printjobs that have gone bad
would be nice too.
The next bloodpressure raisers
are beagle and that gaga
network-manager. ( on SuSE )
Posted Sep 23, 2008 20:05 UTC (Tue) by nix (subscriber, #2304)
Posted Sep 23, 2008 9:08 UTC (Tue) by NAR (subscriber, #1313)
Posted Sep 23, 2008 17:58 UTC (Tue) by arjan (subscriber, #36785)
Posted Sep 23, 2008 2:30 UTC (Tue) by k8to (subscriber, #15413)
Linux is of course a good deal better than this, but avoiding these devils bargains is still laudible.
Posted Oct 4, 2008 18:36 UTC (Sat) by pboddie (subscriber, #50784)
Well in the windows camp, for example, you can't even successfully operate the start menu.
Indeed. What's the point of showing the user the desktop if they can't actually use it? That's the question the Windows developers should be asking themselves.
Posted Sep 22, 2008 19:11 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246)
A lot of the problem is due to how Windows handles things. I can *try* to use the laptop, but random things keep killing the keyboard focus, and launching certain apps "too early" causes them to merely crash. (I suspect the app crashes are due to the firewall service, which I think is in the list of things started *after* login.) There's all sorts of stupid things in that delayed startup, such as the backup software throwing a splash screen up. I can only speculate on what keeps eating the keyboard focus. SMS scripts I suspect. (I get similar issues when the company rolls out patches--bizarre things happen to my keyboard focus and the whole desktop flashes.)
I haven't had similar issues with delayed services starting under Linux, since they are far, far less disruptive. Sure, the disk chugs a little in the background, but the only thing I've noticed is that Firefox might take a couple extra seconds to load. So, as a practical matter, some things *can* be started late without upsetting the user.
But, I suspect that wasn't the point. What ought and ought not to be started late is a judgment call, and the overall impact on the user can be difficult to judge without putting the result in front of a lot of users. For an apples-to-apples, this-is-the-real-thing-no-questions-asked comparison, it seems entirely appropriate to measure power-on to disk-and-CPU-idle. This eliminates judgment calls and fuzzy, difficult to measure impacts. It gives you a framework for tightly targeting a boot-time budget such as what Arjan described. You don't get to wiggle around the budget by saying "Oh, we can defer that one." Instead, you're forced to consider why it's slow and fix it.
If you need to throw a few things out of that initial boot, such as full network bringup in this example, then you can separately determine what its impact is.
Posted Sep 22, 2008 19:41 UTC (Mon) by elanthis (guest, #6227)
It's not wrong, if done right. It just didn't count for their target of
"everything necessary in 5 seconds." Minus networking, apparently, but
that's fine, since with wireless I don't generally get net access until I
login in and select an access point anyway.
Posted Sep 22, 2008 20:03 UTC (Mon) by arjan (subscriber, #36785)
Doing the "stuff in the background" is just hiding latency/boot time, it's not reducing it fundamentally.
Posted Sep 23, 2008 17:36 UTC (Tue) by pjm (subscriber, #2080)
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.)
Posted Sep 23, 2008 17:56 UTC (Tue) by arjan (subscriber, #36785)
(and note that our prototype has about half a second to a second to spare for services you want to add)
As for "login" needing NFS: sure if you configure NFS root, then you'll pay the price for NFS. I don't consider it acceptable that anybody who DOESN'T use NFS root has to pay that price. Even on a generic distro; the distro installer KNOWS nfs root is being used.
So I disagree with you that this isn't applicable to general distributions. General distributions will have to deal with more cases, but they have to, and can, deal with them smartly: only the people who use a feature should pay the price for it in terms of boot time. That doesn't make the distro less generic... and yes it means the distro needs to get several things right, but I consider that fair game.
Again: arjan, ....
Posted Sep 25, 2008 17:40 UTC (Thu) by hummassa (subscriber, #307)
Posted Oct 3, 2008 7:50 UTC (Fri) by dgm (subscriber, #49227)
In fact, this should be applicable to any other system resource: CPU, memory and disk usage.
Posted Sep 23, 2008 8:08 UTC (Tue) by farnz (guest, #17727)
That's orthogonal to what Arjan and Auke are doing. You can
combine "boot complete in 5 seconds" with "start the desktop before some
services are running", to get an even faster boot to the point where you
can work (at least in theory - if the critical path is now kernel startup
followed by X startup, you're doomed). Plus, the "boot complete in 5
seconds" misses some services I need - my mouse is a bluetooth device, for
example, and I use WiFi, both of which have to start after those 5 seconds
Also, "boot complete, CPU and disk idle" is a nice objective criteria,
that can be measured by tools designed for the job. "Booted to the point
where I can work" is not, and invokes the temptation to punt something
that's critical for most people's work until after login - for example,
with hotplug input device support in X, you could configure a core
keyboard, and punt hotplug devices until after X boots. The result is a
machine that you can use from the keyboard, but not with a mouse or
touchpad - as a keyboard user, that wouldn't stop me working, but it
wouldn't be in the spirit of "boot in 5 seconds".
Finally, which is actually better for you:
Posted Oct 3, 2008 17:25 UTC (Fri) by Janne (guest, #40891)
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.
Posted Oct 3, 2008 19:07 UTC (Fri) by farnz (guest, #17727)
You're missing a lot in your example timeline; let me rework it the way
it would actually happen:
Looking at that timeline, one important thing is clear - she has
already decided to go to a particular bookmarked website
before she touches the power button. All the time taken between her
pushing the power button and the website displaying is wasted by the
computer. Thus, the only time the OS has free to waste is the time taken
by Firefox to start up after the OS has started.
Secondly, note that Firefox's start up will be slowed down if the
computer is also trying to bring up the network, start printing services
and generally do other things at the same time. It's incredibly hard to
accurately judge how much idle time you have around application start
Finally, in my experience, services are not delayed after
thinking about use cases. Instead, the delay is based on getting the bare
minimum up and running to let me log in, with functionality taking a while
to come up after that. Making the challenge "get to idle in 5 seconds"
leaves room for someone to come in later, and build on that work to get
a "get to usable in 4 seconds, idle in 6", or even a "get to usable in
under a second, but idle takes 6 seconds".
Posted Oct 3, 2008 19:37 UTC (Fri) by Janne (guest, #40891)
You are describing a situation where the user is twitching to do something with the computer. Where the user even pre-positions the mouse in order to be able to do stuff as fast as possible. Those cases are very, very rare. Normal users do NOT work like that. Normally people don't start their computers thinking "OMG, I need to get online NOW!". And even if they did, the fact that the system boots in 5 seconds, means that they could get online a lot faster than with "normal" boot-sequence.
That said, I don't really understand the complaing about networking. My OpenSUSE-laptop takes ages to boot. And after it finally get to the desktop, it STILL spends few seconds connecting to the network! It would be A LOT better if it booted in 5 seconds, and then spend few seconds connecting to the network.
It makes sense to exclude networking from this experiment, since connecting to the network is not really part of what we call "booting". It's not up to your computer, it's basically being held back by the network. And hacking the boot-sequence of your computer does not touch your network in any shape or form. Network is completely outside the scope of this test. And just because you do not have working networking for few seconds does not mean that the computer is not usable. And still, the "normal" distros are just as slow as far as networking is concerned, so there are no drawbacks in this experiment, as far as networking is concerned.
So how would your wife benefit if the recipe-machine was using Ubuntu (for example)? Instead of booting in 5 seconds, the machine would boot in 45 seconds. Even if you had fully working networking after that 45 seconds (you wouldn't), it would still take about 30 seconds longer to get online than with this fast booting.
"Secondly, note that Firefox's start up will be slowed down if the computer is also trying to bring up the network"
Starting FIrefox taxes the HD and the CPU. Neither of those are taxed when your NIC is getting an IP-address.
"start printing services"
That could be started when the user actually wants to print. Why should we sit around, twiddling our thumbs, when the system starts printing-subsystem, even though the times we print are few and far between?
Posted Oct 4, 2008 11:11 UTC (Sat) by farnz (guest, #17727)
Then you're missing the entire point of the exercise - why does
she have to wait 45 seconds for the OS to boot? Why should she be waiting
up to a minute for things to be ready to use? Why can't she turn the
computer on and use it immediately?In short, why is using a computer with
a 1.83GHz Core 2 Duo and 4GB of RAM full of delays, when using an IPTV set
top box with typically 100MHz CPU and 32MB RAM is not? Granted, the tasks
are different, but the computer is so much more powerful than the STB that
it's a fair question.
The idea Arjan and Auke were working to is to set a hard challenge - a
typical Linux distro takes 30 seconds to get to the same point, they chose
5 seconds - and remove all the obstacles. If you allow delayed service
startup to not count, the danger is that you'll discount services that
matter to users. Indeed, you're already trying to handwave away an
important service for some use cases as "takes too long, and anyway users
can wait"; this is exactly why someone doing the challenge
must set a defined state in which boot is finished. Given the
defined state, I can now look at it, compare it to my use cases, and
say "yes, that's good enough", or "no, I need to work out how to fit WiFi
startup into that 5 seconds".
Again, as I've
said several times, you can go from "5 seconds power applied to idle and
ready" to "3 seconds power applied to usable, 3 more seconds to idle", and
that's a much easier task than going from "60 seconds power applied to
idle" to "3 seconds power applied to usable, 120 more seconds to idle.
Plus, my experience of normal users is very different to yours - they
don't have computers waiting and switched on, they don't start the
computer up without a task in mind, they start the computer thinking "Do I
have any e-mail waiting?", "Can I look up a recipe to use lemon sole,
potatoes and tomatoes?", "What do I need to say in this letter to my bank
manager?", "I need to get that proof printed for marking up" and things of
that nature. To them, a computer is just a tool; you wouldn't get out your
woodworking kit without something to build in mind, so why start up a
computer without a job in mind?
Posted Oct 7, 2008 12:59 UTC (Tue) by Janne (guest, #40891)
She doesn't. I mean, you can apparently boot Linux in 5 seconds ;).
"In short, why is using a computer with a 1.83GHz Core 2 Duo and 4GB of RAM
full of delays, when using an IPTV set top box with typically 100MHz CPU
and 32MB RAM is not?"
Well, that set-top box is designed to do one thing, and it's designed to do
it on one hardware-configuration. So they can optimize it like crazy. Those
do not apple to Linux.
that said, my DVR takes about 5-10 seconds to boot. My DVD-player takes few
seconds as well. My router takes about 10 seconds to become reachable.
"If you allow delayed service startup to not count, the danger is that
you'll discount services that matter to users."
But the thing is that we already have slow as hell boots, even with delayed
services. Like I said, my laptop running OpenSUSE takes ages to boot, and
when I DO get to the desktop, it's STILL not connected to the network! So
the difference between this fast booting and my OpenSUSE is that Arjans
system takes 5 seconds to boot, after which it takes few more seconds to
connect to the network, whereas my laptop takes 45-50 seconds to boot,
after which it takes few more seconds for it to connect to the network.
In other words: it takes just as long for the two systems to connect to the
network. The difference is that the things that happen before that net-
connection take 45-50 seconds on my laptop, whereas on Arjans EEE it only
takes 5 seconds.
And how would you connect to the WiFi befire getting to the desktop? I
mean, you might need to enter passwords and the like? Should the computer
stop booting and prompt you for your WPA-passowrd? No. It should get you to
the desktop and in to an usable state, and prompt you for any needed WiFi-
passwords as needed.
"Indeed, you're already trying to handwave away an important service for
some use cases as "takes too long, and anyway users can wait"; this is
exactly why someone doing the challenge must set a defined state in which
boot is finished. Given the defined state, I can now look at it, compare it
to my use cases, and say "yes, that's good enough", or "no, I need to work
out how to fit WiFi startup into that 5 seconds"."
But Wifi is not part of what we usually think of when we talk about
"booting". And like I said: I see no difference between this 5-seconds boot
when compared to normal booting, if we think of Wifi alone. In either case,
WiFi is disconnected at the end of the boot.
"Plus, my experience of normal users is very different to yours - they
don't have computers waiting and switched on, they don't start the computer
up without a task in mind, they start the computer thinking "Do I have any
Sure. But let's compare two scenarios:
User turns the computer on. It boots for about 45 seconds, and the user
logs in. After he gets to the desktop, he needs to wait for few seconds for
the network to become usable. Then he can check his mail
User turns on the computer. It boots in five seconds. User needs to wait
for few more seconds for network to become usable. Then he can check his
How is that normal distro handling networking better than the EEE is? It's
not online either, at the end of the boot.
removing WiFi from the equation we can focus on the subject at hand:
booting. WiFi relaies on other things that are totally outside the scope of
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds