
Native Client is Widely Misunderstood (2011) - felipellrocha
http://chadaustin.me/2011/01/native-client-is-widely-misunderstood-and-what-google-should-do-about-it/
======
gress
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
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
The Trojan horse logic is about being able to ship binary apps to those
platforms within chrome without having to build everything in.

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

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

------
leoc
There's also a MIPS implementation now too.

------
mantrax5
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
I can tell you didn't read the article because it addresses your point first
thing.

~~~
mantrax5
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
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-...](http://googlecode.blogspot.com/2011/08/native-client-brings-
sandboxed-native.html)

" 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
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...](http://blog.chromium.org/2010/05/sneak-peek-at-native-client-
sdk.html) (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.

~~~
DannyBee
This is not how it was introduced, the blog post was the introduction. We
published earlier research papers because we publish papers.

The plan was always the same.

Before this, the project wasn't really real, it was just research.

If you consider this "public messaging", then I guess google should never
release research papers or research SDK's without fear of being raked over the
coals?

If so, that's a sad state of affairs.

~~~
tptacek
They held the sandbox breaking contest (our team came in second!) in 2009.
You're suggesting they announced in 2011, right?

~~~
DannyBee
I'm suggesting in 2009, it was random cool research (I actually can't even
remember whether it was being funded by chrome back then), not something with
a real and true plan to become what it is now.

That really didn't happen until late 2010 or 2011, AFAIK.

~~~
tptacek
I think I could debate this point with you, but I just clicked up the thread
to see the context (I only found this subthread because I follow your
comments) and can now see why we wouldn't want to perpetuate this subthread.

Your original point, that Portable Nacl is within the original charter of the
Nacl project, was valid, even if we can quibble about the timelines. :)

