> the need for that ultimate level of performance feels ever more irrelevant
Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog.
> ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea.
It's not much different to downloading and running JS. Heap Spraying attacks are the simplest you can run against a JS vm. Then there's more advanced attacks that abuse the JITs nowadays found in VMs to generate malicious native code. And I bet not many JS VMs check their generated code for sanity - which NaCl on the other hand does.
> Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog.
That's due to shitty coding by the front-end developer of the blog. With power comes responsibility; writing in C is a lot of power but there are far more opportunities to write shitty code.
You don't want JavaScript VMs to be running NaCl's verifier on all the code that they generate. That would be a significant performance loss. Remember that JavaScript engines are fundamentally built around self-modifying code, so the verifier would be running all the time.
Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog.
> ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea.
It's not much different to downloading and running JS. Heap Spraying attacks are the simplest you can run against a JS vm. Then there's more advanced attacks that abuse the JITs nowadays found in VMs to generate malicious native code. And I bet not many JS VMs check their generated code for sanity - which NaCl on the other hand does.