How is Google Native Client Faster Than -- Or As Safe As -- JVM or x86 VM?

When I saw Google's proposed native-code execution plug-in earlier this week, my initial reaction was: "Don't we already have those, and they're called exploits?"

I decided to mull it over a bit, and I still don't like it. While the idea of sandboxed native x86 execution based on real-time analysis of instruction sequences makes for a great Ph.D. thesis or 20%-time project, it sounds like an awfully large attack surface for questionable benefit.

Here's what I'd like to know from a practical nuts and bolts point-of-view: how many "compute-intensive" scenarios could not be implemented effectively using either (1) the Java VM or (2) a plug-in based on widely-available open-source machine virtualization, running a tiny Linux snapshot.

While the JVM falls short of native code in some places, it can be as fast -- or even faster -- in other cases (faster because the runtime behavior provides opportunities for on-the-fly optimization beyond what is known at compile time). Yes, there are issue with clients not all having the latest Java version -- but that seems a small issue compared with the operational issue of deploying a brand-new plug-in or browser (Chrome).

Another approach is to use a plug-in that runs a virtual machine, which in turn runs a small Linux (started from a static snapshot). User-mode code should run at approximately native speed in the VM, which should cover the pure computation cases. In a rare situation where someone wants to run an OLTP file-based db (which would behave badly in a VM environment) or get access to hardware-accelerated OpenGL facililties, specific well-defined services could be created on the host, which code could access via driver "ports" installed in the VM image.

These approaches to the security boundary -- Java VM and x86 VM -- are well-known, long-tested and based essentially on a white-list approach to allowing access to the physical host. While Google's idea is intriguing, it sounds as though it's based on black-listing (albeit with dynamic discovery rather than a static list) of code. I'm not yet convinced it's necessary or safe.

What's In Microsoft's "Strata"[?] Cloud OS

(Probably)

Just for fun, let's do a little educated speculation on Microsoft's "cloud os" initiative. It's not too hard to make some good guesses -- Microsoft's existing and unreleased products telegraph a lot about what they are likely assembling. For example, the semi-well-known "COOL" and Visual J++/WFC gave you most of what needed to know to imagine the real .Net platform.

There are lots of pieces out there -- certainly enough to comprise a pretty interesting cloud stack and application model.

Since Microsoft -- and platform vendors in general -- like to go all out, let's imagine this stack reaching from real hardware up through virtualized hardware up to application servers and then to client components and the end-user's browser or alternative on the other end.

Let's start in the middle of this stack and work our way out.

What would the "middle" look like? Well, what makes a hosted ASP.net account different from a cloud platform? Some answers: storage and bandwidth may not be elastic; clustering the app is neither automatic nor declarative, but requires programmatic and operational work; the database is typically a SQL Server instance (perhaps a mirrored failover cluster) with all of the usual capabilities and scaling constraints.

So imagine a hosted ASP.net account with a few changes that address these limitations.

First, swap in an alternative implementation of sessions, that supports clustering, proper caching, etc., with zero config. Add a lint-like tool to warn about code that isn't properly stateless. And an asynchronous worker service for any long-running, background, or scheduled tasks that could be "fudged" with threads or events in a controlled Windows Server environment, but won't work that way in the cloud.

Next, replace the datastore with something like ... SSDS, and a LINQ provider so that in many cases code won't need to be changed at all. The interesting thing about SSDS, of course, is that unlike other non-relational cloud datastores, Microsoft has said the roadmap will offer more relational capability (subject to constraints, no pun intended). So ASP.net apps that need real relational behavior might have an easier time moving to this new datastore.

So, without much new, we have a flavor of ASP.net that is more cloud-centric and less server-centric.

Now on the hardware and VM end of the stack, bear in mind also that -- to add value and sell the Server product, as well as to service enterprises which would like cloud architecture but need parts of the "cloud" to stay inside the firewall -- the whole enchilada is likely to be available as a service (or its own SKU) on Windows Server.

In fact, a number of Microsoft products related to modeling data centers, virtualization, and automated migration of services and machine images suggests that a key thrust of the "cloud os" might be that a customer can easily move services from individual servers up to a private cloud implementation and on to one (or more -- perhaps an opportunity for the hosting partners) public cloud data centers... provided they are coded to conform to the API.

ADO.Net Data Services (aka Astoria) already supports AtomPub, the format Microsoft is using or moving to for all of its Live services, so minimal wrappers (not to say minimal effort in the API design) could turn this into a platform API. A simple using directive brings in a File object and API that works with Skydrive instead of My Documents.

Last, look at the client end of things. Right now, we have ASP.net serving web pages, and we have web services for Silverlight clients. There is also a project (named "Volta", and which has just recently gone offline while a "new version" is in the works) aimed at dynamic tier splitting and retargeting apps in terms of the client runtime. Hmmm... Sounds like a critical part of the front end of the cloud os stack.

In order to provide a RIA experience via Silverlight (or even desktop experience for a cloud-os edition of office), promote the client os product by offering a best-of-breed experience on Windows clients, and at the same time offer a legitimate cross-platform web-browser-consumable app, a piece like Volta is critical, and makes complete sense.

Microsoft tends to hunt big game, and I doubt they are interested in a me-too web app environment. They really intend to offer a cloud os, allowing developers to code libraries and GUIs that are outside of the web paradigm. These bits can run as .Net on Windows ... as .Net in Silverlight on Mac or (one day) Linux ... and as Javascript apps in non-.Net-capable browsers.

The big question in my mind is timing -- how far along are they on the supportable, RTM version of this stuff. Whether this is relevant -- or even becomes a reality -- will depend on how fast they can get this out of beta.

It seems that when Microsoft is quite close to production with a platform they can grab enormous mindshare (recall the release of the .Net platform). If this is an alpha look, with no promised timeline, things are a lot more tenuous. If there is a 1.0 planned before mid 2009, this could make things interesting.

Ghost of Christmas Yet to Come: Alternative Futures for Windows

Sun's OpenSolaris demos and pleas ("put in on your laptop -- really!") last week got me thinking about the desktop OS, or more precisely the boot OS ...

Some folks have hypothesized that 'Windows 7' will be ultra-modular and may introduce a new API scheme while supporting the old ones via virtualization.

I think this is the right idea, but can be taken much further, with benefit to the entire industry/ecosystem.

Consider:

1. The desktop will remain critical, as long as NVidia and Intel keep loading cores and cache onto chips, while keeping the price low and the power consumption efficient. Unless/until mobile broadband gets faster, more reliable, higher penetration, and about a 90% price cut, the desktop (or laptop or palmtop) is where a lot of computing will happen.
2. Windows will remain vital for a majority of desktop users: businesses keep Windows to keep their legacy line-of-business apps running. Those workstations also run Office. Users want to run Office at home. There are also gamers who haven't migrated to consoles.
3. (and this is the fun part): Windows doesn't have to be that desktop, and that desktop doesn't have to be Windows. Breaking them apart properly can create more value Microsoft (in terms of equivalent or greater revenue, with lower costs), and opportunity for everyone else (Apple, Sun, Linux distros, device makers).

What I am basically proposing is that Windows be so extremely modularized that many (eventually most or even all) flavors of it run only in virtualization on top of ... well ... anything.

Having Windows be the Ring 0 (or -1) operating system is hard and expensive and in most cases no longer necessary. It also doesn't pay well. Making an operating system run well on every cheap piece of hardware, taking the blame for the blue screens caused by other folks' faulty drivers, and being the "buck stops here" guy for security and resource management is neither cheap nor easy.

So I say: ditch it!

Could this work? In most cases, yes.

Businesses don't need Windows per se. What they need is an operating system that is supportable and manageable and can run their legacy Windows apps without incurring a bunch of additional cost.

What would a minimal Win32 Lite OS look like? The XP Embedded system builder is all about figuring that out. The Wine, Mainsoft, and Mono folks also have pretty good data on which APIs are critical for which sorts of apps. I'm not suggesting running a port of Win32 (or .Net), just that those folks have real good familiarity with which APIs and services are critical for running a user's apps, and the dependency chains between them. I don't claim to have that info at my fingertips, but we know that an upper bound for client software is XP Pro. From there we can subtract a lot.

So businesses could be running Linux or OpenSolaris or Mac OS, and run a SKU of Win32Lite in VirtualBox. Microsoft wins, because they only deliver and debug against a small set of virtual hardware devices, and can charge around the same amount as they currently do for the license (on an annual amortized or subscription basis) and support. As long as they produce a great implementation and great APIs to develop against (they've got a big headstart for desktop apps), there's no reason they wouldn't keep selling licenses.

Some security issues are lessened, because the virtualization layer is senior to the VM. Similarly with deployment, monitoring, resource management, etc. And hardware has migrated (and continues to migrate) to the USB bus, which is supported via the VM.

What about consumers? The rise of web applications doesn't mean the desktop is irrelevant -- all the apps in Flash, Silverlight, and Java make that clear. But those are browser plug-ins, which don't rely on Windows being underneath them. Home users may well want the latest Microsoft Office 2007, so Wine isn't their solution ... they'll buy a different SKU of Win32Lite to run office and their handful of random non-Web apps... maybe some of the Adobe products.

For the few cases where performance is important (let's say a non-linear editing tool for hacking HD videos), a simple user-mode service on the underlying host can deal with big number crunching or disk-file-shuffling jobs in cooperation with the VM. Again, most legacy consumer gadgets don't need to care about the "real" OS, since they're on USB and they're proxied through to the VM. Most of them will play nice with other-OS class drivers (such as 'mass storage' or 'image acquisition') anyway, so users may not need Windows at all for them.

So who isn't covered by these basic configurations? Folks with real custom hardware (strange ISA or PCI cards and the like) and hardcore gamers.

I have a feeling the 'real custom hardware' will show up more in businesses, which can lean on Microsoft's 10-year-plus support lifecycle policy. Even in slow industries, that should provide enough time to at least plan a migration.

For gamers, well, there are at least 3 options for Microsoft, all of which can provide revenue:

1. Drive innovation in 3D acceleration under virtualization ... Fusion already supports DX9 Shader 2, and with Microsoft's contribution I'm sure the perf could get vaguely close to unmediated DX.
2. Encourage gamers to migrate to a console... not a loss for Microsoft if they can bulk up margins even a little on the XBox
3. Offer a DirectX-on-the-Metal version of Windows, to be run from a bootloader next to a 'productivity OS' ... and I'm thinking DX-on-the-Metal is not that dissimilar from XBox anyway.

And one more thing:

Sooner or later, if the must-boot-on-the-metal requirement has been gone from Windows, hardware changes will make it so that Windows no longer can boot on commodity metal.

The architecture shift will inevitably happen before some businesses are ready to make a switch (don't believe this? go look at the airlines). For some businesses, there may be expensive retro boards (just like there were Z80 boards for running CP/M in 65xx and x86 machines), but eventually we'll need to run Windows in a VM on top of some hardware emulation.

I don't think it's in the least unreasonable to expect emulated x86 hardware to run as fast at that point as real hardware does today. We'll call it MAME Enterprise Edition.