Interesting little digging from TechCrunch’s MG Siegler: as it turns out, Google’s Chrome OS is nearing completion. The company is currently testing a release candidate build, and has reiterated that devices running Chrome OS will arrive later this year.
Beside a service desk, help desk, … Where many clerks use a single application, what are uses for that beast?
pica
Good question. I am very sceptic, too. Also, Android’s success is quite a problem for Chrome OS, IMHO. The OEMs are just getting familiar with Android right now, the flood of upcomming devices is right around the corner and consumers seem to like Android quite a bit with it’s more traditional general purpose approach.
If Chrome OS can boot faster than Android, it’ll have a right to exist. My HTC Desire needs more than 45 seconds to boot! with a 1 Ghz processor! That should be unacceptable for all engineers involved.
Thats including 10 seconds for that silly HTC video to play when the phone boots right?
If you mean the animation where the phone writes “HTC quietly brilliant” on the screen… yes. The animation has really nothing particular, it’s rather mediocre.
Hopefully, something will be actually happening behind the scenes. Each time I wonder what could be so time-consuming in a stupid phone’s boot process.
Well, it’s easy to explain. Consider that DOS took around 30s to boot the hardware of the old days, and Windows 7 and Mac OS X still take about the same time on hardware that’s thousands of time faster.
How is that possible ? Software bloat. At each new releases, the devs of modern operating systems aim for that 30s mark, arguing that if people don’t complain about it enough it’s just good enough. Good enough by good enough, they save a lot of development time in optimization, and it just works as long as hardware processing power is growing according to Moore’s law…
Now, what happens when some manufacturer releases a new product based on old hardware, like a smartphone or a netbook, and tries to stick a desktop OS on top of it ? On that slower hardware, the wasted power hurts performance more than expected by the OS manufacturer. And we get 45s to 1min boot times, among other things like crappy battery life. Blame the hardware manufacturer for not putting a core i7 and a 4400 mAH/12.7V battery in the device.
The more I work on my OS, the more I’m horrified by how unnoticeable the performance impact of basic features now is. I’m growing more and more convinced that it’s superfluous features that no one uses that are so much harming performance.
Sure but how often do you perform a cold boot? I stopped caring about boot times after sleep/resume came out.
For my laptop : every time I use it, except when I only leave it for less than an hour and don’t have the time or the will to save my data.
For my phone : every morning.
Edited 2010-10-14 05:38 UTC
In fairness, modern boot sequences are doing a lot of useful work that DOS never did. For example, DOS just pulled the Centronics RESET pin low across all 3 printer ports (whether they existed or not 😉 for a few seconds and called the peripherals good, then stuck up a default mode 0 text screen with a prompt. Not that challenging, but then, with only 160k and a 4.77 MHz processor…
A modern OS walks the entire USB tree, validating and loading drivers dynamically as it goes, brings up one or more networks, dynamically configures video for the current set of monitors, loads a boatload of desktop extensions and configuration settings… It’s not just “bloat”, it’s very useful work given a billion users with very different preferences, hardware and peripheral sets.
Of course, focusing effort on boot time (by moving some configuration into the background, for example) can result in much faster boot times. For example, the last two Ubuntu releases together cut my desktop boot times by a factor of three.
That said, I reboot my devices (phone to server) so rarely I don’t particularly care. It’s more of a first impression consideration – “wow, Ubuntu boots fast!” – than a real productivity boost.
Yes, they do more, but I don’t think it’s enough.
With modern hardware, generating an identity-mapped page table for 2 GB of RAM is done in a very small fraction of second, and I’m suspicious that it’s the same with probing PCI and USB since the OS is more or less polling high-speed peripherals through an uncluttered bus.
Adaptation to multiple hardware and user configurations can slow down the thing a lot, yes, but only at first boot. At later boot, if there’s no change in system configuration, I think the OS can just go full speed as if it was made for the user’s specific configuration.
But I need more coding work before I can back this claim with experimental data.
Edited 2010-10-14 16:35 UTC
“At later boot, if there’s no change in system configuration…”
There’s the kicker, no? How do you know there’s no change in system configuration until you’ve fully scanned the system configuration?
I believe it was the ill-fated Lindows distribution that used to ask the user during boot if anything had changed, as in “Press ESC to scan hardware” or something (been a loooong time). It booted pretty fast, but of course, only at the very high cost of trusting the end user.
You might also be interested in the generic discussion of fast boot strategies at http://kerneltrap.org/node/2644.
Best wishes on your coding work toward finding even faster boot strategies. It’s part of the joy of open source, as they say. 😉
If I’m not misunderstood, the current boot procedure of most desktop operating systems is to scan hardware, then init every single peripheral as if it was newly plugged in (which takes some times, e.g. because you are forced to load some modules during boot instead of having them loaded by the bootloader together with the kernel).
Considering that during most boots hardware has been left unchanged, an interesting optimization to try IMHO would be to optimize this precise case.
-Scan hardware at boot, as usual
-Is there some new or removed hardware ?
-If not, use optimized boot procedure.
-If it is the case, “recompile” part or all of the optimized boot procedure.
This would lead to some slowdown when new hardware is plugged in, but to speed improvements in the common case.
If scanning is fast and only configuring newly plugged in hardware is slow, it could be worth trying.
More generally, when some settings of the system are left unchanged most of the time, I think that one should try to make the system perform almost as if they were hard-coded, even though such an approach leads to some performance hit when they are indeed changed.
It essentially comes around parallel startup, and in particular doing something while a process is waiting for I/O, it seems… A very important thought that should indeed have been around since day one, but only one thought still…
Heh
More generally, research on an interesting subject is fun, even when you do not earn money for it !
Edited 2010-10-15 16:14 UTC
In my opinion, the very existence of Splashtop shows how slow current boot procedures are.
then chrome os is what you want. At their presentation of chrome os they said that it will boot in less than 7 seconds
You my friend. Your next computer will be a tablet and it will boot only one OS and nothing else.
ChromeOS (or ChromiumOS) runs very well on the original eeePC 700-series, much better than any full-blown Linux install does. It’s allowed us to bring our eeePC 701s up-to-date in terms of web experience.
Secondary machines in the house for web browsing, tablets, public terminals, possibly generic office worker desks depending on what their tasks entail… It won’t replace traditional OS setups for most, but it’ll potentially have a nice niche supplementing them
“It was last July that Google dropped a nuclear bomb in announcing Chrome OS”…
We’ve heard about Chrome OS for more than a year. “Last July”, since this is October, was just a few months ago.
What’s it with Facebook? I can barely imagine leaving Google for that…