This week sees the introduction of the first Chromebooks. But most of the things that Googleadvertises as features aren't really new or novel. In fact, most of those features are already available in one form or another on conventional PCs.
The Chromebook is essentially a 3G netbook that runs a secure, but very limited, operating system called Google Chrome OS. Chrome OS is based on Gentoo Linux, a highly customizable and fast Linux distribution, trimmed down to only run a single application: the Chromium web browser. All Chrome apps are really just in-browser web applications, some of which take advantage of the latest and greatest HTML5 features to offer a desktop-like experience.
I have some good first hand experience developing extensions for Chrome, the browser, and played around with Chromium OS (essentially the same as Chrome OS) when it was first announced. Because Google Chrome OS and the Chrome browser share a common codebase, I was curious to examine how Google’s claims look from a technical perspective.
Let's take a look under the hood at each of the advertised features to see what Google is really offering.
Because Chromebooks run a browser and nothing else, Google has trimmed down the boot time by eliminating many of the operating system components that typically need to be loaded. The solid-state drives, with their fast read performance, can load what’s left very quickly.
This doesn’t seem like much of a selling point: users aren't generally interested in boot time in particular; they just want the computer to be instantly available. When you talk to iPad owners about why they love the iPad usually they mention that you can just push a button and it's on. In reality, iPads and smartphones actually do take a while to boot up and and shut down, but you rarely have to do this. Since Chromebooks offer a long standby time (reportedly up to a week), the startup time doesn’t matter.
Of course there are times when a laptop really needs to be powered down, but for most people this need arises infrequently.
Chromebooks offer built-in 3G wireless to provide on-the-go connectivity, which is essential for a laptop that depends heavily on “the cloud.” The first Chromebooks will only have 16 GB of storage, which is plenty for booting an OS but not much if you want to store a significant amount of music, videos, or personal data.
It sounds nice to store everything “in the cloud”, but what happens when the network isn't available or if it's spotty? ChromeOS offers some technical solutions to deal with this, but to explain them I have to give a bit of background on Chrome apps.
Another important thing to note is that doing caching properly can get pretty technically hairy when dealing with syncing across multiple machines. It's not easy for developers to build apps that work properly offline, and Google doesn't provide any application-level APIs to help developers build software that syncs. That said, GMail features an offline mode and will automatically fetch and store data from your computer if the Internet connection is disrupted or is unreliable, and will sync up when the connection is restored (this option is temporarily disabled until 3Q 2011).
Same experience everywhere / Friends let friends log in:
These are non-features, in my opinion. All consumer operating systems support multiple user accounts that limit access to other users' data. What is different about Chrome OS is that in addition to data, the apps themselves are tied to a Google user account; someone should be able to login to any ChromeBook and quickly get access to all the apps and data already stored in their account.
Amazing web apps:
Some initially thought that because Google would continually update the OS, the computer itself would take longer to become obsolete. I don't think so. Chrome OS is going to behave like Chrome (the browser) in that software updates are going to be forced, so backwards compatibility is going to be a non-issue. That makes it easier for app developers in some ways because they don't have to worry about supporting multiple browser versions, but it does mean that they will have to be more aggressive at keeping up with browser updates.
An interesting note here is that some folks at Google developed an efficient differential compression algorithm called Courgette in order to make Chrome software updates dramatically smaller than was previously possible, which means faster, lower-bandwidth updates. In the example Google cites, the size of a small software patch was only 80 KB, which, for comparison, is about twice the size of a typical banner ad. The effect is that such small, quick updates improve overall security because software patches can be quickly pushed out and won’t burden users with a slow and cumbersome “software update” procedure.
Some also took the logic of the Chromebook to a ridiculous extreme, suggesting that there would be little need for better processors in future netbooks, because all the computing would be done in servers off in “the cloud.” Google even claims, “Chromebooks are designed to get faster over time as updates are released.” This may be technically true, but web-based apps are not going to become “thinner” over time. The current trend, in fact, is toward richer web applications, with more complex and sophisticated user interfaces for apps running in the browser (using HTML5 features), leaving only the real heavy-lifting duties for the server.
Chromebooks offer two paths to a more secure operating system, sandboxing and verified boot.
Sandboxing—preventing programs from messing with each other’s data— is nothing new; the HTML security model already prevents different web sites from directly accessing each other's data. (For example, one domain can't access cookies from another domain.) Smartphone apps work the sameway. And the same restriction applies to Chrome apps. The Chrome Extensions API provides a method to allow inter-application communication, but there isn't any kind of shared communication bus, only direct app-to-app communication.
The verified boot feature, on the other hand, is a pretty interesting feature. At boot time, the built-in encryption chip (the Trusted Platform Module) verifies a precomputed hash of the boot image to ensure that it hasn't been tampered with by any malware (or clever users, for that matter).
I don't know who exactly is going to buy these. The Chromebook is basically a 3G netbook with a more secure operating system. It can't run any popular Windows or Mac applications. 3G netbooks never took off, and 3G tablets and smartphones pretty much killed them off for consumers. It also doesn’t seem like Chromebooks will do well with some typical consumer tasks like uploading a bunch of photos and videos. A Chromebook might make a nice ancillary computer for simple uses like checking email and weather, but at the prices they are offering, a tablet will be more attractive.
I could see some small organizations that don't have large IT resources buying these. Managing a horde of Chromebooks is going to be more like managing corporate mobile phones and less like dealing with PCs. If a Chromebook develops a hardware problem, it can simply be swapped for another one. It remains to be seen how Google will do in the service arena - they aren't really known for their customer support.
It seems to me that this will be good for the PC manufacturers because Google is going to become one of their biggest customers and they are going to be able to rely on a more predictable (perhaps) recurring subscription model to sell hardware. It also gets them out from Microsoft's thumb a little bit.
It’s interesting to look back at the development of all of the different pieces over time that enabled the Chromebook: a new and fast browser with good Linux support and a fresh approach to software updates, an offline storage API (Google Gears), a new extensions API for building plugins and browser apps, a whole portfolio of cloud based apps (Gmail, GDocs, Picasa, GCal, etc). I'm not convinced that all these were part of a coherent long-term strategy, but Google has certainly leveraged their assets well to create a potentially disruptive new platform.