Google Native Client 0.5 : released with stable ABI

http://code.google.com/intl/el-GR/chrome/nativeclient/docs/releasenotes.html

by Rexxar • 15 years ago

66 18 15 years ago

code.google.com

morganpyne4• 15 years ago

Does anybody here have experience using this? It looks like it could potentially solve an issue for me bridging access to USB and TCP-accessible devices from a cross-platform browser-based app, while giving a relatively easy way to get the software installed on them. On the other hand, will this turn out to be the DirectX of the future (ugh). Would love to hear some personal anecdotes from someone who was tried it out.

wmf2• 15 years ago

NaCl can perform the same I/O that JavaScript can, so it may not do what you want.

morganpyne4• 15 years ago

Thanks for the reply. If it's limited to what JS can do it certainly won't do what I need. Also just noticed I wrote "DirectX" instead of "ActiveX" in my previous post, oops.

majmun• 15 years ago

this is what is missing in all modern browsers, browser is envisioned from start as a client and therefore not able to access such things. But i agree there sholud be browser with JS and all that with capabilities of server behaviour. maybe next gen of browsers will have that. allthou it could brake the concept of thin clients.

chc• 15 years ago

NaCl seems like such a dead end, I can't understand why work is going into this instead of PNaCl.

morganpyne4• 15 years ago

Could you explain this a little more? I have no real knowledge of either and would be curious to hear your opinion as to which one may have a future and why.

forgotusername2• 15 years ago

The basic complaint is that NaCl is architecturally tied to 32bit x86. It relies on segmentation (bounds) checking that no longer exists on amd64, and perhaps more damningly, it's tied to the Intel instruction set altogether.

PNaCl is basically the same idea but built on top of LLVM's bitcode format (sortof a portable "high level assembly" representation of a program).

Personally except for the segmentation issue, I don't see bitcode as particularly compelling over x86, since the latter is already ubiquitous, and the other major issue with x86 that'd prevent efficient use on other platforms, that of instruction alignment, is already expressly prohibited in NaCl (in other words it should be easily possible to statically translate an x86 NaCl executable to run on ARM or similar, without all the overhead of runtime translation e.g. VMware). I'm guessing at least some of this kind of translation is already done even on amd64 in order to support bounds checking from software.

Edit: disclaimer: I've never actually used it, just found it intensely interesting when it was first released. These days I tend to think of it as just another Google land-grab involving a non-portable API that backs onto some "trusted" service with only a single provider at present (kinda like App Engine). From reading the Chromium roadmap (they someday hope Chromium will itself mostly run underneath NaCl), seems that's very much what they want it to be in the long term.

wmf2• 15 years ago

Much of the recent work appears to be on APIs and browser integration, which I assume would be shared with pNaCl.

kayoone2• 15 years ago

So when is this integrated into Chrome then ? Is it already? I cant really find information on that.

ysangkok2• 15 years ago

It already is. You need to enable it manually though. If you use NaCl 0.5 you need Chrome 14.

kayoone2• 15 years ago

Alright cool, but when is it enabled by default so we can take advantage of users not needing a plugin anymore ? Does google have any plan there ? Seems to take forever since i first read about NaCL in 2009.

diggericon• 15 years ago

Its crashing at my end.

Google Native Client 0.5 : released with stable ABI

Related Stories