Linked by Thom Holwerda on Wed 10th Dec 2008 19:49 UTC, submitted by BluenoseJake
Google has released an early version of Native Client, a framework designed to run portable x86 binaries inside a web browser - in a sandbox. Native Client also includes technologies that allow for easier communication between JavaScript and Native Client executables, which makes it possible for web applications to leverage native code when it comes to processor intensive tasks. This sounds eerily similar to Microsoft's ActiveX - one of the biggest security failures of the Windows operating system. Google insists, however, that Native Client is much, much more secure.
Thread beginning with comment 339817
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Good luck with securing the x86 instruction set
by kragil on Wed 10th Dec 2008 21:11
in reply to "RE: Good luck with securing the x86 instruction set"
Member since:2006-01-04
Agreed. Pushing and optimizing Java might be the better option IMHO.
Secretly I am hoping that open source and open standard will break the dominance of X86. It would be really nice to have a fast ARM Netbook in 2009 that can run nearly everything for a whole working day (8 to 10 hours).
100% working open source flash is the only thing I still really need.
And I don't think Google is smarter than I am 
(Lively anyone?)
RE[2]: Good luck with securing the x86 instruction set
by james_parker on Wed 10th Dec 2008 21:15
in reply to "RE: Good luck with securing the x86 instruction set"
Member since:2005-06-29
I'm not even sure what the advantages of running native code are supposed to be. Poor implementations of non-JIT Java [...] combined with more years of poor implementations of non-JIT javascript have given portable runtimes a bad name.
The problem with "JIT" is that the results are simply thrown away after use. A much better approach would be "JITAR" (Just in Time And Retain), which would then amortize the translation of executable code across multiple invocations. Combined with efficient fine-grained dynamic linkin, a mechanism for finding and using common libraries (not necessarily maintained by a single source), and reliable version checking -- all to reduce the actual amount of compilation done across applications -- it could be extremely efficient.
Of course, given its relative ubiquity, x86 (or a reasonable subset) could be used as the intermediate language to even further reduce compilation for common cases.
RE[2]: Good luck with securing the x86 instruction set
by Michael on Wed 10th Dec 2008 21:20
in reply to "RE: Good luck with securing the x86 instruction set"
Member since:2005-07-01
RE[3]: Good luck with securing the x86 instruction set
by JrezIN on Wed 10th Dec 2008 23:10
in reply to "RE[2]: Good luck with securing the x86 instruction set"
Member since:2005-06-29
RE[2]: Good luck with securing the x86 instruction set
by Wes Felter on Wed 10th Dec 2008 22:46
in reply to "RE: Good luck with securing the x86 instruction set"
Member since:2005-11-15
RE[3]: Good luck with securing the x86 instruction set
by Delgarde on Wed 10th Dec 2008 23:18
in reply to "RE[2]: Good luck with securing the x86 instruction set"
Member since:2008-08-19
Rewriting C code in Java is expensive.
It is, but that's relevant only if existing unmodified C code will run on this new platform. There's a question of libraries (both static and shared), of binary formats, of all sorts of things like that. If my code calls printf, for example, where will it find the function implementation, and how? The story doesn't answer any of those questions.
RE[3]: Good luck with securing the x86 instruction set
by tyrione on Thu 11th Dec 2008 00:24
in reply to "RE[2]: Good luck with securing the x86 instruction set"
Member since:2005-11-21
Member since:
2005-07-24
I'm not even sure what the advantages of running native code are supposed to be. Poor implementations of non-JIT Java with horrid support for UIs back during the heyday of Java "applets" combined with more years of poor implementations of non-JIT javascript have given portable runtimes (and the letters 'j', 'a', and 'v') a bad name. Java is really only a little clunky these days, and Javascript engines are getting ready to not suck. We're finally mostly rid of the rid of the ActiveX terror. This is not the time to be pushing native code. It's finally time to start pushing client-side Java and Javascript.
Then again, the guys at Google are a lot smarter than I am. So there must be some uber-rarified reason for doing this.
Edited 2008-12-10 20:41 UTC