Native Client: A Technology for Running Native Code on the Web | Hacker News Reader

Native Client: A Technology for Running Native Code on the Web

google-code-updates.blogspot.com

32 pointsbdfh4227 comments

A coworker: "Yay! Google is re-imlementing ActiveX!"

I hope it's a bit more stable than that!

NaCl is very stable. Just don't get it wet.

Your coworker doesn't really understand ActiveX; ActiveX controls execute unchecked native x86 code with full access to the system call table. NaCL falls somewhere in between VMWare and the Java Bytecode Verifier.

I like your abbreviation for it, but that's not an official name, right? Are you just hoping it will catch on?

I'll join you in calling it NaCl.

NaCl is the chemical name for salt, right? :P

They used it in the paper.

Yahoo! has already released a very similar "BrowserPlus" ... http://browserplus.yahoo.com/

They don't look that similar, since BrowserPlus doesn't appear to run arbitrary untrusted native code.

NaCL doesn't run "arbitrary" native code; it runs a strictly controlled subset of x86, with all bblock edges verified, in a per-process environment that uses segment access controls to prevent code from overwriting code, and without access to the full system call table. It is basically a faster version of the Java applet sandbox.

Maybe "arbitrary" wasn't the right word; my point is that it looks like BrowserPlus lets you run a small selection of native things approved by Yahoo, while NaCl lets you run whatever you want in a sandbox. Most of the restrictions of NaCl are inconsequential since they only block things that well-behaved code doesn't do anyway.

I believe BrowserPlus will allow 3rd party plugins, though I'm not sure if they will require Yahoo approval.

Also, there's already a "RubyInterpreter" plugin, though assuming it's sandboxed there's not much advantage over JavaScript, unless you prefer Ruby (JS appears to be faster than Ruby, in most cases: http://shootout.alioth.debian.org/debian/benchmark.php?test=...)

It's game over for Microsoft. The OS will become even more irrelvant. Adobe should be really worried too - they both just might disappear into a silvery lit air :)

Let's just hope Google doesn't mess this opportunity up. This is the silver bullet and they get to shoot it only once and they must not miss. No beta tags.

I wouldn't say game over just yet, there is still much to be determined in this space and with this recent technology.

I first thought the same thing also, but looking at it more objectively we have to see how users adopt native client.

It was game over long before NaCL, which is why I'm not bullish on this particular browser plugin: very, very few information problems people need solved require native code, and those few problems are already pretty well represented. If this was a killer problem, the JVM applet plugin would have evolved faster.

This could be a huge boon to casual multiplayer gaming. You may be able to implement games that are as fast as desktop clients, but which require zero installation. (Once the plugin is installed the first time, of course.)

The same benefits would also be a huge boon to browser office apps.

Actually, this is the architecture that should be used to distribute plugins, period.

You say that as if you knew it to be true. But we don't really even know if it's going to work; it's a new x86 verification scheme, and if it's somehow broken, it won't work at all.

I see how a near-native-performance plugin interface is valuable, but it's still just not clear to me why, if this was that important, it wouldn't be in the Java applet plugin's bailiwick. The same CS disciplines that make NaCL possible can also drastically accelerate the JVM.

It's also not totally clear that, when NaCL is actually fielded, the end user experience will be that much better than the applet plugin. NaCL forks off a seperate process and sets up a special runtime with a sidecar debug monitor; once it's up in steady state, I'm sure it's faster than Java, but the big issue with Java is setup time.

Your referents are a bit vague: "You say that as if you knew it to be true."

Are you referring to my first paragraph, where I say could?

Are you referring to my second, where I say would? (Would if it works like it's supposed to.)

As for my last paragraph, this is an opinion based on personal experience with the "security" of ActiveX and other plugins I've run into in my professional life. Web plugins and other downloaded executables should be sandboxed for security.

Also, the fact that it's not a virtual machine, but virtualized machine code will help with setup: the X86 ISA seems to change much less often than the JRE.

When I said "that", I think I meant, "all of it". ;)

ActiveX vs. NaCL is a false comparison, obviously. You can't do worse than ActiveX, and nobody promotes it.

I don't understand your last paragraph; setup time isn't going to be based on the X86 ISA, but rather the time it takes to fork a process, monitor it in a debugger, set up the system call interface, and then do whatever UI goop NaCL wants to do to give native code a window context. It could be faster than the Java applet plugin. It could be slower. And applets could get faster.

So your "that" referent consisted of two hypothetical parts and a 3rd statement that you agree is trivially true.

I meant setup from a user standpoint. I suspect that once such sandbox software was stable, updates would be less frequent than updates to the Java plugin. You meant setup time in terms of getting code JITed and actual execution.

History will judge this to be our day's version of VBA.

Could you run a Python interpreter in this, or Perl?

Yes. Of course, you can do that in Javascript, too.

Better yet, you can run a JavaScript interpreter in there. Firefox, even.

It seems like NaCl should be part of Gears, no?

I guess metaprogramming is out of the question.

Not necessarily, although you won't be doing any JIT.

Reply on news.ycombinator.com