Native Client is Widely Misunderstood (2011) | Hacker News Reader

Native Client is Widely Misunderstood (2011)

chadaustin.me

19 pointsfelipellrocha22 comments

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.

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.

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.

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.

The Trojan horse logic is about being able to ship binary apps to those platforms within chrome without having to build everything in.

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

Intel is pushing Intel chips in Chromebooks. They're undercutting and OEMs are certainly not going to say no.

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.

There's also a MIPS implementation now too.

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

I can tell you didn't read the article because it addresses your point first thing.

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.

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

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

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 (2009)

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.

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.

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

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.

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. :)

You're right that the first link I posted is a research paper, and that it should be interpreted accordingly. It is interesting though that in the paper, they compare NaCl to other systems, some of which include ISA virtualization, and they specifically say "we made a deliberate choice against virtualization". And this paper is just a small sample of what Google was saying about NaCl in 2009. But you're right, it is still a research project at that point.

However, you apparently missed the second link I posted, which is in fact a blog post and an introduction. NaCl is no longer a research project there. In fact, the post itself specifically describes the difference between research releases and the release it is announcing.

If some code runs orders of magnitude slower it's the same as being incompatible. Yes you might execute an ASM.JS game on older browsers but at 1FPS it's not enjoyable.

Yes, but it seems the blame game plays out differently. If a website won't run because it's demanding a plugin of some kind or a different web browser then the user tends to blame the website; if it runs, painfully slowly, on their browser but quickly on a different model of browser then (s)he tends to blame his/her browser. Really, the way forward is to have things set up so that sites can compile to arch-specific NaCl and PNaCl and "asm.js", and then serve the browser the best one that it will accept.

Native code is already heavily used in the form of iOS apps, it just isn't part of the web. I am not sure that this distinction is particularly profound considering how reliant the app ecosystem is on the internet. What iOS offers are basic guarantees about the capabilities of the underlying hardware. Web apps can make no such assumptions, regardless of how cleverly they execute the code. So for native client the application will never run fast enough for a significant number of users despite the design goal of increased speed. Unless the app has latency or bandwidth constraints it will always be more reliably faster to do resource intensive work on a server.

Reply on news.ycombinator.com