The iPad and the new GoogleOS

I like it.

Apple's insistence on using storage to differentiate pricing is an OK idea, but the price difference between models is hard to support.

Anyway, in my last post I dreamt of my ideal device. Now that the iPad has been seen by most, you could visualise my ideal device as an iPad that folds in half.

It, of course, needs a camera, needs to work as a phone and needs to run ChromeOS, but otherwise it is close.

Folded in half it would be about 7.5"x4.8" (190mm x 120mm), 1" (25mm) thick.

The Future

I think the PC has matured and is in decline. 

Netbooks have harmed the laptop market. Their low cost and high portability has meant that laptops and desktop have had to cut margins to sell. Microsoft too, has probably had to reduce margins to ensure their OS - old as it is - is the de-facto standard. I recently saw that Aldi advertised a 17" Core II Duo laptop with everything you could need for $900 AU. Even though it is many times better in almost every respect, the market wants laptops to be sub $1000 AU.

Where a big laptop fails is it's size. Consumers have their adequate 15" laptop or their 22" desktop and it still does the job just fine - even with Windows XP. They now want to be free to roam around their homes or around town with a take-anywhere Netbook.

They have their big-screen touch phones too. Great as a phone and as a media player but they are not too good at web browsing. So a market is born: a small screen web browser.

The Netbook was first and does the job by scaling down a laptop so that it is ultra portable. Apple thought better, and made a smaller device that still offered a 10" screen that could be used in portrait or landscape. And they added 3G for that always-on experience.

What the iPhone, Androids and Nokia's have shown, is that the new killer-app is an app store. A place to buy your software, be it office applications, games, music, video, books or just cool toys.

The OS is irrelevant.

The design is far more important than the hardware. Low powered computers are fast enough - adequate. You don't need to worry about storage, frame rates, resolution and interfaces since they have everything that you typically need. Now it is more important to consider looks, weight, portability, battery life and Apps.

What Apple and Google have also done is to reduce the risk of malware by selecting the ARM microprocessor and a more secure-by-design operating system. ARM processors don't allow some of the techniques used to cause a PC to execute foreign code, and UNIX and Linux have demonstrated that they are resistant to malware.

Apps too, are more likely to be web apps - based on HTML and JavaScript. These can be easily sandboxed to protect the OS and other core applications and services. Google also has their Native Client which allows native compiled code to run safely and securely on a PC or ARM machine.

A new OS will enter the scene.

Perhaps a few. Windows will decline as more devices are sold with Android, Linux and OS-X. I don't think Symbian will survive either.

If the OS is irrelevant then it will shrink and become a specific purpose, custom OS for the particular device. If all the applications run in a browser then applications will no longer depend on OS services. Instead they will mostly depend on browser services - the browser is the new OS and it includes the secure, windowing/graphics environment for games, music, videos, office applications and browsing.

Recently Google released a new programming language called Go. To me, it seems to be a descendant of a language designed at Bell Labs called Newsqueak. Rob Pike developed Newsqueak and is also developing Go. Ken Thompson, who also worked at Bell Labs, is also part of the Go development effort at Google. Both Newsqueak and Go are used to do systems programming - a language to build or experiment with operating systems. Why would Google want that - they use Linux don't they?

Ken Thompson and Rob Pike both worked on Plan 9 and it's descendent, Inferno, which was open-sourced in 2005.

I think Google is looking to use Go to compile a descendant of Inferno to become the base OS for Google and Android. Why? Go makes concurrent programming easy, and future servers and appliances are going to have lots of CPUs and GPUs.

Background

This is a video (2007) of Rob Pike talking about Newsqueak, Plan-9 and a toy window system.

Google's ChromeOS

In case you missed the news, Google has announced that it will build a secure operating system for, well, any device: desktops, netbooks, tablets, phones.

Basically, it is

"Google Chrome running within a new windowing system on top of a Linux kernel"

and for security they are

"completely redesigning the underlying security architecture of the OS so that users don't have to deal with viruses, malware and security updates."

As you might imagine, this has stirred quite some commentary from magazines and bloggers: gizmodo, techcrunch and Wikipedia always has something to offer.

But I think most have missed the other key ingredients - everyone but ToxProX at least.

Google is not just working on a new OS. It is also working on at least two other related projects: Native Client and O3D.

O3D

I'll cover O3D first since I don't have much to write. The web site suggest that this stands for 'Open web standard for 3D graphics'.

It is a browser plugin that allows web developers to add 3D graphics to their application. I think the short video demo describes it best.

Basically, GPU accelerated 3D graphics for your browser.

Native Client

Native Client also known as NaCl (but never as Salt) is a way to run 'normal' programs safely.

A normal program is a word processor; a game; a photo editor; a VoIP client; a movie maker; or a 3D earth browser. Most of the software you use are normal programs and they are usually compiled to machine code for your CPU type and for your operating system.

What is Native?

A native program runs on the CPU and not in another program that decodes the instructions and then performs the operation.

That's not very clear so I will try a metaphor:

It is like reading a book. A book written in English is easily read by someone who understands or natively speaks English. Give them a book in German, and a German-English dictionary, and they could also read the book - but much slower.

For each word that they have not seen before, they would have to look up the word in the German-English dictionary, read the English meaning and then decode the meaning of the German sentence. They would have to do this for every sentence.

Initially they would be slow, but as their German vocabulary grows their sentence translation speed would improve because they are optimising the process of looking up the English meaning of a German word by memorizing it. But they will never be as fast as a native speaker since they are always translating.

Many programs written in Java, JavaScript, Python, Ruby, C#, lisp, perl and flash work this way. The program is written in a non-native language and another piece of software does the translation. Fast CPUs and cleaver optimizing techniques allow them to run quickly, but a native program that did the same thing would run at least twice as fast, but more often at least 10 times faster.

(A side note here is that CPUs are not getting that much faster any more which is why all language developers are working on ways to make their interpreter work faster or getting their compiler to generate faster and often smaller code.)

So, why aren't all programs written to run natively? The answer is portability. Interpreted programs can generally run on any operating system and on any CPU. Speed is traded for portability. It also means that we often loose the benefits of hardware accelerated graphics.

Native Client CPU Support

Most home and business computers use just 2 types of CPUs: x86-based and ARM based.

Intel, AMD and some other manufacturers make x86 CPUs which are generally used in servers, desktops and more recently netbook computers.

ARM licenses their designs to many manufacturers which integrate various modules and produce very low-powered chips for use in mobile devices such as ipods and mobile phones.

NaCl is being built for these two CPU architectures. This doesn't prevent future support for other CPUs like IBM's PowerPC or Sun's Sparc or Sony's Cell processor.

Native Client Security

Back to Native Client. This could be part of web 3.0: All applications loaded from the web, running securely in the browser at native application speeds? Maybe web 2.5?

NaCl tackled security in a new way. The programs are run in a sandbox. The sandbox disassembles the program, enforces memory access rules, rejects code that doesn't obey strict rules to prevent it jumping out of the sandbox, and only allows interaction with the real world through the limited API back to the browser or perhaps the ChromeOS.

This solution has some interesting benefits:

• There is no need to enforce a trusted development chain so developers don't need a special, trusted compiler and developer certificate. Signed applications are unnecessary.
  

• Buggy code can not crash the OS and nor can it do any damage since it is running in a sandbox which does not have access to hardware or the OS.

• Malware can't make use of bugs to gain privileged access to the OS and the sandbox ensures all code stays in the sand. So, malware can not spread itself, access any file on the OS or leave the sandbox (or is it a salt box?). Could this be the end of Malware as we know it? I think Google thinks so.
  

Write Once, Run Anywhere

An unrealized dream of software architects is to write a program once, and to be able to run it on anything. Native Client makes this a reality. It will be a new program format that allows an application to run in any web browser (with a NaCL plugin I guess) on any operating system and on any hardware.

It also means that software will no longer need to be installed.

Enter Google Gears

Google Gears allows you to run your Google applications while off-line. It provides a database for local caching of data, HTML, images, JavaScript and perhaps NaCl programs as well.

Once you are back on the net, your locally generated data will synchronise with your on-line data.

Say someone creates a game for Native Client. You would agree to the license (if any), make any payment and run the game. The game would be cached locally so you won't need to download it each time you want to play, and this cache will allow you to use it when your computer is not connected to the web.

Now if the developer fixes a bug, or adds a new feature, the browser will check to see if the cached version is up-to-date. If not, it will automatically download and cache the latest version.

If this is how it might work, Google have just disrupted the whole universe of content distribution. There is no need for software installation. No need for update services. No need for fancy package management like Debian's APT. It will be like a universal version of iPhone applications.

So you can look forward to Google Earth, Picasa and Google Office applications all running from the web without having to install them and keep them up-to-date.

So, if programs run fast, run anywhere, are secure and don't crash the browser or OS, why wouldn't you use it for other parts of an operating system? Did I mention that NaCl also supports POSIX threading and IO? Now it just needs a hardware layer, device drivers and a GUI.

We already know that ChromeOS will be based on Linux so just the GUI remains to be built. Or does it?

Chrome is the GUI

What if Chrome (the browser) IS the GUI? It already has a window manager - we call them tabs. They can be pulled-out of the browser, minimised and resized - just like a window manager.

It already has a scripting language - JavaScript, and Chrome's V8 engine is fast.

It already supports HTML5 which covers-off video, audio and virtually everything that Adobe's Flash does.

And, it is getting hardware accelerated 3D graphics in the form of O3D.

A version of the Chrome browser was released for the Chrome OS recently. It was a deb package so it is designed for, most probably, Ubuntu. It is not much different from the standard Chrome browser, but it does have a clock display, battery indicator and a hint of network settings.

My guess - there is no window manager apart from the Chrome browser.

In Summary

Native Client promises much:

• Programs will run fast.

• Any compiler can be modified to produce NaCl code.

• The compiler will make a program that will run on ARM and x86 (for now) CPUs.

• The program will run in a sandbox that restricts what it can do.

• Buggy programs can do no damage.

• Malicious programs like viruses and worms can do no damage, nor can they spread or modify files on your OS.

• May be enabling technology for ChromeOS