Let's Try Again in Merkinish: "Education Is Key"
This is a technology site, so if you really want to know what Native Client is all about, maybe you take the time to read this
http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf
,before you write half-truths here ?
And if you still think it is less secure than a JVM, please post your questions for people like me who actually read the paper.
Regarding Security Managers, I think there is a consensus in academia that you can make them safe. Whether SUN ever got them right, I have some doubts, though.
There is a consensus that SE Linux and AppArmor have strong and dependable security managers. There is a consensus that an OS like Linux and the MMU can lock processes out of the kernel. So if they manage, why shouldn't Native Client ?
Secondly, NaCl does not need LLVM. It might be useful as an ANDF
http://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format
though.
Thirdly, NaCl allows for basically any programming language to compile natively against a CPU, if a small number of precautions are taken during code generation. You don't need to use Garbage Collection if you don't like it, which is different to the JVM. You are not forced to use the simplistic memory layout scheme of Java or .Net. Neither that funny bag concept of JavaScript.
It would not be a major effort to port COBOL, FreePascal and a ton of other compiled or interpreted languages to NaCl. Only a little change in the code generator is required (alignment of jump target addresses , alignment of indirect jumps, and instruction white-listing, basically). I find the Googlers had a refreshingly new idea and the fact they made it open source made it even more attractive.
Think of this application: An algotrader submits his trading code to the Stock exchange as a NaCl executable and the exchange will execute the algorithm directly in the process of the trade matching engine. Delay: 1 microsecond.