OSNews:

OSNews: http://www.osnews.com/story/20629/Google_Releases_Native_Client_Runs_Code_Natively_in_Browser Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Mon, 09 Nov 2009 02:05:36 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com Hmm... http://osnews.com/thread?339813 http://osnews.com/thread?339813 Native Client == NaCl == Sodium Chloride == table salt

Just a coincidence?

Or are they subtly trying to hint that someday this technology should be ubiquitous and bring extra flavor to every website? Wed, 10 Dec 2008 20:10:00 GMT donotreply@osnews.com (mmebane) Comments Good luck with securing the x86 instruction set http://osnews.com/thread?339814 http://osnews.com/thread?339814 .. not sure it will happen though.

I for one will be _VERY_ hesitant to run native code from some website.

Actually I might not even install the plugin ;P Wed, 10 Dec 2008 20:10:00 GMT donotreply@osnews.com (kragil) Comments RE: Good luck with securing the x86 instruction set http://osnews.com/thread?339815 http://osnews.com/thread?339815

I for one will be _VERY_ hesitant to run native code from some website.

Agreed. It's one thing to provide a sandbox for scripting code that requires an interpreter. It's another matter entirely to sandbox code that's running natively on the CPU. Without knowing more about the security they'd be putting in place, I'm not at all comfortable with this idea. Wed, 10 Dec 2008 20:23:00 GMT donotreply@osnews.com (Delgarde) Comments But why http://osnews.com/thread?339816 http://osnews.com/thread?339816 But why, Google, why? Why do we need to run x86 binaries in a browser which is itself an x86 binary? Can't we like have normal secure web standars and instead dive further into obscurity and incompatibility? Wed, 10 Dec 2008 20:25:00 GMT donotreply@osnews.com (Buck) Comments RE: Good luck with securing the x86 instruction set http://osnews.com/thread?339817 http://osnews.com/thread?339817 I'm not even sure what the advantages of running native code are supposed to be. Poor implementations of non-JIT Java with horrid support for UIs back during the heyday of Java "applets" combined with more years of poor implementations of non-JIT javascript have given portable runtimes (and the letters 'j', 'a', and 'v') a bad name. Java is really only a little clunky these days, and Javascript engines are getting ready to not suck. We're finally mostly rid of the rid of the ActiveX terror. This is not the time to be pushing native code. It's finally time to start pushing client-side Java and Javascript.

Then again, the guys at Google are a lot smarter than I am. So there must be some uber-rarified reason for doing this.Edited 2008-12-10 20:41 UTC Wed, 10 Dec 2008 20:36:00 GMT donotreply@osnews.com (sbergman27) Comments hmm... http://osnews.com/thread?339818 http://osnews.com/thread?339818 maybe i am missing hte bigger picture, but does anyone else think that google's time could have been btter spent on something else? Wed, 10 Dec 2008 20:42:00 GMT donotreply@osnews.com (poundsmack) Comments RE: Hmm... http://osnews.com/thread?339819 http://osnews.com/thread?339819 My first thought too. I assume there is no connection other than the fact they probably think it's funny to call it NaCl and let just the few people "get it." Wed, 10 Dec 2008 20:46:00 GMT donotreply@osnews.com (Adam S) Comments RE[2]: Good luck with securing the x86 instruction set http://osnews.com/thread?339821 http://osnews.com/thread?339821 Agreed. Pushing and optimizing Java might be the better option IMHO.

Secretly I am hoping that open source and open standard will break the dominance of X86. It would be really nice to have a fast ARM Netbook in 2009 that can run nearly everything for a whole working day (8 to 10 hours).

100% working open source flash is the only thing I still really need.

And I don't think Google is smarter than I am

(Lively anyone?) Wed, 10 Dec 2008 21:11:00 GMT donotreply@osnews.com (kragil) Comments RE: But why http://osnews.com/thread?339822 http://osnews.com/thread?339822

But why, Google, why? Why do we need to run x86 binaries in a browser which is itself an x86 binary? Can't we like have normal secure web standars and instead dive further into obscurity and incompatibility?

I think they want to compete directly with other managed environments [.net and Java] and their "bytecodes" are very similar to the x86 opcodes [I say "very similar", should I say "identical"?]. In this way, they can create a JIT compiler in a simpler way and they get normal x86 binaries running with no modification [or simple modifications] in their "vm".

Nice approach I think, though I see the possibilities surpass the web and the webbrowsing and invade the virtualization and process isolation arena.Edited 2008-12-10 21:16 UTC Wed, 10 Dec 2008 21:14:00 GMT donotreply@osnews.com (ebasconp) Comments RE[2]: Good luck with securing the x86 instruction set http://osnews.com/thread?339823 http://osnews.com/thread?339823

I'm not even sure what the advantages of running native code are supposed to be. Poor implementations of non-JIT Java [...] combined with more years of poor implementations of non-JIT javascript have given portable runtimes a bad name.

The problem with "JIT" is that the results are simply thrown away after use. A much better approach would be "JITAR" (Just in Time And Retain), which would then amortize the translation of executable code across multiple invocations. Combined with efficient fine-grained dynamic linkin, a mechanism for finding and using common libraries (not necessarily maintained by a single source), and reliable version checking -- all to reduce the actual amount of compilation done across applications -- it could be extremely efficient.

Of course, given its relative ubiquity, x86 (or a reasonable subset) could be used as the intermediate language to even further reduce compilation for common cases. Wed, 10 Dec 2008 21:15:00 GMT donotreply@osnews.com (james_parker) Comments RE[2]: Good luck with securing the x86 instruction set http://osnews.com/thread?339824 http://osnews.com/thread?339824 Well, we know the guys at Google know how fast javascript can run. So either they've found it is too slow for something they want to do (what the heck would that be?) or this is just an experimental project with no major application in mind. Wed, 10 Dec 2008 21:20:00 GMT donotreply@osnews.com (Michael) Comments Why native x86 http://osnews.com/thread?339825 http://osnews.com/thread?339825 Seems a bit silly to build this with x86 in mind, especially since google wants have a piece of the action on the mobile market with Android. And I don't see any mobile x86 devices appearing any time soon... Wed, 10 Dec 2008 21:24:00 GMT donotreply@osnews.com (error32) Comments RE: hmm... http://osnews.com/thread?339826 http://osnews.com/thread?339826 Maybe. But then again, a lot of major advancements in technology have come from companies investing in research that seems of questionable importance to their main business plan.

Xerox, anyone? Wed, 10 Dec 2008 21:37:00 GMT donotreply@osnews.com (rexstuff) Comments Comment by TQH ! http://osnews.com/thread?339828 http://osnews.com/thread?339828 So, does Android compile on x86? Wed, 10 Dec 2008 21:43:00 GMT donotreply@osnews.com (TQH !) Comments Good http://osnews.com/thread?339829 http://osnews.com/thread?339829 I was just looking to code a website! (www.muslimnur.com) Wed, 10 Dec 2008 21:54:00 GMT donotreply@osnews.com (A.O.K.) Comments WTF http://osnews.com/thread?339830 http://osnews.com/thread?339830 This must be one of the most backwards projects that Google has done. This is totally a step backward, not forward. There is no future for native code on the web.

Let's look at their example:

For example, imagine that you run a photo-sharing website and want to let your users touch up their photos without leaving your site. Today, you could provide this feature using a combination of JavaScript and server side processing. This approach, however, would cause huge amounts of image data to be transferred between browser and the server, leading to an experience that would probably be painfully slow for users who just want to make a few simple changes. With the ability to seamlessly run native code on the user's machine, you could instead perform the actual image processing on the desktop CPU, resulting in a much more responsive application by minimizing data transfer and latency.

Well, if you code your app poorly, then yes you will have tons of latency and data transfer back and forth. However, someone who knows what they're doing would do all the processing on the client-side anyway, with a rich client-side JavaScript framework like SproutCore. So the argument for "increased latency and bandwidth use" is irrelevant.

The only real argument is performance. But JavaScript engines (V8, SquirrelFish, TraceMonkey, etc) are becoming insanely fast. Sure, perhaps not quite as fast as running native code, but close.

And with native code the runtime has to do extra work like verifying the binaries which has an additional overhead. Not to mention the incompatibility between different architectures (I'd like to see that X86 code running on an iphone... and if it does using some kind of VM, to compare its performance to optimized JavaScript running on V8 or SquirrelFish), and the additional burden for the developer.

This is just yuck.Edited 2008-12-10 22:13 UTC Wed, 10 Dec 2008 22:10:00 GMT donotreply@osnews.com (Myrd) Comments RE: Hmm... http://osnews.com/thread?339831 http://osnews.com/thread?339831

Native Client == NaCl == Sodium Chloride == table salt

Just a coincidence?

Or are they subtly trying to hint that someday this technology should be ubiquitous and bring extra flavor to every website?

And with this line of cryptogram the software will eventually stress out our systems and force us to get check ups and change our diets. Wed, 10 Dec 2008 22:12:00 GMT donotreply@osnews.com (tyrione) Comments RE: Hmm... http://osnews.com/thread?339832 http://osnews.com/thread?339832 So Native Client raises our blood pressure if used too much? Wed, 10 Dec 2008 22:15:00 GMT donotreply@osnews.com (Kokopelli) Comments RE[2]: Hmm... http://osnews.com/thread?339833 http://osnews.com/thread?339833

And with this line of cryptogram the software will eventually stress out our systems and force us to get check ups and change our diets.

Only a percentage of people are classified as "sodium sensitive". But none of us can do without salt entirely. Think about it:

http://tinyurl.com/5b7879

http://tinyurl.com/6n5jvnEdited 2008-12-10 22:22 UTC Wed, 10 Dec 2008 22:17:00 GMT donotreply@osnews.com (sbergman27) Comments It's not secure http://osnews.com/thread?339834 http://osnews.com/thread?339834 Correction to the OSNews summary: Google does not claim that Native Client is actually secure *at all*. In fact, they released it early as open source so it can even CLOSE to have a chance to be secure.

And as for Native Client itself, I think this idea is pretty ridiculous considering the gap between unmanaged and managed performance has only gotten considerably smaller over the last few years. Then there's the fact that developers would need to deploy multiple Native Client executables to support anything except stock PCs, and the fact that the performance gains of such a platform over Java, .NET/Silverlight, or Flash-based RIAs will not only be negligible, but it will continue to shrink as those systems gain more runtime performance enhancements. I just can't imagine a world where this would actually be beneficial to a normal web developer (although clearly this could be useful in medical and other latency-intensive/precise software).

Interesting project though and I'm glad they open sourced it right off. Wed, 10 Dec 2008 22:18:00 GMT donotreply@osnews.com (fury) Comments RE[2]: Good luck with securing the x86 instruction set http://osnews.com/thread?339839 http://osnews.com/thread?339839

So there must be some uber-rarified reason for doing this.

Rewriting C code in Java is expensive. Wed, 10 Dec 2008 22:46:00 GMT donotreply@osnews.com (Wes Felter) Comments ActiveX http://osnews.com/thread?339845 http://osnews.com/thread?339845 Yay, the ActiveX it's cool for everyone to play with?! Wed, 10 Dec 2008 23:10:00 GMT donotreply@osnews.com (memson) Comments RE[3]: Good luck with securing the x86 instruction set http://osnews.com/thread?339846 http://osnews.com/thread?339846 ...they just want to bring more Quake to the world! Wed, 10 Dec 2008 23:10:00 GMT donotreply@osnews.com (JrezIN) Comments RE: WTF http://osnews.com/thread?339847 http://osnews.com/thread?339847

The only real argument is performance. But JavaScript engines (V8, SquirrelFish, TraceMonkey, etc) are becoming insanely fast. Sure, perhaps not quite as fast as running native code, but close.

I think that's a bit of an exaggeration. The javascript engines are certainly becoming a lot faster, and for most purposes, are fast enough. But to say they're close to native speed is exaggerating more than a little. For heavy computation work, it's hard to beat true native code. Wed, 10 Dec 2008 23:13:00 GMT donotreply@osnews.com (Delgarde) Comments RE: It's not secure http://osnews.com/thread?339848 http://osnews.com/thread?339848 don't forget it can be used not only on the web, but on the client-side too... plugins can use NaCl and solve some problems that plugins have in these days... Wed, 10 Dec 2008 23:15:00 GMT donotreply@osnews.com (JrezIN) Comments RE: WTF http://osnews.com/thread?339849 http://osnews.com/thread?339849

This must be one of the most backwards projects that Google has done. This is totally a step backward, not forward. There is no future for native code on the web.

I violently disagree. Try writing a full-featured postscript document viewer (i.e. Acrobat) or a timeline based vector/rastor graphics runtime with scripting support (i.e. flash) in javascript or java and see what the uptake on that would be. You cant do everything in Java - sometimes performance matters. I think people are missing the point because of the whole "it runs quake!" angle...

1. This is potentially a _safe_ and browser-neutral alternative for activeX and netscape plugins.
2. Neither of those 2 technologies is remotely secure or trustworthy - this promises to be.
3. If (I stress if) this can be made provably secure ,i.e. the runtime can guarantee that code running within it cannot perform certain operations this could be very very useful indeed.

I would argue that the real benefit of this is not so much to create a new development path for web applications, it is to replace an already existing, heavily utilized, but horribly broken one. Just because we are all used to the fact that plugins are plain ass insecure and untrustworthy doesnt mean we should accept it as a fact of life.

As things stand now, both acrobat and flash do massive amounts of system configuration, registry changes, file-type associations, writing executable images and libraries all over the place, etc. They do this simply because they can. A runtime that would permit these types of applications to be developed, but would inherently limit their ability to affect the underlying operating system and filesystem would imho be a very good thing. Wed, 10 Dec 2008 23:16:00 GMT donotreply@osnews.com (galvanash) Comments RE[3]: Good luck with securing the x86 instruction set http://osnews.com/thread?339850 http://osnews.com/thread?339850

Rewriting C code in Java is expensive.

It is, but that's relevant only if existing unmodified C code will run on this new platform. There's a question of libraries (both static and shared), of binary formats, of all sorts of things like that. If my code calls printf, for example, where will it find the function implementation, and how? The story doesn't answer any of those questions. Wed, 10 Dec 2008 23:18:00 GMT donotreply@osnews.com (Delgarde) Comments RE: Hmm... http://osnews.com/thread?339851 http://osnews.com/thread?339851 I hope not. Otherwise, Mayor Nannystate Bloomberg would ban its use in NYC. Wed, 10 Dec 2008 23:27:00 GMT donotreply@osnews.com (ari-free) Comments RE[4]: Good luck with securing the x86 instruction set http://osnews.com/thread?339853 http://osnews.com/thread?339853

...they just want to bring more Quake to the world!

Back in the day, I loved Quake 1. I wasn't a gamer. Not at all. But I downloaded the demo to my W95 box and played it. And I was completely hooked. We didn't call it Quake 1 back then. We just called it "Quake" because it was the only one. The demo shows E1M3 (episode 1, map 3). And that is interesting. Because I had the most notable dream about it some years ago. Years after Q1, or even Q2 was considered even remotely current.

I was on that very level. I just sort of found myself there. Except it wasn't a game. It was real. No monsters were present. No one at all, in fact. It was completely silent. It was like a Disneyland recreation but without the cars and without the other people. I walked from the cave, where you start out, into the hallway shown in the screenshot. (It's the first appearance of the grenade launcher.) The Ogre wasn't there, though. I walked around for a while, and was just amazed that I was really able to view what I was considering to be some sort of recreation even in the dream. The architecture was awesome, as Quake 1 architecture usually was. Then I guess I moved on to another dream or woke up. But to this day, I'm glad for the experience.Edited 2008-12-10 23:37 UTC Wed, 10 Dec 2008 23:35:00 GMT donotreply@osnews.com (sbergman27) Comments Not many ActiveX analogies... http://osnews.com/thread?339855 http://osnews.com/thread?339855 Not many ActiveX analogies, apart from the fact that they run native code, of course. ActiveX is far more complex than NC could ever be.

But I doubt that Native Client can actually run native code because that would be highly risky, even when removing "dangerous instructions". To be secure, NC should be sandboxed and thus run inside a VM. If it runs inside a VM, NC basically is like Java applets, Flash or Silverlight. So Google created its own version of those frameworks, something which was highly probable in the past and now it's a reality.

If it doesn't compile into bytecode and it actually compiles to native code, it will be highly difficult to secure, even when stripping out dangerous code during compilation.

Whatever it is, as I stated in past, this is a confirmation from Google that Javascript+HTML model is not suitable for complex Web-based application. This is a *direct* confirmation that Flash/Silverlight/Java path is the right one. As it was expected ;-) Thu, 11 Dec 2008 00:12:00 GMT donotreply@osnews.com (TBPrince) Comments RE[3]: Hmm... http://osnews.com/thread?339857 http://osnews.com/thread?339857

"And with this line of cryptogram the software will eventually stress out our systems and force us to get check ups and change our diets.

Only a percentage of people are classified as "sodium sensitive". But none of us can do without salt entirely. Think about it:

http://tinyurl.com/5b7879

http://tinyurl.com/6n5jvn "

Really? Duh. If you take my post seriously then you miss the point of it. Thu, 11 Dec 2008 00:22:00 GMT donotreply@osnews.com (tyrione) Comments RE[3]: Good luck with securing the x86 instruction set http://osnews.com/thread?339858 http://osnews.com/thread?339858

"So there must be some uber-rarified reason for doing this.

Rewriting C code in Java is expensive. "

Expensive? Relative to what? Google's expenses on marketing vaporware costs far more than that cost. Thu, 11 Dec 2008 00:24:00 GMT donotreply@osnews.com (tyrione) Comments Photoshop in the browser? http://osnews.com/thread?339874 http://osnews.com/thread?339874 I think Google is readying for Photoshop in the browser, or maybe it is time for games. Thu, 11 Dec 2008 02:13:00 GMT donotreply@osnews.com (skypilot) Comments RE: Not many ActiveX analogies... http://osnews.com/thread?339875 http://osnews.com/thread?339875 why do do we need all those complex web applications anyway, sure they are convenient but isn't that stretching the initial goal of the web.
Plus I don't think plugins/applets is the way to go, as it cut a significant share of the user (mobile, alternative OS,....) from the actual content. Thu, 11 Dec 2008 02:24:00 GMT donotreply@osnews.com (dvhh) Comments ARM? Why no one has mention it. http://osnews.com/thread?339876 http://osnews.com/thread?339876 Before anything else, Security, or usefulness,
Does NaCI runs on anything other then x86 is the most important question. Or will be it possible to run on other processors.

If it is x86 only then i will say it is a SERIOUS step backwards.

I could see the usefulness of Native Code. But being x86 only seriously hurt. Thu, 11 Dec 2008 02:39:00 GMT donotreply@osnews.com (iwod) Comments RE: Not many ActiveX analogies... http://osnews.com/thread?339895 http://osnews.com/thread?339895 I'm inclined to agree. I've written AJAX apps and while they work well, the overhead is ridiculous even with other people writing the frameworks. Web apps are exciting until you see what it takes to make them work. Thu, 11 Dec 2008 04:53:00 GMT donotreply@osnews.com (snozzberry) Comments