Comment by BrendanEich | Hacker News Reader

Comment by BrendanEich | Hacker News Reader

Parent Full thread

PNaCl is both not done and (last I checked) not totally machine-independent due to LLVM encodings of machine word sizes. See also http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... for doubts on the wisdom of using LLVM bitcode for a long-lived, widely-distributed object file format.

PNACL is a fine research project, but unfortunately both NaCl and PNaCl are tied to Pepper, a gargantuan API specified nowhere and implemented only in chromium.org code.

To say this is "Open Technology" is to reduce "Open" to the level of "Big company Big Bucks Open-washing." There is nothing open about an unspecified research project without a proven multi-party governance structure that's dominated from start to finish by Google, and which only Google could afford to staff and push -- including via big-money distribution deals with game developers and distributors.

As I said at Strange Loop and in past talks, don't shoot the messenger: Microsoft and Apple will never adopt NaCl/Pepper. It is a non-starter as a web standard.

Why pray tell should Mozilla fall on Google's sword here? Why should we beg to be involved more "in the process" years after it started? Who are you to say that NaCl/Pepper is better for developers or anyone else than a cross-browser approach targeting JS VMs, which are already there and getting fast enough with typed array memory models to compete with PNaCl? (We aim to demonstrate this.)

NaCl/Pepper looks like an incumbent power's technological folly, similar to Microsoft Active X or Google's Dart-as-a-native-VM. Just because a big company can pay for it does not make it "Open" or "Good" or good for the web.

You've been free with charges of dishonesty, but I'll refrain from drawing conclusions about you from your position except to say that what you write is astoundingly naive -- at best. For anyone building a competitive browser that is not Chrome or chromium-based, what you propose is a money pit in direct and opportunity costs, with no clear path to standardization, where Firefox would always be behind in "Pepper conformance" compared to Chrome. The answer is no.

You'll get the same answer from any other browser vendor not free-riding off of chromium/Google.

There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to jump on what is perceived as a "Google treadmill." None of my comment was about any of that.

What I can't understand is the fundamentalist reaction to the very idea of native code, the ignoring/dismissing of serious work to solve the problem of portability, the liberal use of words like "never" and "non-starter," spread of FUD by invoking inaccurate comparisons like ActiveX (vis a vis its security model) and DLL Hell, and the spreading of misinformation. For example, PNaCl is not, and as far as I can tell never has been, dependent on machine word size. The link you cited doesn't apply because it is arguing against a different approach than what PNaCl actually does.

PNaCl works by defining a little-endian ILP32 machine as the target and fixing all important characteristics of this machine independently of the characteristics of the underlying CPU. This abstract machine's characteristics are defined in such a way that they can efficiently be translated to native code on any modern CPU. This is all covered in the introductory doc: http://src.chromium.org/viewvc/native_client/data/site/pnacl...

> a cross-browser approach targeting JS VMs, which are already there and getting fast enough with typed array memory models to compete with PNaCl? (We aim to demonstrate this.)

This is a far more reasonable and compelling story. By all means talk up your stuff and argue that you can win in the free market of ideas. I'm not arguing that I or anybody else should be able to dictate to developers what technology they use; on the contrary it is the Mozilla argument of "no one gets to the machine except through our VM and our GC" that paternalistically ties developers' hands and limits their options.

Work with say Khronos group to establish an OpenCPU standard with a source code and possibly intermediate representation.

Socialize amongst CPU vendors, and interest platform makers in the mobile and desktop space.

Watch it absorbed by web standards.

You are still being free with accusations of spreading misinformation and other evils. If you want to have a real exchange, cool it! Just try to imagine how a hardball from me casting aspersions on you for suspected bad or unfair (to Mozilla; "fair" to Google) motives might feel.

Thanks for the PNaCl pointer. My comment was based on LLVM bitcode having machine word size dependencies. This was an issue a while ago. I should have checked to see if it remained one.

This correction doesn't alter the general unreadiness of PNaCl for the web, on several fronts. Pepper is one, but PNaCl performance lagging NaCl is another. The Chrome Web Store features games ported via NaCl, for performance -- not PNaCl, which would be significantly slower. On this basis alone, it's premature for you to push PNaCl ahead of Google.

> This is a far more reasonable and compelling story.

Well, gee, thanks a ton! :-|

I've been telling this story clearly since Fluent in May. That you chose not to hear it and instead flung accusations and told sob-stories about big bad Mozilla is your doing, not mine.

Here's a final clue: all browser vendors, definitely including Chrome, make the rule (not an argument) "no one gets to the machine except through our VM(s) and GC(s)" -- outside of a few dying plugins, which are even source-licensed and co-released.

And that brings back my final point: NaCl is for safer plugins, which are OS-specific anyway. The likeliest evolution of SFI or CFI enforcing compilers and runtimes as plugin hosts is via the OS, not the browser. Write a letter to Microsoft and Apple, not to Mozilla!

These are shallow arguments: * pepper is "inspired" by nsapi, clarify your point. * PNaCl performance lagging isn't a solid argument, you know it'll get better, the solution might even be to cut LLVM out save for bitcode. * "nobody does this at the moment" so why does it belong in the OS?

In reverse order:

* Why in the OS? I didn't say "belong", just "likelier". That is because plugins are native code compiled by OS-dependent toolchains, and OS vendors are few (three that matter) and lock up native code these days via SDK licenses, app store rules, and even kernel-level restrictions.

In contrast, there are four or five competitive browsers, only one of which has Pepper and the rest do not -- and will not.

* I do not know how much better PNaCl can get. The shallow argument here is your assertion that "you know it'll get better". The same could be speculated about JS performance at Emscripten-generated code, and that works cross-browser. That's the cross-browser path of least resistance, compared to the practically unpassable Pepper barrier.

* Pepper is "inspired" by lots of APIs, but here the shallow shoe fits your new-HN-user drive-by. NPAPI is a sunk cost all browsers save modern IE have paid out for years. Pepper is new and much bigger. Have you even read all the interfaces?

The bottom line is that whatever PNaCl performance wins may lie in the future -- and I will believe them when Google does as shown by Chrome Web Store games being PNaCl'ed not NaCl'ed -- Pepper is the blocker for any cross-browser adoption in reality.

This ignores principled objections to more native code on the web, as a "social ill". Let's take that up separately, because it could override any technical argument. I'm happy to stop on the Pepper point for now, since Google manifestly is stuck there.

Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser?

Why wouldn't other browsers have Pepper?

Compilers are as good as what they've been tuned for. In my view PNaCl's shortcoming is startup time because it lacks a JIT and LLVM's back end is too slow for now. Speed up the backend or JIT code and you'll get close to GCC performance while being portable and somewhat language agnostic.

Yes I have seen pepper, and most of the interface relates to the GPU. How is sunk cost better, when a big part of the API can be backed by what canvas relies on?

You would consider adopting PNaCl and pepper in FF if there were games that targeted them? If the code were contributed to Mozilla?

What do you mean by "more native code"? Can't view source?

I appreciate the answers.

>Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser?

I think you answered your own question with the "save" part.

The vendor shipping it with the browser means it controls it, it has responsibility for it, it secures it, and it allows it. End of story.

>Why wouldn't other browsers have Pepper?

JS is a necessity for a web browser/vendor, and is already present in it. Pepper is not, and there are NO signs it will be. Do you see any movement towards adoption as of now? I see the opposite, the abandonment of even old style plugins.

I'll rephrase: why is any new VM to be relegated to the OS? The presence of incumbent VMs?

JS is an incumbent. Pepper is similar to nsapi, and has nice features which are compatible with HTML5's implementation (as in canvas). Saying it shouldn't be adopted because Nobody is adopting it is circular.

What are old-style plugins? Anything not JS?

I said clearly why Pepper is not being adopted: it is a gigantic pile of API and implementation specified only by the C++ in chromium.org svn. Other browsers cannot port all that OS and WebKit glue code except at very high cost, direct and opportunity -- and even then on a bet that Pepper + NaCl wins, and again on a treadmill far behind Chrome.

Do you actually work on a browser codebase? If so, have you worked on competing browsers' codebases at all? Do you begin to see the problem? It's not quite Active X (open source is a small help), but it's on that slope and uphill only a bit.

> Other browsers cannot port all that OS and WebKit glue code except at very high cost

Why would any other browser need that glue code? The Pepper API is large but fairly straightforward and doesn't change dramatically between revisions. In addition, I don't believe Google has ever said that they wouldn't make the development process around those changes more open (at least making them public before pushing the new implementation out to the world).

> Do you actually work on a browser codebase? If so, have you worked on competing browsers' codebases at all? Do you begin to see the problem? It's not quite Active X (open source is a small help), but it's on that slope and uphill only a bit.

I've only worked on Webkit a small amount (mainly doing security analysis) but I worked with Pepper a good deal and I've worked on Gecko for a decent while now. I really don't see the incompatibility; there are plenty of good arguments against NaCl, but I don't think there's a fundamental problem there. I can definitely understand not wanting to allocate resources to the issue, but not being opposed to the issue in general.

> Why would any other browser need that glue code?

Because other browsers do not use WebKit, or at least chromium WebKit. Are you really asserting that no glue code is required on any other browser?

> The Pepper API is large but fairly straightforward

Where is the spec? You are not in the real world here.

There are plenty of differences between Gecko's audio APIs and Pepper's. If you really work on Gecko, mail me about this. I have reason to doubt your claims here.

If I sound argumentative and fired up, it's because I feel like Mozilla has been casting stones on this issue for years. Imagine how you would feel if Google executives were publicly criticizing Mozilla efforts like Persona, arguing that they would never support them and no one else will either, basing their criticisms on issues that you are actively fixing.

(For what it's worth, Persona looks promising to me personally, and I also like Rust very much, a lot more than Go. I say this to demonstrate that I'm not just a Google partisan and that I admire a lot of what comes from Mozilla).

I am much happier to discuss this dispassionately on a technical basis. I'm much happier if I don't have to argue against what to me are very unfair accusations, like being as proprietary as Silverlight.

> Here's a final clue: all browser vendors, definitely including Chrome, make the rule (not an argument) "no one gets to the machine except through our VM(s) and GC(s)"

I don't understand the argument you are making, (P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC. And (P)NaCl executables are OS-independent. I don't understand what you're getting at here.

>(P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC

And this is the argument he's making: that does not fly by browser vendors. They DON'T want to have code run OUTSIDE their VM/GC.

He said "including Chrome." Chrome supports NaCl. This does not compute.

It's not hard: Chrome sandboxes NaCl'ed code and links it against a runtime, Pepper. That's a "VM" by any other name.

Thanks for the support, but that's not what I meant. NaCl + Pepper is like a VM where the compiler does the heavy lifting so the native code can run safely (Software Fault Isolation, SFI -- wild pointers lead to a safe non-exploitable crash), rather than a JITting or MMU- or hypervisor-based VM doing the heavy lifting at runtime.

It's quite clever, but still enough of a new thing that Chrome also sandboxes NaCl'ed code out of process. Belt and braces are good. No silver bullets.

But a VM is as a VM does. This is part of Google's VM-set and not any other browsers. The rule still applies.

Truly unsafe native code in plugins (e.g., un-NaCl'ed Flash) runs out of process too, and sandboxed to some extent, but it can cause problems that are not contained (and did at the last CanSecWest Pwn2Own contest, IIRC).

The link he cited still does apply. It discusses several different issues. PNaCl's portability only covers a subset of them.

Thanks! I happen to agree with with Dan Gohman (http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43...), but I'm not sure where Chris Lattner ended up on this.

Much is possible in software, so perhaps some day, or under some transformation, LLVM bitcode would be suitable as a stable long-term object file format.

There's still a point here: PNaCl is pushing a stone up a very tall hill. ANDF and other Universal Object formats go back to the 70s if not earlier. It's very difficult to standardize such things, never mind Pepper.

FWIW, the aim for LLVM is to avoid breaking the bitcode format now 3.0 has shipped — not that it's platform independent or anything else yet.

I don't understand why you feel it necessary to make your points in such an inflammatory manner. Your arguments are well made, why do you feel the need to, for example, call someone 'astoundingly naive?' Being rude doesn't make your points more convincing and I would have hoped you were above that kind of thing. It's a pity because you have a huge amount to contribute.

I went out of my way to say that Haberman's position as I understood it -- not he himself -- was "astoundingly naive". This after he called me dishonest and speculated on motives. Are you using the same yardstick with me as with him? I think not.

Arguing about motives is a form of the _ad hominem_ fallacy, and I was avoiding it, in contrast to my fine counterpart. Yeesh!

Oh come on. My label of "dishonest" was in regards to a statement, not you personally, just like your label of "astoundingly naive" against me.

And I didn't speculate about motives. I'm not sure what statements of mine you're taking so much offense to, but your speech has also been brusque and uncharitable at times ("Who are you to say...", "Here's a final clue:").

I also went out of my way to empathize with Mozilla's concerns and reasoning for not wanting to support NaCl, whereas you show no appreciation for why someone might ever legitimately want to run native code on the web.

You wrote, very first comment at top:

"To dis NaCl on this basis and not even mention PNaCl is dishonest."

That was in response to my slides. You were calling me dishonest. Come on yourself!

You then went on about "propaganda" and scary salt crystals. Something is off right there. Mozilla doesn't make propaganda and we have a tiny fraction of Google's budget (which I can assure you has been deployed commercially to push NaCl).

I don't think your tone or content are balanced on any of this, and you at least climbed down on the salt crystals. Can you do likewise on the "dishonest"?

Please stop signing your posts.

Why?

House style: http://ycombinator.com/newsguidelines.html

Please don't sign comments, especially with your url. They're already signed with your username. If other users want to learn more about you, they can click on it to see your profile.

Ok, sorry about violating house style. Old habits die hard.

You seem a lot more interested in getting me to take back things than you are in taking back your misleading slide.

Substitute whatever adjectives you want if the ones I used offend you, but the point still remains that the most vocal criticism of (P)NaCl comes from Mozilla and it is anything but "balanced."

I would feel more inclined to issue an actual retraction if there was any indication that I was mistaken about this or that it would change.

That said I'm not really interested in arguing further, since we've clearly reached an impasse. I admire the work you have done with JavaScript, and I admire the work Mozilla has done over the years on many great products.

The slide I showed is not misleading. NaCl is not portable, PNaCl is still not ready for prime time based on Google's own actions, and you protest too much and do not practice what you preach.

"Mozilla" meaning me, bzbarsky, blizzard (previously), roc on the plugin-futures list, others have been forthright compared to the mostly-silent other browser vendors, who haven't even spoken via corporate or individual channels on this non-issue apart from my pal Maciej at Apple coining "Active G" to refer to Pepper.

If this circumstance makes you shoot us, the messengers, you need to read more Greek tragedy!

We're telling you why NaCl/Pepper are a no-sale among all the non-chromium browsers. You don't like the reasons we give, but that's no justification for your ascribing to us bad motives or a dishonest agenda or techniques ("propaganda"). We have been perfectly clear about the unacceptably high cost of Pepper, and the single-company control problem of all of NaCl/PNaCl/Pepper.

Your own misstatements are yours, and you should retract or not based on their righteous or wrongful nature, not on what anyone else does. That you excuse your conduct based on your grievance with us is thoroughly broken, as a piece of moral reasoning.

At this point you are perfectly clear: you want a free lunch (from all browsers, but especially from Firefox), we won't give it to you, so you call us names and imply that we act out of bad motives. That makes you persona non grata in my book. Good luck!

I've expressed my personal opinions about NaCl here on HN before too: http://news.ycombinator.com/item?id=2057611

For what it's worth, I think the comment you linked is far more fair and balanced criticism. If all of the statements I was hearing from Mozilla people sounded like that, I would have no beef.

Maciej and I agree, but you are holding Mozilla to a different standard from Apple. Another reason I'm striving to ignore you (for both our sakes).

I have a different writing style from Brendan, but I don't think there is any significant substantive difference between what he said in this thread and what I said almost 2 years ago.

(Although, the fact that PNaCl is still an experiment and not the mainstream of NaCl nearly two years after I wrote my comment should be further cause for concern.)

The significant substantive differences, to me as a reader, are:

- You don't make final-sounding judgments like "never" or "non-starter" that preemptively reject any future evolution of the technology.

- Your criticisms are highly pragmatic and specific, such that it is clear what hurdles the technology would have to clear to address them, and you don't close the door to the idea that they could (even if it seems unlikely to you).

- You don't fall back on ideological arguments like native code as a "social ill" that would suggest that your true objections run deeper than what any technical improvements could possibly address.

Thank you for that.

The purpose of my "final-sounding judgments" is to cut the crap in the short term that keeps getting dumped on Mozilla by you and others with an enlarged sense of entitlement, and an unjustified assumption that NaCl/PNaCl + Pepper is somehow "better" in the large, and so should get free support from non-Chrome browsers.

If you think overcoming some hurdles enumerated by Maciej will get PNaCL and Pepper support into Safari (where, BTW, Pepper is closest to porting cleanly by any measure, e.g., patch size), you're dreaming. Remember, I did not coin the funny "Active G" phrase. That shoe was fit by the guy you're trying to suck up to here.

If an indefinite-future-tense, and therefore worthless, promise from me to be open to portable SuperPNaCl in 2020, will get you to stop bashing Mozilla and flattering Apple, then here it is. Indeed my plan is for JS to evolve and mutate to be that portable object format for native code to compile to.

Emscripten is a promising sign along this path. And the PNaCl folks are targeting JS too, I hear, so this looks like a common goal.

Now can you stop defaming Mozilla?

/be

Now can you start ignoring haberman like you said you would? Your belligerent comments are getting a bit old at this point. You hate NaCl. We get it. Criticizing a slide makes you upset. OK. Understood.

I always reply when I have something worth saying.

"Hate" is the wrong word. There's nothing to hate in a well-done SFI-enforcing compiler. I admire the R&D effort. We -- bad old Mozilla, including evil-me -- are seriously considering using NaCl (not Pepper) for SFI in native code parts of Servo. No "hate" here, so do try to grow up: "You hate NaCl" is just weak, beneath you, as an analysis of motives and causes.

Let's step away from NaCl as pure tech for safer compilation of unsafe languages.

I do call Google's business strategy pushing NaCl+Pepper via games and even (till it all fell apart last November) Flash heavy-handed, and one-sided to such an extent that what's pushed can never be standardized.

What's belligerent here is for someone (haberman), who I hear works for Google, a company that has all the money and power in the world, and which makes actual "pro-NaCl propaganda" as well as pays game developers and others to use the Chrome-only tech (NaCl, not PNaCl, note well), to fire first on this thread. It wasn't me who showed "belligerence".

That first shot even tried open-washing, lamely, and it tellingly put Mozilla in the subordinate position. ''I could understand "we want to be more involved in the process."''

If you don't work for Google or hold a brief for them, ask yourself why haberman's presumption is that Mozilla, or any other browser maker, should be asking or begging to be included in a process that we were excluded from and practically speaking could never participate in without equal big bucks and market power.

The great thing about the Web is that no one owns it. Browser vendors, tool makers, and developers (whom the first two groups avidly court) have to reach consensus via standards. And I find that developers, not just pure web devs, definitely including @kripken (Emscripten's creator), @jashkenas (CoffeeScript), and others, are more creative and faster moving than many highly-paid C++-first hackers, including those perpetrating single-vendor follies such as NaCl+Pepper.

Whine at me, cry "hate" and "belligerence" while turning a blind eye to the big gun who fired first, and shoot the messenger. It doesn't matter. NaCl+Pepper have already lost to JS for portable cross-browser high-performance native code compilation.

Ah I see I should have said "Google" where I said "NaCl". My mistake.

You're doing better! But no, I don't "hate" Google. Big companies and big groups of people in general have inherent morally failure-prone properties. Google fights these, and in many ways still manages "don't be evil".

Heavy-handed and one-sided strategies and tactics may be odious, I may "hate" them -- you should too if they're not well-justified and likely to prevail -- but that's not the point of this exchange, which haberman started. Nice try deflecting, though.

The point of my slide, and of my comments here, is to make the case for what's best for the Web. So let's get back to that.

What is best for the Web? Not NaCl, we all agree. PNaCl? Not with Pepper as a mandatory API for all browsers to adopt. And PNaCl has a JS back end.

Steve Jobs killed Flash. Plugins are in decline. However well Google, Mozilla, and others use NaCl for native code safety, on the Web JS looks highly likely to continue, and to get super-fast for the well-typed and GC-free code produced by Emscripten.

This all points to a future where evolved JS is the PNaCl format that works cross-browser. We're already working on this at Mozilla, but via Emscripten not PNaCl. If Google aims its formidable engineers at the same goal and works in the standards bodies early and fairly, great. I'd love that.

Do you think the current status of Emscripten justifies your words? We'd all like to believe that.

The challenge now is more on the JS VM side, optimizing the Emscripten-generated idioms and the typed array memory model. Also, longer-term, we're working on JS language evolution via Ecma TC39.

These are focus areas of the team I just mentioned.

Well we agree. My answer is not to justify PNaCL, but to let you know that when you say "we commit to this", it means we give some serious investment on Emscripten and building a community. So far Emscripten has only been mentioned as 1-2 slides on each JS talk. And I think we both agree that a serious project as it is, it needs a few people building posting updates and letting everyone about the great work that is being done by @kripken.

Thanks though for your answer.

That's why you have been supporting Emscripten with... just one developer, it's creator? Shouldn't there be a whole team towards this goal you envision?

Currently emscripten should have the amount of people three.js has.

There is a team working on the longer-term goal, including game platform, JS engine, and Mozilla Research people. Why did you assume otherwise?

Also, Emscripten has a strong github community. Unlike Google we can't afford to pay everyone who might be needed -- we also prefer not to if we can build a wider community from day one.

Wow, I didn't notice that the thread continued for so long after I posted.

The things you cite are pretty much all because I would never give 0% probability to a future event. Who knows? Things change. But I think it is quite unlikely that NaCl will become a widely accepted part of the Web platform, and I think that would be a bad thing in its current state.

My "highly pragmatic and specific" criticisms seem to me like they say the same thing as Brendan's original slide bullets, just with more detail. I did not mention "no view source", but I agree that is a significant downside, if not necessarily as much of a showstopper as the others. Being a single-vendor-controlled technology is the biggest showstopper.

Another big issue that I didn't mention, and which I think also aligns with Brendan's criticisms, is that adding a major new technology to the web platform requires tremendously compelling use cases and a good argument that they cannot be handled with existing technologies. I don't think that case has really been made for NaCl.

And yes, I did jokingly coin the term "ActiveG" to refer to NaCl. Though I believe it was another wag who later referred to Dart as "GBScript".

Oh hey, I just saw this now.

For what it's worth I thought you were from Mozilla when I wrote my post, not that it matters that much either way.

I think you made some substantial points that were not covered in Brendan's slides, specifically:

- A standard with only one implementation is de facto controlled by one entity. This is a great point, and different than Brendan's point "defined by implementation." Brendan's criticism would be solved simply by standardizing (P)NaCl under multi-party governance, which I fully expect Google will do at some point. [0] Your criticism is not solved unless it is actually practically feasible for someone else to implement that standard.

- Relying on binary-level validation of binary code has a lot of attack surface. This is a great point that I've seen others make, though I believe it is being addressed (perhaps since you wrote your message) by having multiple layers of defense (ie. also running in a separate process inside a ptrace sandbox).

It doesn't bother me that you joke around with your friends by calling it "ActiveG," because in the context of serious discussion you acknowledge that it has "a better attempt at security design than ActiveX." It does bother me when others seriously compare the two, as if a completely unsandboxed execution environment can be compared to a serious attempt at sandboxing.

In any case, now that it supposed to be shipping soon (http://news.cnet.com/8301-1023_3-57534803-93/google-offers-l...) we should get a better chance to see if it truly can demonstrate a compelling improvement over JavaScript.

[0] Just wanted to mention that though I work for Google I am not involved in (P)NaCl and have no inside information about it.

> At this point you are perfectly clear: you want a free lunch

Nope, I wanted a footnote that says "they're working on it." That is about 97% of what I wanted from this discussion. ES6 isn't "ready for prime time" either, being an unfinished spec, and yet the entire presentation was about that. You're comparing JavaScript's future with NaCl's present, and not mentioning that it is Google's stated purpose to remove the glaring limitation that is the basis of your discounting it as a technology (at least as far as that slide is concerned). How is that not misleading?

I have never once suggested, in a single one of my messages on this thread, that non-Chromium browsers should adopt NaCl/Pepper in their current form (in fact I have said exactly the opposite, that I can understand their reasons for not wanting to), and yet you continue to attribute this viewpoint to me, calling me "astoundingly naive" for it, and issuing no retraction for that (despite all the retractions you demand from me). How is this the moral high ground?

I would be happy (more than happy, actually) to completely retract my statement, since it certainly gives me no pleasure to think that you would mislead your audience, but you are declining to demonstrate that I was wrong or that you have an interest in being entirely forthcoming with your audience. By pressuring me to retract my statements while feeling free to say what you want I feel you are bullying me. I'm not a huge fan of how you are ascribing inaccurate viewpoints to me and calling me names for them, and yet I am not demanding that you retract it all or I will discount your existence as a person (incredibly harsh, by the way).

does PNaCl work? do you know the answer to that question?

I have not personally used it, but the documentation at http://www.chromium.org/nativeclient/pnacl/building-and-test... indicates that it is at least capable of running spec2k. I don't know what's complete and what is incomplete. I do know that it is the stated goal of the NaCl project to achieve portability through PNaCl; that alone makes it deserving of mention in this context (https://developers.google.com/native-client/overview#distrib...).

Reply on news.ycombinator.com