Google Chrome gets friendly with Native Client
Google pushed out version 4.0.220.1 of its Chrome browser on Friday and it comes loaded with a number of fixes and features, including the debut of Native Client on Microsoft’s Windows OS. The nifty Native Client (or NaCl) open source tech has been developed for running x86 native code in web apps. By slotting it into Chrome, …
This topic is closed for new posts.
Ho hum
And I thought that the point of HTML, Java et al was to make web browsing hardware independent. Then Google come along with an idea like this. It's bad enough that web developers often need to code and test for different browsers, this will presumably mean they will need to code and test for hardware as well.
Flash and then some
I've just read the research paper, and the claim that this is portable is complete horseshit. It only runs on an x86 platform, and even if it was to be made portable then performance would be awful. As performance is the only claimed benefit of this technology then it should be take out and shot. ARM netbooks are available and likely to increase their market share, so despite Apple switching to x86 from PowerPC it's far from an x86 only world.
On the security side of things, creating a sandbox for a Java virtual machine with it's straightforward byte code is one thing, but a sandbox for a whole x86 environment?
It's just another awful technology like Flash that if it gains traction will lead to further balkanisation of web content
Maybe it is for flash?
Maybe this is for hosting flash. I can't see any other reason to download and run x86 code in a browser. Me, I will stick to Firefox for the sake of FlashBlock and AdBlock
Is it me or does this sound like ActiveX?
Following the great tradition of posting comments without understanding the problem fully in the first place, I thought I'd ask the question...
NaCl
Salt or Nacelle?
Salt of the Earth Or Warp Drive?
Thats one for the scientists and trekkies to fight over!
ActiveX redux?
This sounds like Microsoft's old ActiveX, which (thankfully) died, forgotten in the dustbin of history. We have Java and .NET (Silverlight) --- both fine and TRULY portable technologies that get compiled down to machine code and run almost as fast as a typical C++ program. If Google wants its client-side apps to run faster than JavaScript, why doesn't it consider using this technology?
Why do we need to turn the clock back?
@Parax
Perhaps they wish to salt the web? Poisoning the land so that only app powered by Google genes can flourish?
And people think MS is evil....
@Parax & TheBigYin
That's a point, I can't believe this article had no salt puns.
Come on The Register, what are you playing at? I shall take my business elsewhere if this continues...
Highly related
See here for more laughs:
http://www.theregister.co.uk/2008/12/15/dziubba_nativ_client/
Surely, adding NaCl to Chrome ...
... is just inviting rust.
The only thing new in software...is that there's nothing new in software
Ahh, Google reach Stage Four of the rise and fall of great IT companies. The stages being Startup, Innovation, Dominance, Hubris and Death. A marker of hubris is to reinvent the wheel "only this time do it better". Virtualization is a classic, recurrent theme here and almost invariably ends up dying in the Tarpits Of Performance, a strange place where the promise of new hardware dangles acceptable ops/sec in front of the designer but never quite delivers.
In this case the tarpits have claimed yet another scalp. Face it boys and girls, nothing runs as fast as code for the metal you are running it on. Either learn to live with it, throw a lot of hardware at it (not PC hardware, I'm talking the z/VM approach) or spread the load over nodes by cheating (X window terminals, arise)
read the paper on it
it's at <http://nativeclient.googlecode.com/svn/trunk/src/native_client/documentation/nacl_paper.pdf>. I read it a while back and it impressed me with its elegant, lightweight, native sandbox implementation. It seemed very neat indeed, but then it did rely on x86 hardware specifically, hence nonportable. Which is the killer IMO.
It does not seem to me like activeX nor flash nor silverlight, it's a *sandboxing* facility that can run stuff within at near-full speed. I guess it borrows a little from the jvm in that it examines loaded code and verifies it in a very simple way (requiring said code to have its (subset of x86) instructions laid out in a specific way to make the examination both simple and complete; that modified layout is not onerous at all).
Having talked it up, I must say I *still* don't want it in a browser.
ho ho
Have introduced Chrome Frame into Microsoft Explorer, they obviously want to rub NaCl into the wound.
Windows apps on non-WinTel. Make it a x86 emulation, Google could buy wine and/or ReactOS
Thanks to @BlueGreen for doing the hard work and reading the white paper. I agree that reliance on x86 hardware limits NaCl.
However, if an x86 emulator was built and google ported free WIN32/Windows OS alternatives such as WINE and/or ReactOS into Chrome then one could run standard Windows applications within Chrome independent of hardware.
Which makes ChromeOS on alternatives to x86 such as ARM more appealing as it cirumvents the blocker: "compatibility is the enemy of competition" because access to the vast, comprehensive x86 Windows application base would be available on non-x86 and non-Windows machines. Non-x86 netbooks suddenly become more appealing with the WinTel monopoly challenged.
Sure, an x86 emulation on non-x86 will run slower than on x86 hardware but it might still be usable. Perhaps some clever folk could come up with optimisations such as JIT. Lots of expertise out there regarding emulation: consider Apple's Rosetta for running PowerPC based programs on their Intel machines.
Will Google buy WINE and/or ReactOS? Perhaps at least we can expect more Google Summer-of-Code seasons where these programs are developed.
This topic is closed for new posts.
