Google Native Client 0.5 : released with stable ABI
code.google.com
Google Native Client 0.5 : released with stable ABI
1–10 of 19 posts
Re: Google Native Client 0.5 : released with stable ABI
#2Does 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.
Re: Google Native Client 0.5 : released with stable ABI
#3NaCl seems like such a dead end, I can't understand why work is going into this instead of PNaCl.
Re: Google Native Client 0.5 : released with stable ABI
#4NaCl seems like such a dead end, I can't understand why work is going into this instead of PNaCl.
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.
Re: Google Native Client 0.5 : released with stable ABI
#5Does 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 ou…
NaCl can perform the same I/O that JavaScript can, so it may not do what you want.
Re: Google Native Client 0.5 : released with stable ABI
#6NaCl seems like such a dead end, I can't understand why work is going into this instead of PNaCl.
Much of the recent work appears to be on APIs and browser integration, which I assume would be shared with pNaCl.
Re: Google Native Client 0.5 : released with stable ABI
#7NaCl seems like such a dead end, I can't understand why work is going into this instead of PNaCl.
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.
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.
Re: Google Native Client 0.5 : released with stable ABI
#8Does 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 ou…
NaCl can perform the same I/O that JavaScript can, so it may not do what you want.
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.
Re: Google Native Client 0.5 : released with stable ABI
#9Earlier quoted context omitted.
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.
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…
Thanks for the information. I did a little googling also after posting my question and it seems that it would be foolish to look at using either of them for any sort of production code at the moment. I think the PNaCl approach looks more interesting though. One to watch perhaps, but more out of curiosity right now.
Re: Google Native Client 0.5 : released with stable ABI
#10Earlier quoted context omitted.
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.
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…
NativeClient supports ARM (http://www.h-online.com/open/news/item/Google-s-Native-Clien...).
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.