Google's Objectives with the Chrome OS

by Rich

Friday, July 17, 2009 at 10:07 PM EDT

Google’s announcement of their Chrome OS project has triggered a good deal of speculation about Google’s objectives, and about what the final product might be like. The Technology Review, published by MIT, has an article by Erica Naone, which discusses how some characteristics of Google’s Chrome browser might have implications for the OS project:

The first netbook devices running Chrome OS won’t be released until the second half of 2010, so most users will have to wait until then to find out precisely how the software will work. But that doesn’t mean there aren’t hints out there already, and the biggest clues can be found in Google’s Chrome browser, which the company says will be a key part of the new OS.

As I discussed when the Chrome OS was first announced, Google as a firm makes its money from selling advertising on the Internet, and it is in Google’s interest to get more people to spend more time surfing the Web. So it is no surprise that the company envisions Chrome OS as a Web-centric system, with the user interaction focused through the browser:

Speed, simplicity and security are the key aspects of Google Chrome OS. We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web.

The Chrome browser does have some significant design differences from more conventional browsers like Mozilla’s Firefox. Because Google is a supplier of Web applications (such as Google Mail and Google Docs), the Chrome browser was designed with running Web apps in mind. One specific significant difference relates to browsing on more than one page or site at a time. Although both Firefox and Chrome can open multiple tabs and windows, in Firefox these are different threads of execution running in the same address space, while in Chrome they are separate processes, each with its own address space. A consequence of this is that, if one session crashes or hangs, it is much less likely to affect other sessions in Chrome than it is in Firefox.

The trade-off, in a conventional OS, is that creating and running separate processes requires more resources than creating and running threads. (In fact, some OS environments call threads “light-weight processes”.) But in an OS built mainly to support a browser environment, all of the process primitives in the OS can be optimized for that environment. That would address one of the things that is clumsy with Web applications today: the combination of browser and conventional OS is not really that good at dynamically adjusting memory allocations as the Web application mix changes.

A major role for the OS is allocating memory to applications and adjusting it as their needs change. A big problem with interactive Web applications to date has been that browsers didn’t have efficient ways to adjust the memory assigned to different Web pages.

If you work with Firefox on Linux (as I do), you will probably have noticed that, a few hours after the browser is started, things begin to slow down if you have many windows and/or tabs open. One of the reasons this occurs is that the browser cannot always reclaim resources completely when a tab is closed, for example. (To be fair to the good folks at Mozilla, this works much better now that it did a couple of years ago.) A resource allocation subsystem built to support a browser should be able to do this much better.

Another factor has to do with the user interface mechanism. Many of the GUI elements used by the browser are in fact supplied by the underlying environment. In Microsoft Windows, the GUI environment is closely tied to the operating system itself, which creates a good deal of complexity. In Unix or Linux, the usual GUI environment is the X-Window System, which is separate from and runs on top of the OS. Although this simpifies some things, X is itself a very complex bit of software. For example, it has been from the beginning a “network aware” interface, which allows one to run an application on one machine and use the display and keyboard of another machine on the network. (We used this almost 20 years ago for remote software demonstrations across town and across the Atlantic.) Once again, a GUI framework tailored to the specific requirements of browser-based applications should be considerably more agile and efficient.

Perhaps the most intriguing possibility is a new type of capability that Google is said to be considering as part of the Chrome OS:

The company is working on an experimental project called Google Native Client that would allow code written in non-Web languages such as C and C++ to run securely in the browser.

Chris Rohlf, a senior security consultant for Matasano Security, which has been involved in testing the implementation of Native Client, says, “It could be Google’s secret weapon when it comes to Chrome OS, because it would allow developers to extend that platform with things like video and graphics without having to wait for Google to implement any of that.”

This has many interesting possibilities: it would, as Mt. Rohlf says, allow the platform to be extended. It might also allow Web applications to utilize specialized application libraries, written in more traditional languages like C or C++, for mathematics, statistics, financial modeling, and the like,

I think this is going to be fun to watch.