Native Client (NaCl) has been shipping with Google Chrome for a while now, but it wasn't enabled by default. It has just been enabled in the Beta channel which means it'll hit the stable channel in about 6 weeks or so.
For those that don't know, NaCl is a plugin that runs native code in the browser. For instance, C/C++ code compiled against NaCl will run sandboxed in the browser, and the Pepper library allows your program and the browser to communicate.
I have a bunch of little games I wrote in C that I'd like to port. Last I heard, NaCl had an SDL port, but most of my games are written with Allegro so I'm hoping someone ports that soon if they hadn't already.
Auditing a simple sandboxed VM's security is already hard enough, so the hell with it, why not allow native code to run and expose any and all hardware faults and privilege escalations to fucking browser code. Brilliant.
The main advantage of Web scripts is portability across different machines, but you lose it once you use native code. So what's the point of native code Web scripts? You get the worst of both worlds!
>>4
You can still have your web apps written in pure JavaScript and use NaCl to handle the bottle necks. Take for instance a photo editor written in JavaScript. Some of them will send the data over the network and process the photo server side. You could embed a binary written in C/NaCl to process the photo client-side and write a hook that will use that if the browser supports it or fall back on the old method if it doesn't.
The entire app doesn't have to be written it native code, but native code can be leveraged to resolve performance bottlenecks on systems that support it. This in combination with WebGL, which Chrome has had for a month or two and which speeds up graphic processing in the browser 1000 fold, could lead to some really killer browser-based games, which Google is really pushing for.
Although I really wish Intel (and AMD) would stop selling CPUs before they had all the errata dissolved.
Name:
Anonymous2011-08-12 15:55
fuck you cose i have no cloue about what u are talking
Name:
Anonymous2011-08-12 16:02
What about sodium chloride?
Name:
Anonymous2011-08-12 16:14
Seriously? This just opens up a whole can of worms, both in security and cross-browser/system compatibility problems. As if we didn't already have enough shit to deal with thanks to IE.
>>16
Why would anyone want extra Python in their browser? You can already run it (if you know what you're doing) and Python is kind of a shitty language imho
Name:
Anonymous2011-08-12 18:31
Native Client? Can someone tell me how C/C++ code compiled to VM byte-code running in a VM in a browser can be considered native, because I just don't see it?
It's the same as Google's "Native" SDK for Android... it's not actually native, running straight on the metal... it's just compiling your C/C++ to their VM byte code.
>>20
It's not byte-code and it's not running in a VM. It's an actual binary that Chrome pulls from the server and runs on your machine, and yes, you must compile a separate binary for each platform you wish to support.
>>20,23 http://code.google.com/games/technology-nacl.html Native Client is a sandboxing system. It runs code in a virtual environment where all OS calls are intercepted by the NaCl runtime. This has two benefits. First, it enhances security by preventing untrusted code from making dangerous use of the operating system. Second, because OS calls are virtualized, NaCl code is OS-independent. You can run the same binary executable on MacOS, Linux, and Windows.
But syscall virtualization by itself wouldn't be as secure as Javascript, because clever hackers can always find ways to exit the sandbox. NaCl's real contribution is a software verification system that scans each executable module before it runs. The verifier imposes a set of constraints on the program that prevent the code from exiting the sandbox. This security comes at a relatively small performance price, with NaCl code generally running at about 95% the speed of equivalent compiled code.
>>25 But syscall virtualization by itself wouldn't be as secure as Javascript, because clever hackers can always find ways to exit the sandbox. I don't see how, except if there's a security flaw in the kernel.
NaCl's real contribution is a software verification system that scans each executable module before it runs. The verifier imposes a set of constraints on the program that prevent the code from exiting the sandbox. This security comes at a relatively small performance price, with NaCl code generally running at about 95% the speed of equivalent compiled code. I suppose indirect jumps, indirect calls, and jumps or calls in the middle of an instruction are forbidden. Code making extensive use of callbacks is probably slowed down much more than 5% then, and can even be impossible to compile. I hope I'm wrong.
Name:
Anonymous2011-08-13 9:18
>>30
They'll find a way. If people can punch through VM's like Virtual PC and Virtualbox, they'll do it to this as well.