Slashdot Mirror
Google Native Client Puts x86 On the Web
t3rmin4t0r writes "Google has announced its Google native client, which enables x86 native code to be run securely inside a browser. With Java applets already dead and buried, this could mean the end of the new war between browsers and the various JavaScript engines (V8, Squirrelfish, Tracemonkey). The only question remains whether it can be secured (ala ActiveX) and whether the advantages carry over onto non-x86 platforms. The package is available for download from its Google code site. Hopefully, I can finally write my web apps in asm." Note: the Google code page description points out that this is not ready for production use: "We've released this project at an early, research stage to get feedback from the security and broader open-source communities." Reader eldavojohn links to a technical paper linked from that Google code page [PDF] titled "Native Client: A Sandbox for Portable, Untrusted x86 Native Code," and suggests this in-browser Quake demo, which requires the Native Code plug-in.
The only problem you seem to have with Java plugins is the load time -- this is only resolved by Javascript because JS is pre-loaded by the browser at all times (in modern browsers at least).
If other plugins were to be marked as 'frequently used' by the plugin engine and loaded at runtime instead of page load-time, they'd obviously be just as responsive as Javascript (or more so, since Java is compiled to native code in many cases).
Making a browser that integrates Java in a reasonable way and makes it work just as seamlessly as Javascript was tried already (by Netscape) but it was before we had computers with enough RAM to handle it IMHO.
- Michael T. Babcock (Yes, I blog)
Microsoft is doing something similar and is, in fact, presenting a talk today on leveraging legacy code to deploy desktop applications on the web.
You can find more details here.
x86 code runs natively on 90% of the processors out there. Java or .NET bytecode runs natively on about 0% of them (Sun did have a Java chip once but it is long dead). So it is hardly any worse than the alternatives. There are many x86 emulators and some of them have reasonable performance.
If we were starting from scratch now, nobody would choose the barnacle-encrusted i386 instruction set as a way to distribute programs. But given the hardware and software that exists, it's not such a bad choice.
Of course, the way to do it is to define what instruction sequences are safe and allow only those. I assume that's what they are doing and 'modules may not contain certain instruction sequences' is just the one-line summary.
That said, you can make any instruction sequence you like using the assembler and run it on your Linux system, and it cannot break out of the process virtual machine to access hardware or memory belonging to other processes or the kernel. If it can, this would be a bug in Linux. So there is no reason why arbitrary instruction sequences couldn't be allowed in principle, if you let the operating system do the work of sandboxing the process. After all why reinvent the wheel?
-- Ed Avis ed@membled.com
I do. And so can you. It's the C-based syntax that throws most programmers for a loop. Once you realize that the language is actually of a functional design similar to LISP, everything gets a lot easier.
Javascript has one of the most flexible Object systems I have seen in my 20+ years of programming. And its typing system is actually quite strong. Like another poster mentioned, it's dynamically typed not weakly typed. Which is an issue that fades into obscurity once you understand how to properly utilize the language.
Javascript (like most functional languages) is perfect for building large apps out of a massive number of small bits. Look up scoping in Javascript sometime and you'll understand that larger apps get built by having machines within machines within machines to go from simple tasks to ever more complex tasks. It is, in many ways, a more scalable solution than APIs and packaging. But it is different and therein lies the crux of its failure in the minds of many programmers.
Javascript + Nintendo DSi = DSiCade
Pretty much all of Sun's offerings have HotSpot built in, which provides JIT compilation for the JVM. IBM's JVM, BEA, etc. all have JIT features. Google's Android has Java-like Dalvik, which is slow as balls and doesn't have JIT functionality.
Some ARM processors are capable of executing Java bytecode natively. The device developers have to pay for that feature though.
Really, it sounds like Google is poorly trying to reinvent Java. They've tried this with Android already and it doesn't work so hot from a performance standpoint.
Mod me down, my New Earth Global Warmingist friends!
I also noticed that Google is very aggressively trying *not* to use Java JRE anywhere, as Dalvik VM or this x86 nonsense demonstrate. I have no idea why is that, given Java and JRE are FOSS now. One thing is for sure: Their Google Docs and other office-like applications would only start to make much more sense if they use new JavaFX clients (that can be dragged from browser to desktop, becoming standalone app) alongside with improving JRE support in Chrome and Firefox.
839*929
Two reasons they didn't use a JVM for Android:
1) They started the Android project before Java was open-sourced.
2) Sun has slightly different licenses for desktop and mobile use. The desktop license is GPL with a classpath exception (letting you write non-GPL java apps to run on the virtual machine), the mobile license is straight GPL. Google didn't want to force developers to only produce GPL apps for Android, so they could not use this.
See Stefano's blog