In the Clouds: Inventing Chromebook

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.

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?  Move the entire desktop operating system into RAM.  By moving the entire operating system into RAM, that immediately took off the table the largest performance bottlenecks in the operating system: File I/O.

Very few tasks that an operating system perform are CPU intensive or cause other major delays that can't be attributed to File I/O.  By running the operating system entirely in RAM, most such 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 code became 60% faster, and I could run non-indexed, recursive greps of the entire RAM resident file system in under 15 seconds.  Try doing that with a hard disk.

When discussing the RAM resident architecture of the original versions of Chromebook, nearly everyone expresses concerns about data loss.  In fact, data loss was not a problem for several reasons.  First, many tasks were performed as webapps, so as long as the webapps were well written, there was no possibility of data loss, there.  Second, I had configured my IDE to auto-save backups to a network drive, so even in the event of a system crash only a few seconds of work could be lost.  Third, some version occasionally synced backups to a local storage media.  Aside from that and boot loading, the operating system never accessed any local storage media aside from dynamic RAM. Ever.

Running a RAM resident 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, but hogging a few gigabytes of RAM is.  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 in RAM 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.