Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
In a presentation at the Ubuntu Developer Summit in Barcelona, developer Scott James Remnant noted that boot time decreased from 65 seconds in version 8.10 to only 25 seconds in 9.04. This is already a substantial improvement, but he believes that there is still room for more aggressive optimization. Canonical, the company behind Ubuntu, will continue pushing the limits of boot performance during the upcoming development cycle for Ubuntu 9.10, which is codenamed Karmic Koala. According to Remnant, the company aims to achieve a ten-second boot time next year for Ubuntu 10.04, the release that will follow after Karmic."
Posted Jun 10, 2009 23:10 UTC (Wed)
by atai (subscriber, #10977)
[Link] (4 responses)
Posted Jun 10, 2009 23:32 UTC (Wed)
by mattdm (subscriber, #18)
[Link]
Posted Jun 11, 2009 0:21 UTC (Thu)
by clugstj (subscriber, #4020)
[Link] (2 responses)
Posted Jun 11, 2009 16:00 UTC (Thu)
by salimma (subscriber, #34460)
[Link] (1 responses)
Both Fedora and Ubuntu are targeting 10 seconds next time around, AFAIR.
Posted Jun 11, 2009 17:56 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link]
Posted Jun 11, 2009 2:13 UTC (Thu)
by ajft (guest, #52749)
[Link] (53 responses)
Posted Jun 11, 2009 2:18 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (19 responses)
Laptops would be one big reason. Supend/resume is good as far as it goes, but shutdown and reboot is all too common. Mine won't cleanly dock/undock for example so reboot is the only option. Other folks dual boot.
Posted Jun 11, 2009 4:15 UTC (Thu)
by eru (subscriber, #2753)
[Link] (14 responses)
I have never seen this work reliably in Linux on any computer I have ever tried it on! At best the computer resumes, but there is always something missing, like sound. Fast boot (and fast shutdown, lets not forget about that side) is more likely to be implementable reliably, so more useful.
Posted Jun 11, 2009 4:22 UTC (Thu)
by skvidal (guest, #3094)
[Link] (11 responses)
Posted Jun 11, 2009 4:58 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (8 responses)
Posted Jun 11, 2009 7:18 UTC (Thu)
by eru (subscriber, #2753)
[Link] (7 responses)
Posted Jun 11, 2009 8:45 UTC (Thu)
by ledow (guest, #11753)
[Link] (2 responses)
It's very much dependent on the price paid for the hardware (so most people's hardware is just too cheap to do it), the manufacturer, the age (but that's *rarely* the issue), even the programs/hardware that are running at the time, and most importantly - the BIOS. Even my brand-new 2009-manufacturing-date laptop, bought for me by my employer can't do suspend/resume in Windows reliably, let alone Linux (but it is worse in Linux, which fits in with what I've experienced elsewhere). ACPI tables etc. play a big part in the process and most cheap computers have the bare minimum to let Windows play nicely and rarely, if ever, see a BIOS update to fix it.
In fact, I'm that disillusioned with suspend and related activities (Wake-on-LAN, etc.) that I just forget they exist now. They are rarely reliable on a well-used system (e.g. staff laptops) even if the system does support it and the machine is well-managed, so you can imagine what happens with 90% of people's PC's. Other network admins I speak to have the same problem and if they NEED this functionality (very rare), they specify it as terms of the supply contract so they can fall back on something. What happens then is that any kernel upgrades mean that the problems appear again (and thus they run ancient kernels to keep the functionality).
Apple Mac's seem to be much better, I grant you. I've not seen one of them fail to come back up. But even my Palm will sometimes refuse to turn on and that basically *lives* in sleep mode all the time. It's just not a reliable technology, even if there are pockets of experience that seem to indicate it is. And when we say "Linux machines", we're talking about a VAST range of hardware and thus, in general, "Linux machines" don't do suspend reliably (mainly because machines as a whole don't either).
Posted Jun 11, 2009 16:19 UTC (Thu)
by salimma (subscriber, #34460)
[Link] (1 responses)
I do agree that Macs have an advantage here -- being able to go from sleep to hibernate when the battery level goes critical. This is a new feature, though -- for a longest time Macs can't actually hibernate at all. Hopefully the PC world will eventually drop BIOS -- some laptops already ship with EFI firmwares, but with BIOS emulation forced to be on at all times.
Posted Jun 12, 2009 5:38 UTC (Fri)
by drag (guest, #31333)
[Link]
Posted Jun 11, 2009 19:12 UTC (Thu)
by liljencrantz (guest, #28458)
[Link]
Posted Jun 11, 2009 21:49 UTC (Thu)
by Trelane (subscriber, #56877)
[Link] (2 responses)
Posted Jun 14, 2009 4:03 UTC (Sun)
by eru (subscriber, #2753)
[Link] (1 responses)
Posted Jul 1, 2009 23:01 UTC (Wed)
by SEMW (guest, #52697)
[Link]
My eeepc (1000) suspends and resumes perfectly -- with Ubuntu.
Admittedly, this is using the array.org customised kernel, but even so.
Sadly, my desktop, which uses much older, more standard hardware, doesn't. Oh well, can't win them all..
Posted Jun 11, 2009 8:49 UTC (Thu)
by roberton (guest, #39680)
[Link] (1 responses)
For me this is great progress. My previous laptop never had this working reliably, and that over several versions of Ubuntu and Fedora. Annoyingly suspend/resume would sometimes work, but not reliably enough to be able to use it. Since it is all about convenience having it die 1 in 3 times kind of stops it being a useful feature...
Regarding boot up, I have an Asus netbook which doesn't get used everyday and so is usually off. The fact that it boots up pretty quickly does definitely make a difference to how often I get it out though. If it took 2 minutes (bad even for Windows I know, but just as an illustration), then I would probably use it far less. And I also agree with another commenter, it's interesting to see _why_ linux takes X seconds and what can be done to improve it. The quest to improve boot times seems to have made people look again at some old and ugly stuff that would otherwise just be left.
Roberto/.
Posted Jun 11, 2009 11:00 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
It's important to report bugs in suspend & resume. If you take the attitude that "that never works in Linux" then there is no bug filed, no-one has any reason to investigate why, it doesn't get fixed, so you've created a self-fulfilling prophecy. Particularly if it "almost" works, so that you get some diagnostics (e.g. for a while SATA didn't survive suspend on some hardware, but this meant a resume would give you kernel IO error reports that you could write into a bug report - obviously "the screen stays blank" isn't as helpful to maintainers)
I have reported, and had fixed, several suspend/resume bugs in previous laptops, including regressions. None of us would sit around saying "it's a shame the Linux USB subsystem crashes when you plug in a mouse, but that's just the way it has to be I suppose" (at least I hope not). Take the same attitude to any sub-system you want to work. If it's worth moaning about (as several have taken time to do in this comment thread) then it's worth writing a proper bug report.
My desktop PC doesn't (or didn't the last time I tried, it runs for months at a time recording TV and managing my DSL connection, so I don't try new kernels often) suspend correctly, but I believe that's related to the Nouveau driver, which is reverse-engineered from nVidia's super-secret hardware - so that's not a huge surprise.
Posted Jun 11, 2009 5:40 UTC (Thu)
by Los__D (guest, #15263)
[Link] (1 responses)
- Only thing is that VirtualBox can't be running, or there's an about 20% chance of a crash, but it's not really fair to blame anybody but Sun about that one.
However, hibernation is very unstable.
Posted Jun 11, 2009 15:20 UTC (Thu)
by szh (guest, #23558)
[Link]
Posted Jun 11, 2009 9:57 UTC (Thu)
by danpb (subscriber, #4831)
[Link] (2 responses)
IMHO this fixation of boot-time & pretty boot screens is diverting energy from more useful work. I'd rather hibernate-to-disk were 50% faster than boot-time be reduced from 20 to 10 seconds. If we care about pretty graphical boot, then we should focus on making hibernate / restore pretty. Those are things I experience every morning & evening.
Posted Jun 11, 2009 14:10 UTC (Thu)
by jwb (guest, #15467)
[Link]
Posted Jun 11, 2009 19:16 UTC (Thu)
by liljencrantz (guest, #28458)
[Link]
Posted Jun 11, 2009 16:37 UTC (Thu)
by Stephen_Beynon (guest, #4090)
[Link]
Posted Jun 11, 2009 3:15 UTC (Thu)
by sbergman27 (guest, #10767)
[Link] (3 responses)
Like it or not, we live in "The Real World" where we end up rebooting either more often than we need to, out of caution... less often than we should, out of pride... or more often than we want to, out of undesired necessity.
That said, that whole recent discussion on LKML about bringing back the once on, once off, replaced by udev, devfs fell pretty flat when one considers its reliance on the "boot time" argument as its stimulus.
Posted Jun 11, 2009 5:35 UTC (Thu)
by PO8 (guest, #41661)
[Link]
Posted Jun 11, 2009 10:58 UTC (Thu)
by prl (guest, #44893)
[Link] (1 responses)
Seconded. The Unix workstations that I recall from the early 90s booted quicker than many systems now - despite processors that are 1000 times faster. One of the main problems is that we have been conditioned by BIOSen and Windows to expect that boots take a long time. Clearly they don't need to - but expectations have been lowered so that even our 3 year-old DVD recorder takes 20 seconds to start up, which is about 4 times longer than the VCR it replaced. Utterly ridiculous. On the Linux front, it does appear that some applications have become lazy about how long it takes to boot up even simple configs. I reboot often enough that I would prefer not to lose the time. But one excellent reason is good PR - I very much want Linux newbies to see a 10 second boot. They should be impressed from the first minute. I hope that wider support of coreboot (LinuxBIOS as was) will help here, as well as the new ARM netbooks (which don't need legacy BIOSen).
Posted Jun 11, 2009 14:12 UTC (Thu)
by jwb (guest, #15467)
[Link]
DOS on a Pentium, *that* was a smoking fast boot.
Posted Jun 11, 2009 4:14 UTC (Thu)
by ncm (guest, #165)
[Link] (1 responses)
Posted Jul 1, 2009 22:56 UTC (Wed)
by SEMW (guest, #52697)
[Link]
Posted Jun 11, 2009 4:25 UTC (Thu)
by dkite (guest, #4577)
[Link]
Phone rings. I turn machine on, and can jot notes of the call as I talk.
All day without having to plug it in.
And the hardware has to be cheap enough to not worry too much about it
And I have to be able to type on the darn thing.
Hence the 'obsession' with boot times. Or a low power instant on.
Derek
Posted Jun 11, 2009 8:52 UTC (Thu)
by fb (guest, #53265)
[Link]
Most people complaining about faster booting efforts seem to thinking in server/data-center terms where machines are not turned out. Or about their own laptops which never fail to suspend. _My_ laptop sometimes fail to suspend.
I also have a NAS at home (running Debian) which I turn off when not using it, and also have a Android Developer Phone. Both could use some faster boot time.
[...]
I used to have a PentiumIII running Debian that would boot in 20s. It really smells of bad engineering that years later my Core2Duo laptop was booting at around 50s.
Posted Jun 11, 2009 9:27 UTC (Thu)
by skitching (guest, #36856)
[Link] (13 responses)
Posted Jun 11, 2009 10:00 UTC (Thu)
by danpb (subscriber, #4831)
[Link] (1 responses)
Posted Jun 11, 2009 10:30 UTC (Thu)
by prl (guest, #44893)
[Link]
Those with long memories will recall that the idea of the BIOS was that it was a VM - so that DOS could boot without needing inconvenient drivers for multiple disk and graphics hardware. In fact I recollect that the original idea was that DOS would continue to use the BIOS calls once it had booted - but the hardware manufacturers quickly realised that this was staggeringly inefficient. The idea was expanded to network cards (PXE) and power management (APM and then ACPI). The poor quality of all the various implementations just shows that relying on firmware like this is not a good idea...
Posted Jun 11, 2009 12:05 UTC (Thu)
by nye (subscriber, #51576)
[Link] (9 responses)
Posted Jun 11, 2009 14:14 UTC (Thu)
by jwb (guest, #15467)
[Link]
Posted Jun 11, 2009 14:59 UTC (Thu)
by paragw (guest, #45306)
[Link] (7 responses)
Apart from that suspend resume works *only* with Linux on this machine - great to be on the
Posted Jun 11, 2009 16:44 UTC (Thu)
by nye (subscriber, #51576)
[Link] (6 responses)
Posted Jun 11, 2009 18:42 UTC (Thu)
by paragw (guest, #45306)
[Link] (5 responses)
Posted Jun 11, 2009 21:00 UTC (Thu)
by khc (guest, #45209)
[Link] (4 responses)
Posted Jun 11, 2009 21:22 UTC (Thu)
by larryr (guest, #4030)
[Link] (3 responses)
Essentially it is the same as doing "reboot" except instead of going back to the BIOS, the running Linux kernel just runs the subsequent instance of the kernel directly, as it would be by GRUB or whatever the bootloader is. One thing it might be used for is to boot from the BIOS into a minimal Linux OS instance which is essentially a super intelligent bootloader which uses kexec to boot the desired target OS... that way not much intelligence is required of the bootloader which the BIOS calls. But actually using kexec from the Linux shell is pretty mundane and anticlimactic by itself. Larry
Posted Jun 11, 2009 23:25 UTC (Thu)
by khc (guest, #45209)
[Link] (2 responses)
Posted Jun 12, 2009 1:09 UTC (Fri)
by paragw (guest, #45306)
[Link] (1 responses)
If you need to kexec a new kernel you can do something like this at the command line -
$) sudo kexec -l /boot/vmlinuz --append="root=blah" --initrd=/boot/initrd.img
man kexec for more details... Posted Jun 11, 2009 15:09 UTC (Thu)
by Los__D (guest, #15263)
[Link]
Posted Jun 11, 2009 9:52 UTC (Thu)
by k3ninho (subscriber, #50375)
[Link]
Posted Jun 11, 2009 10:17 UTC (Thu)
by epa (subscriber, #39769)
[Link] (2 responses)
The time taken to shut down the system could also be improved...
Posted Jun 12, 2009 1:31 UTC (Fri)
by foom (subscriber, #14868)
[Link] (1 responses)
lsof also works well for this. Keep restarting servers incrementally, until lsof tells you nobody has
Posted Jun 15, 2009 14:55 UTC (Mon)
by pabs (subscriber, #43278)
[Link]
Posted Jun 11, 2009 17:14 UTC (Thu)
by warp (guest, #14659)
[Link] (2 responses)
I work for a credit card processor, I will never be able to use suspend to ram because of the 'cold boot' class of attacks.
Of course, I will never see a straight 10 second boot time because the whole disk encryption setup I use involves both a passphrase and a USB mass storage device, but the less time I have to wait before I can enter the passphrase, and the less time I have to wait after I have done so, the better.
Please, don't make the assumption that people _can_ simply suspend to ram, or that suspend to disk is all _that_ fast to come up from when you're having to restore from encrypted swap.
Posted Jun 12, 2009 9:26 UTC (Fri)
by amonnet (guest, #54852)
[Link] (1 responses)
If i have physical access to your system (has needed by this kind of attack), i'd just pull the plug out of it and start with my boot device of choice. I would not trust your suspend to ram anyway.
Posted Jun 12, 2009 19:27 UTC (Fri)
by warp (guest, #14659)
[Link]
With full disk encryption and a suspend to ram system, the cold boot issue allows them to grab the memory from the system, potentially even move it to another system, and grab the decryption keys for the HD.
Now, ideally, Linux overwrite the encryption keys on shut down, but.
Posted Jun 11, 2009 17:34 UTC (Thu)
by martinfick (subscriber, #4455)
[Link] (1 responses)
Now let's look at a server with great uptimes... Oh, a hardware failure, put in a new card, boot. Oops still fails, maybe the card wasn't bad, how about swapping the memory, boot. Still bad, hmm, that IDE cable looks a little twisted, let's replace it instead, boot... add in a config change or two to accommodate the forced hardware change and you might have a few more reboots. Suddenly that 10 second boot time is starting to look appealing for my uptime, and my sanity. A stretched example with naive assumptions? Probably. Nevertheless it is naive to think that servers would not also benefit from uptimes. The longer the uptimes of your server, the more likely that some change that happened during the previous uptime will inadvertently affect the way the system boots this time, possibly causing another required fix/reboot cycle. Longer uptimes means longer lurking potential boot problems.
Posted Jun 11, 2009 21:06 UTC (Thu)
by nix (subscriber, #2304)
[Link]
(It's about 30s. 30s! It's a good thing this machine never gets shut
Posted Jun 12, 2009 3:04 UTC (Fri)
by gdt (subscriber, #6284)
[Link]
Some of us have to run serious services, where downtime per service per annum must be less than a few seconds. With server reboot times in seconds rather than minutes the periods when a service is in a hazardous condition is very much reduced. This in turn can save serious money -- you might only need to deploy three redundant sites rather than four. I'd suggest that people don't try to contain features within tight boxes. Real time computing is very much useful for some websites, not just for hardware controllers. Power saving is important in ten thousand server computer rooms, not just in phones.
Posted Jun 19, 2009 10:16 UTC (Fri)
by jamesh (guest, #1159)
[Link]
If you are creating and destroying virtual machines in response to load, it is nice if they start up fast since the time spent starting the VM is waste and costs money.
Things like hibernation or suspending the VM are not particularly interesting for this model either. Each VM will usually be a clone of a smaller set of machine images, so the state of individual VMs is not that interesting. Further more, if you did suspend/hibernate the VM you'd need to store that image somewhere and that would also cost money.
These benefits are most obvious when using leased resources like Amazon EC2, but can also be relevant for private clouds: the time spent starting a VM is time that can't be used by another VM.
Posted Jun 11, 2009 10:01 UTC (Thu)
by alecs1 (guest, #46699)
[Link]
Having the machine boot fast is a nice second thing. More important than I would like.
Third would be to have KDE startup faster. Because that is CPU bound, by updating the hardware the time was more than halved.
Posted Jun 11, 2009 14:06 UTC (Thu)
by sdalley (subscriber, #18550)
[Link] (1 responses)
What's not so great is that it takes a full 20% of that time every time Firefox or Thunderbird (Fedora 10) just redraws its window on my thin client. This is without app processing of any kind. Just wave an xterm in front of it and watch the graphics huffing and puffing for 2-3s to get things back to exactly how they were. It seems to be proportional to the number of widgets, Dia is even more dire. Somehow this doesn't seem like progress.
Doing an "xdpyinfo" on a thin client (a SunRay 1) showed that the X server had the following extensions:
Emacs refreshes instantly, Tcl/Tk apps refresh instantly, Gnome apps and Ooo are dog slow. It would be illuminating to know where all that time is actually going. Anyone know?
Posted Jun 11, 2009 14:39 UTC (Thu)
by jwb (guest, #15467)
[Link]
Posted Jun 11, 2009 18:32 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (5 responses)
Posted Jun 11, 2009 23:49 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
Here's the question I can't find an answer to. What desktop related processes are in the target 10sec boot budget. The Ubuntu budget gives 4 seconds to login and get to an idle desktop. What's running by default on that idle desktop? Not just applications..but desktop elements like applets that exist as separate processes.
You boot up, you autologin..and the desktop comes up. How rich is the desktop experience that can be achieved in 4 seconds to reach idle cpu and disk io? Does the target desktop you can get to in 4 seconds a real world usage pattern? How quickly does that achievable boot time decay once you start using the desktop and changing settings so the default desktop is useful?
Hell just throwing image files onto your desktop for nautilus to render preview images of could significantly put you over the budget. Is Ubuntu still setting its Download folder in xdg to the Desktop?
Obviously this sort of benchmark has to be a non-networking active target. Just searching for wireless networks can take that long and will keep you out of the target idle state.
-jef
Posted Jun 12, 2009 14:43 UTC (Fri)
by james_w (guest, #51167)
[Link] (3 responses)
The budget is to get to a clean image of the default Ubuntu desktop.
> Does the target desktop you can get to in 4 seconds a real world usage pattern?
... so yes.
> How quickly does that achievable boot time decay once you start using
The default desktop is useful.
Obviously if you start changing things then the time taken to log in will change. How much it changes depends on what alterations you make.
The target of this work is to make Ubuntu boot faster. The budget is for the default configuration running on the target platform, so that is the only place you can be sure to see 10 second boot. Anywhere else it will be faster, but you can't count on 10s.
If adding particular things to the desktop adds more time to the login sequence than it should then that can be fixed as well, but the focus of this effort is to gain a quick, consistent, maintainable baseline. Not to try and ensure that every machine, in any configuration, can boot in 10 seconds.
The aim isn't to game the system. Scott has always said that the timings will always be to a particular point, and that doing certain things, like delaying the startup of some services for a few minutes are not acceptable. The aim isn't just to get a headline boot speed, but the ensure that the boot process is as well engineered as possible. Much of the work done for 9.04 was removing some unneeded things from the startup sequence, such as trying to set the hardware clock at multiple points.
This means that the improvements will rarely come at the cost of increasing the cost of adding one more thing to the log in sequence. Unlike some systems, the gains won't be achieved a by carving out lots of things that aren't needed in the target configuration, everything should still work the same as before, it will just get there more quickly.
Thanks,
James
Posted Jun 12, 2009 14:54 UTC (Fri)
by mjthayer (guest, #39183)
[Link]
Seconded, I use the default desktop as my standard working environment. I dislike wasting time with unneeded customisation, and I want to be able to get from a clean install to my working environment as quickly as possible if ever needed - and the default Ubuntu desktop does what I need it to.
Posted Jun 12, 2009 16:28 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
I thought the budget was to an idle desktop.. idle disk..idle cpu. idle disk and idle cpu is slightly more aggressive than "get to a".
I can use a desktop that is still churning disk and cpu rendering file thumbnail images sitting on the Desktop. But that's not an idle target.
Does "clean" have a specific meaning in the context of the stated "idle" desktop that needs to be explicitly defined? Because its not used in the announcement email.
"The default desktop is useful"
You missed the main point I was trying to make. How long does a default "clean" desktop.. stay "clean" when its actually in use? Even when someone does not change any settings. Does having a list of "Recent Documents" significantly degrade the speed of the GNOME panel loading? If Ubuntu is still pointing xdg download directory to the desktop, does having things like thumbnail images to render of downloaded files severely degrade bootup? It's not just about the first boot after a fresh install. It's about the consistency of boot times when the user has made absolutely no settings changes. I think in particular the Desktop as download directory xdg setting that Ubuntu carries will make it difficult for that 4 second "idle" desktop budget into the Gnome desktop to be achievable outside of the very special conditions of a fresh desktop that has seen little or no internet usage.
-jef
Posted Jun 12, 2009 17:12 UTC (Fri)
by james_w (guest, #51167)
[Link]
By clean I meant "fresh install".
> You missed the main point I was trying to make.
No, I chose to take a shot at your wording. After that sentence I spoke to the rest of your concerns.
> I think in particular the Desktop as download directory xdg setting that
As I said, the budgets are for a fresh install on the target platform. The aim is not to ensure that every Ubuntu desktop on every system loads in 4 seconds, as great as that would be.
> Does having a list of "Recent Documents" significantly degrade the speed
If they do then we should look at fixing them.
Trying to provide a good base on which we can build doesn't mean that we won't try and fix other issues. We don't have to fix all performance issues in order to get some benefit.
The 10s target is a known state, a fresh install, on a single platform for consistency, so that it is easily repeatable. Once that is done it might be nice to have secondary targets that provide more "real world" setups. It's easy for anyone to profile their particular sequence and help to trim the fat though, so you don't need the same control over the platform and image, and time targets aren't useful, they are essentially arbitrary anyway.
Thanks,
James
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
http://fedoraproject.org/wiki/Features/20SecondStartup
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Supend/resume is good as far as it goes,
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Well, maybe I have been unusually unlucky, then. The last straw was a few weeks ago, when a netbook I bought with bundled Linux managed to suspend/resume once, but trying it again froze the machine, and the processor fan started whirring at full speed. Lucky the eeepc 901 has a hard reset button accessible with a straightened paper clip...
re happy stories about suspending Linux boxes
re happy stories about suspending Linux boxes
re happy stories about suspending Linux boxes
re happy stories about suspending Linux boxes
bios. Vista and newer Windows OSes support EFI...
re happy stories about suspending Linux boxes
re happy stories about suspending Linux boxes
That was with the original installation. Upgrading the OS seems to have helped. OK, now I have one example of a Linux system where suspend/resume works. But one would have expected that since this is one of the rare cases where the hardware vendor co-operated with the distro maker on a known hardware configuration, suspend/resume would have worked out-of-the box.
re happy stories about suspending Linux boxes
re happy stories about suspending Linux boxes
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
am lucky to have uptime measured in hours !
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
bouncing around or being lost/stolen.
Whatever.
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
The "real" machine is (or was) a VM...
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
BIOS. The BIOS on my workstation (HP xw6600) takes a long time compared to the OS (Ubuntu 9.04)
- they would benefit greatly from switching to Coreboot.
other side finally! (It came with Vista and thru SP1/SP2 it has always failed to suspend/resume
reliably.)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
for me on multiple machines.
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
how does one use this?
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
you do a restart either via the UI or via command line, it will by default kexec the kernel.
$) sudo kexec -e
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
> only way to be sure that you are running the new code everywhere on the system.
the old (deleted) file open.
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Tyan S7010's BIOS sits at a dead black screen before deigning to show you
*anything*?
down...)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
10s to boot. 2s to redraw a Thunderbird or Firefox window on a thin client
AccessX Adobe-DPS-Extension DAMAGE DOUBLE-BUFFER DPMS DPSExtension Extended-Visual-Information FBPM GLX LBX
MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD Multi-Buffering
RECORD SECURITY SHAPE
SUN_ALLPLANES SUN_DGA SUN_OVL SUN_SME SYNC SolarisIA TOG-CUP
X-Resource XC-APPGROUP XC-MISC XEVIE XFIXES XIE
XInputDeviceEvents XInputExtension XTEST
10s to boot. 2s to redraw a Thunderbird or Firefox window on a thin client
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
> processes are in the target 10sec boot budget. The Ubuntu budget gives 4
> seconds to login and get to an idle desktop. What's running by default on
> that idle desktop? Not just applications..but desktop elements like
> applets that exist as separate processes.
> the desktop and changing settings so the default desktop is useful?
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
https://lists.ubuntu.com/archives/ubuntu-devel/2009-June/...
Ubuntu aims for ten-second boot time with 10.04 (ars Technica)
> desktop that needs to be explicitly defined? Because its not used in the
> announcement email.
> Ubuntu carries will make it difficult for that 4 second "idle" desktop
> budget into the Gnome desktop to be achievable outside of the very
> special conditions of a fresh desktop that has seen little or no
> internet usage.
> of the GNOME panel loading? If Ubuntu is still pointing xdg download
> directory to the desktop, does having things like thumbnail images to
> render of downloaded files severely degrade bootup?