What I suspect Google is up to with Native Client
I had originally intended on spending a lot more time on this, but as ever perfection is the enemy of good enough, so will just cut to the chase and reiterate the main points I made last week. I’m finding it infuriating trying to get this out cohesively, so please feel free to flag stuff for more discussion. In particular I’m going to try ignoring speculation and “gut feelings”, or suggestions for a future design here[-1], there’s just too much to explain. The crux of what I was talking about centres around the apparent shifts that are likely to occur in the ‘user’ software space in the coming 2-5 years, driven by public evidence mainly from Mozilla, Google, and W3C, but also from acquisitions e.g. by Adobe[6]. Google quietly shipped an “ActiveX killer” by the name of Native Client[0,2] sometime in 2008. As of now it is enabled in Chrome for all users. This is a sandboxing technology that allows running untrusted native code directly on a user’s CPU with almost optimal virtualisation overhead (<1% on i386, ~7% on amd64 and ARM). Initially billed as a “research experiment”, the stated aim was to allow writing fast code in C that can augment a JavaScript application, e.g. for the renderer of a 3D browser based game.
