5 ms·

Can you go into more detail about why you are glad there isn't a blob + VM approach? I know the long history of Java vulnerabilities, etc... but I'd be curious

by hderms 14y ago

Can you go into more detail about why you are glad there isn't a blob + VM approach? I know the long history of Java vulnerabilities, etc... but I'd be curious to hear what someone knowledgeable about the subject would say.

hosay123 14y ago
It's easy to show. Imagine Gmail was written for and compiled with an IE3 or IE4 era Javascript parser/interpreter/compiler, and the result was distributed as a blob to run natively. Shortly thereafter Google goes out of business. Now imagine the browser vendors finally figure out how to make languages like Javascript fast, only there is the small problem of 100 zettabytes of blobs on the web, written by companies that no longer exist, and that can't be optimized at all because it's all distributed in a form that resists any inspection. We don't even use stacks any more – they were some daft hold-over of the 60s that lasted far too long into the 2040s. Only all those zettabytes of blobs were compiled with optimizations that target stack-based VMs. That's the promise of Native Client.
- cromwellian 14y ago
  A highly obfuscated and minified JS application like GMail has about the same level of introspectability as Java bytecode. I have little problem consuming Java bytecode written 18 years ago by companies that went out of business. Leaving aside binary format representation of portable VM code, there's also the issue that NaCl supports multithreading and asm.js doesn't. WebWorkers/Isolates are a poor substitute for high performance games.
  - niggler 14y ago
    "WebWorkers/Isolates are a poor substitute for high performance games." Have you tried? (genuinely curious)
    - fzzzy 14y ago
      WebWorkers have also been recently enhanced so that it is possible to pass a message with no copy (by moving it out of the current WebWorker; it loses it's reference to the data). I suspect taking advantage of this would greatly help in a game situation.
  - pifflesnort 14y ago
    Native Client also supports SSE on x86, and NEON on ARM.
    - hosay123 14y ago
      And will binaries compiled for Native Client today support SSE6 (released Q1 2014), ARMv15 (Q3 2016), and so on? Of course, if the authoring party still exists to recompile it, and they have a commercial reason for doing so..
      - pifflesnort 14y ago
        This is a problem no matter what your target is. Web apps written in 1997 do not take advantage of modern browser features. Browsers written in 1997 can not render modern web pages. At least with NaCL, you have the option of taking maximum advantage of the available hardware. I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing, the way we've seen CPU vendors add support for virtualization-specific extensions. At the end of the day, I don't see this as a death blow for NaCL. Rather, it pushes us farther into a post-JS/HTML/CSS platform. We'll start seeing new languages take off, and the underlying platform target itself (browser, native, or otherwise) will matter less and less. asm.js can be just another compilation target, along-side NaCL and iOS. Once you go in that direction, the HTML/JS/CSS monstrosity start to become less relevant outside of hypertext documents.
        comex 14y ago
        > I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing A bit off topic, but this already exists, in the sense that there is no difference between NaCl-style sandboxing and what every OS kernel already provides for its processes, except that NaCl is generally locked down tighter. All that would need to happen is for OSes to provide support for containers with arbitrarily restricted syscalls (as Linux already does) and NaCl could give up on the software fault isolation without any real loss in security.
        14y ago
  - agilescale 14y ago
    What do you mean by that? Java bytecode is leaps and bounds more instrospectable, and by that, I mean that programs can actually garner useful information from it, otherwise tools like Eclipse's code completion woudn't work. The source won't be preserved, but the class, field and method names will. That's much better than what you get from minified JS. I also mean that, despite its unconvenience, Java's reflection API is still quite powerful. I don't get the fixation with the fact that the filename ends in a .js extension; just because a bunch of code is in a familiar interpreted language doesn't make it readable or maintainable in any other manner.

by hderms 14y ago

hosay123 14y ago

It's easy to show. Imagine Gmail was written for and compiled with an IE3 or IE4 era Javascript parser/interpreter/compiler, and the result was distributed as a blob to run natively. Shortly thereafter Google goes out of business. Now imagine the browser vendors finally figure out how to make languages like Javascript fast, only there is the small problem of 100 zettabytes of blobs on the web, written by companies that no longer exist, and that can't be optimized at all because it's all distributed in a form that resists any inspection. We don't even use stacks any more – they were some daft hold-over of the 60s that lasted far too long into the 2040s. Only all those zettabytes of blobs were compiled with optimizations that target stack-based VMs. That's the promise of Native Client.

cromwellian 14y ago
A highly obfuscated and minified JS application like GMail has about the same level of introspectability as Java bytecode. I have little problem consuming Java bytecode written 18 years ago by companies that went out of business. Leaving aside binary format representation of portable VM code, there's also the issue that NaCl supports multithreading and asm.js doesn't. WebWorkers/Isolates are a poor substitute for high performance games.
- niggler 14y ago
  "WebWorkers/Isolates are a poor substitute for high performance games." Have you tried? (genuinely curious)
  - fzzzy 14y ago
    WebWorkers have also been recently enhanced so that it is possible to pass a message with no copy (by moving it out of the current WebWorker; it loses it's reference to the data). I suspect taking advantage of this would greatly help in a game situation.
- pifflesnort 14y ago
  Native Client also supports SSE on x86, and NEON on ARM.
  - hosay123 14y ago
    And will binaries compiled for Native Client today support SSE6 (released Q1 2014), ARMv15 (Q3 2016), and so on? Of course, if the authoring party still exists to recompile it, and they have a commercial reason for doing so..
    - pifflesnort 14y ago
      This is a problem no matter what your target is. Web apps written in 1997 do not take advantage of modern browser features. Browsers written in 1997 can not render modern web pages. At least with NaCL, you have the option of taking maximum advantage of the available hardware. I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing, the way we've seen CPU vendors add support for virtualization-specific extensions. At the end of the day, I don't see this as a death blow for NaCL. Rather, it pushes us farther into a post-JS/HTML/CSS platform. We'll start seeing new languages take off, and the underlying platform target itself (browser, native, or otherwise) will matter less and less. asm.js can be just another compilation target, along-side NaCL and iOS. Once you go in that direction, the HTML/JS/CSS monstrosity start to become less relevant outside of hypertext documents.
      - comex 14y ago
        > I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing A bit off topic, but this already exists, in the sense that there is no difference between NaCl-style sandboxing and what every OS kernel already provides for its processes, except that NaCl is generally locked down tighter. All that would need to happen is for OSes to provide support for containers with arbitrarily restricted syscalls (as Linux already does) and NaCl could give up on the software fault isolation without any real loss in security.
        14y ago
- agilescale 14y ago
  What do you mean by that? Java bytecode is leaps and bounds more instrospectable, and by that, I mean that programs can actually garner useful information from it, otherwise tools like Eclipse's code completion woudn't work. The source won't be preserved, but the class, field and method names will. That's much better than what you get from minified JS. I also mean that, despite its unconvenience, Java's reflection API is still quite powerful. I don't get the fixation with the fact that the filename ends in a .js extension; just because a bunch of code is in a familiar interpreted language doesn't make it readable or maintainable in any other manner.