Tuesday, November 13, 2012

Inventing Chromebook

While working for Google back in 2006, I had the good fortune to create a new operating system.

I confess it wasn't created from scratch.  It was a chopped down Linux distribution - as so many "new" operating systems are, these days.

This new operating system was originally code-named "Google OS" and since 2009 has been released to the public under the product names, Google Chrome OS, Chromebook, and Chromebox.   I wrote a patent for it, #8,239,662, titled "Network-based Operating System Across Devices" that was finally granted in August 7, 2012.  Long after I left Google.

Here's a few interesting tidbits about the invention of Chromebook.

First, Chromebook was initially rejected by Google management.  In fact I wrote the first version as early as July 2006 and showed it around to management.  Instead of launching a project, the response was extremely tepid.  My boss complained, "You can't use it on an airplane."  Actually, you could as, under the covers, it was still a bare-bones Linux distribution and could execute any Linux program installed on it.

Second, Google OS was not originally written for Chrome or called "Chrome OS".  The first versions were all based on Firefox.  When I wrote the first version in 2006, Google had not yet started developing a web browser of its own, nor had the name "Chrome" exist as a Google product.  Chrome versions followed in 2007, after internal beta test versions of Chrome started to be passed around inside Google.

Chromebook (2007)

Third, Chromebook was definitely not intended to be "another device" for web browsing - as many product reviewers have characterized the Samsung Chromebook models.  The first versions were bare-bones Linux distributions, but fully functional for many tasks, including code development for a Google engineer.  I myself used versions of Chromebook, exclusively, every day, for over a year as my primary development box, taking it on many business trips, and even some airplanes.

Fourth, the main priority of Chromebook - originally - was not to write a webapp-only operating system.  In fact, the main priority when I started constructing the operating system was the need for speed - to create a super-fast operating system.

Why bother to write a super-fast operating system?  I was frustrated with Windows and Linux, which I perceived were unnecessarily slow.  For example, at that time my occupation was writing webapps for Google, so I was restarting my web browser frequently, sometimes hundreds of times a day, to clear browser cache and cookies as part of the code development process.  Restarting the web browser was a particularly slow operation, often taking 30-45 seconds, whether IE or Firefox, Linux or Windows. (Chrome not being available in 2006.)  However, even simple tasks such as displaying a directory in a file explorer were unreasonably slow operations, requiring several seconds for a task that should be nearly instantaneous.  A few seconds here, 45 seconds there, might not sound like much of a delay, but when such delays occur hundreds of times a day, it adds up to a costly amount of time.

The solution?  Eliminate bottlenecks in the kernel, particularly file I/O.  By depending on well optimized kernel without many of the bottlenecks in Goobuntu, many tasks became nearly instantaneous, without having to rewrite or do any performance optimization at all for thousands of applications that make up the operating system.  For example, restarting Firefox went from ~45 seconds to ~1 second.  Browsing a directory in the file explorer went from ~8 seconds to ~0.01 seconds.  Even compiling Google's massive code base became 60% faster.

When discussing the web-app architecture of Chromebook, nearly everyone expresses concerns about network connectivity.  In fact, network connectivity was not a problem for several reasons.  First, even in those early days, Google was experimenting with off-line modes for web-apps. Since all tasks were performed as web-apps and could be migrated to off-line web-apps eventually, any issue could eventually be mitigated with web-app code running on the webtop. Second, synchronization with Google Drive guaranteed user data was replicated and available from the network server. In some ways, that was even more convenient than the traditional approach to file systems, because it meant a user could switch from one webtop to another web top, and see updates to their data move with them. Finally, nearly all users are connected all the time!

Running a webtop operating system did pose other challenges.  First, avoiding the installation of any bloated applications.  A bloated application hogging a few gigabytes of hard disk space might not be painful on a disk, but for our goal of deploying an operating system for entry level hardware, it would add significant expense.  Such bloat had to be avoided by replacing the functionality with webapps.

Second, many software vendors don't support Linux at all.  This functionality also was replaced with webapps.

Thus, tracking down webapps to replace any and all functionality normally found on a desktop, became a priority.  That's how the seeds of the webapps on the Chromium desktop, albeit originally written in HTML and running on Firefox, were planted.

While running your front-end operating system entirely with web apps is a fundamental shift to the status quo of modern operating system architectures, I'm convinced the benefits far outweigh the costs.  As we live our lives, connected and online, few or no resources need to be stored on the same computer as the attached keyboard, and those which are stored don't need to be accessed by spinning a magnetic platter.