5 ms·

Native Client is Widely Misunderstood (2011)

19 points by felipellrocha 12y ago

higherpurpose 12y ago
> Native Client implies x86 False. Originally, Native Client was positioned as an x86 sandbox technology, but now it has a clear LLVM story, with x86-32, x86-64, and partially-implemented ARM backends. Portability is a key benefit of the web, and Google understands this. And yet, Google seems to be pushing Intel chips in Chromebooks, to the point where Intel almost completely dominates the Chromebook market. NaCl actually doesn't work "as is" on ARM, only PNaCl does, and I think Google tends to prefer NaCl over PNacl, which is why they keep pushing Intel Chromebooks in the market.
- jayd16 12y ago
  Intel is pushing Intel chips in Chromebooks. They're undercutting and OEMs are certainly not going to say no.
- ryanackley 12y ago
  As someone who has actually developed in NaCl and participated in that community, your statements have no basis in fact and sound completely biased against Google. Out of the box, PNaCl is now the default toolchain. All the NaCl docs discuss PNaCl as the target of choice. The build target of the tutorials in the NaCl docs is PNaCl. Also, in the dedicated NaCL Google Group, the NaCl team has been saying for years that PNaCl would eventually be the default and preferred target for NaCl components.
mantrax5 12y ago
I understood it won't pick up, and lo and behold, I understood it right. People were right that an x86 sandbox is a silly idea for a web standard, this is why it's no longer one. As it is right now, it's ASM.JS, without the .JS (and so, without the backwards compatibility).
- pekk 12y ago
  I can tell you didn't read the article because it addresses your point first thing.
  - mantrax5 12y ago
    I actually did read it. And I'm responding to the idea that "see, you complained, and Google changed it, so your former complaints are now misunderstandings" is really not a valid thesis.
    - DannyBee 12y ago
      Your claim that it was ever meant to stay "an x86 sandbox" is contradicted by a lot of things, including the actual launch announcement for NACL: http://googlecode.blogspot.com/2011/08/native-client-brings-sandboxed-native.html http://googlecode.blogspot.com/2011/08/native-client-brings-... " The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. " I actually dislike PNaCL for a different set of reasons, but claiming it was built as an x86 sandbox, and meant to stay that way, is just revisionist history. If you believed otherwise, it was, in fact, your misunderstanding.
      - cliffbean 12y ago
        Your history omits an earlier chapter, which was the period during which Google introduced NaCl to the world. http://research.google.com/pubs/archive/34913.pdf http://research.google.com/pubs/archive/34913.pdf (2009) http://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html http://blog.chromium.org/2010/05/sneak-peek-at-native-client... (2010) No mention of PNaCL anywhere. Eventually they did change their public messaging away from x86 sandbox and towards PNaCl, though not before causing lots of external confusion and fear. And even then, with the time it took to get PNaCl released, some of the external confusion persisted. The earlier poster does indeed seem to have misunderstood the history, but it's easy to see where such misunderstanding may come from.
gress 12y ago
I don't think Google cares about it as a web standard. They just want to deploy it widely through chrome, ChromeOS, and chrome on Android (eventually), and use it as a Trojan horse for their own binary applications and OS components.
- ryanackley 12y ago
  I don't follow the trojan horse logic since they already have the unfettered ability to ship any binary component they want to the platforms you list without using Native Client.
  - gress 12y ago
    The Trojan horse logic is about being able to ship binary apps to those platforms within chrome without having to build everything in.
- tootie 12y ago
  I'm guessing Apple will cockblock them from ever deploying this to iOS. In that regard, asm.js is far more likely to see adoption.
  - gress 12y ago
    You're right that Apple won't allow that on iOS, but I don't think they care. This is about them establishing a new platform to displace Android and the open web.
leoc 12y ago
There's also a MIPS implementation now too.

19 points by felipellrocha 12y ago

> Native Client implies x86 False. Originally, Native Client was positioned as an x86 sandbox technology, but now it has a clear LLVM story, with x86-32, x86-64, and partially-implemented ARM backends. Portability is a key benefit of the web, and Google understands this. And yet, Google seems to be pushing Intel chips in Chromebooks, to the point where Intel almost completely dominates the Chromebook market. NaCl actually doesn't work "as is" on ARM, only PNaCl does, and I think Google tends to prefer NaCl over PNacl, which is why they keep pushing Intel Chromebooks in the market.

jayd16 12y ago
Intel is pushing Intel chips in Chromebooks. They're undercutting and OEMs are certainly not going to say no.
ryanackley 12y ago
As someone who has actually developed in NaCl and participated in that community, your statements have no basis in fact and sound completely biased against Google. Out of the box, PNaCl is now the default toolchain. All the NaCl docs discuss PNaCl as the target of choice. The build target of the tutorials in the NaCl docs is PNaCl. Also, in the dedicated NaCL Google Group, the NaCl team has been saying for years that PNaCl would eventually be the default and preferred target for NaCl components.

mantrax5 12y ago

I understood it won't pick up, and lo and behold, I understood it right. People were right that an x86 sandbox is a silly idea for a web standard, this is why it's no longer one. As it is right now, it's ASM.JS, without the .JS (and so, without the backwards compatibility).

pekk 12y ago
I can tell you didn't read the article because it addresses your point first thing.
- mantrax5 12y ago
  I actually did read it. And I'm responding to the idea that "see, you complained, and Google changed it, so your former complaints are now misunderstandings" is really not a valid thesis.
  - DannyBee 12y ago
    Your claim that it was ever meant to stay "an x86 sandbox" is contradicted by a lot of things, including the actual launch announcement for NACL: http://googlecode.blogspot.com/2011/08/native-client-brings-sandboxed-native.html http://googlecode.blogspot.com/2011/08/native-client-brings-... " The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. " I actually dislike PNaCL for a different set of reasons, but claiming it was built as an x86 sandbox, and meant to stay that way, is just revisionist history. If you believed otherwise, it was, in fact, your misunderstanding.
    - cliffbean 12y ago
      Your history omits an earlier chapter, which was the period during which Google introduced NaCl to the world. http://research.google.com/pubs/archive/34913.pdf http://research.google.com/pubs/archive/34913.pdf (2009) http://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html http://blog.chromium.org/2010/05/sneak-peek-at-native-client... (2010) No mention of PNaCL anywhere. Eventually they did change their public messaging away from x86 sandbox and towards PNaCl, though not before causing lots of external confusion and fear. And even then, with the time it took to get PNaCl released, some of the external confusion persisted. The earlier poster does indeed seem to have misunderstood the history, but it's easy to see where such misunderstanding may come from.

gress 12y ago

I don't think Google cares about it as a web standard. They just want to deploy it widely through chrome, ChromeOS, and chrome on Android (eventually), and use it as a Trojan horse for their own binary applications and OS components.

ryanackley 12y ago
I don't follow the trojan horse logic since they already have the unfettered ability to ship any binary component they want to the platforms you list without using Native Client.
- gress 12y ago
  The Trojan horse logic is about being able to ship binary apps to those platforms within chrome without having to build everything in.
tootie 12y ago
I'm guessing Apple will cockblock them from ever deploying this to iOS. In that regard, asm.js is far more likely to see adoption.
- gress 12y ago
  You're right that Apple won't allow that on iOS, but I don't think they care. This is about them establishing a new platform to displace Android and the open web.

leoc 12y ago

There's also a MIPS implementation now too.