4 ms·

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 th

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.pdf?revision=1752 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.

hermanhermitage 14y ago
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.
BrendanEich 14y ago
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!
- aplzrtve 14y ago
  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?
  - BrendanEich 14y ago
    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.
cliffbean 14y ago
The link he cited still does apply. It discusses several different issues. PNaCl's portability only covers a subset of them.
- BrendanEich 14y ago
  Thanks! I happen to agree with with Dan Gohman (http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43769 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.
  - gsnedders 14y ago
    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.
deleted 14y ago
[deleted]

hermanhermitage 14y ago

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.

BrendanEich 14y ago

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!

aplzrtve 14y ago
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?
- BrendanEich 14y ago
  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.

cliffbean 14y ago

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

BrendanEich 14y ago
Thanks! I happen to agree with with Dan Gohman (http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43769 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.
- gsnedders 14y ago
  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.

deleted 14y ago

[deleted]