Google's Objectives with the Chrome OS
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:
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:
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.
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:
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.
This article originally appeared on Rich's Random Walks.