Linked by Thom Holwerda on Tue 12th Oct 2010 20:51 UTC
Google 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.
Thread beginning with comment 445179
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: "use cases" for Chrome OS
by ricegf on Fri 15th Oct 2010 11:01 UTC in reply to "RE[7]: "use cases" for Chrome OS"
ricegf
Member since:
2007-04-25

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

Reply Parent Score: 2

Neolander Member since:
2010-03-08

"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?

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.

You might also be interested in the generic discussion of fast boot strategies at http://kerneltrap.org/node/2644.

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

Best wishes on your coding work toward finding even faster boot strategies. It's part of the joy of open source, as they say. ;-)

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

Reply Parent Score: 2

Neolander Member since:
2010-03-08

In my opinion, the very existence of Splashtop shows how slow current boot procedures are.

Reply Parent Score: 2