

Google Native Client 0.5 : released with stable ABI - Rexxar
http://code.google.com/intl/el-GR/chrome/nativeclient/docs/releasenotes.html

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

~~~
morganpyne
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.

~~~
forgotusername
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.

~~~
haberman
NativeClient supports ARM ([http://www.h-online.com/open/news/item/Google-s-
Native-Clien...](http://www.h-online.com/open/news/item/Google-s-Native-
Client-goes-ARM-and-beyond-957478.html)).

You would have to compile multiple versions to support multiple architectures,
but the implication that NaCl is fundamentally tied to x86 is incorrect.

NativeClient's use of segmentation on x86 is just an implementation detail of
how the sandbox is implemented on that architecture, AFAIK. NaCl doesn't
fundamentally require that any target architecture support segmentation.

~~~
forgotusername
Yep sorry for the misinformation, I hadn't read much about it recently. Seems
whatever it does on amd64 (or in PNaCl at a guess) is also how it works on arm
(7% slowdown from looking at the FAQ).

~~~
ysangkok
It's called Software Fault Isolation. There is a link to the paper on it in
Wikipedia.

------
morganpyne
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.

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

~~~
morganpyne
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.

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

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

~~~
kayoone
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
Its crashing at my end.

