Slashdot Mirror
Google Demonstrates Chrome Native Client With Bastion
Multiple readers sent word that Bastion, an action RPG from indie developer Supergiant Games originally made for Xbox Live Arcade, has shown up in the Chrome Web Store. The purpose of the move is to showcase the browser's Native Client technology. From the article:
"Ian Ellison-Taylor, Google's director of product management for the open Web platform, said that Native Client, also called NaCl, can currently improve browser performance by 1 to 10 times. 'What would it be like if we could run native code inside the browser,' he asked the crowd, and he enumerated two goals for the Native Client project. He said Google wants to bring native applications to the Web for performance and security reasons, and it wants to enrich the Web ecosystem by bringing popular, long-in-use programming languages to the Web."
This is so revolutionary. Now we can run native applications on our computers! Just imagine the possibilities! Oh, wait. We already can. And they aren't inhibited by some horrid browser-based sandbox.
can currently improve browser performance by 1 to 10 times
- this reminds me of the quote from the historical documents:
-Good Lord! That's over 5000 atmospheres of pressure!
-How many atmospheres can the ship withstand?
-Well, it was built for space travel, so anywhere between zero and one.
You can't handle the truth.
Like I really want anyone and their uncle to be running native code on my machine. We went to a sandbox model for a reason! If this is active now, how do we shut it off?
1. 2.
I tried Bastion this morning on my arguable beefy 8-core 8 GB machine. SLOW AS SNOT. So either it's slow or I need to change some configuration setting. Maybe I'm missing something, but wasn't doing this crap in the browser supposed to make it "just work" (tm)?
Mad Software: Rantings on Developing So
I am a little uneasy of making a web browser a proprietary platform. PcMag had an article about Chrome being the next IE 6 of the browser wars 2.0.
IE 6 was a great browser in 2001 regardless of its security shortcomings found years later. Everyone on slashdot back then admitted to using it but were scared and assumed the WWW would die soon because of it. Everyone seems to be oblivious that Google is another evil big corporation no different than Microsoft. Actually synergy is behind Google now, like it was with MS a decade ago.
Dart is chrome only, the javascript libraries are Chrome only or particulary run much better on Chrome (google ones like V8), this and many other proprietary HTML 5 code like that site with the band a few months ago that only work in Chrome. This game will use HTML 5 but has other proprietary hooks to make sure it wont run in any browser.
Google is making it clear they look at the browser as an operating system. At least Microsoft today is running away from ActiveX and trying to do good with IE 10 which will be the most open and standards compliant browser to date. Firefox is dying and is losing popularity. In a year or two from now it will be a IE vs Chrome world.
Anyone else bugged or am I just paranoid? I just want a great browser and not a simple fast one, but with the real goodies underneath it that are dependent on Chrome.
http://saveie6.com/
What would it be like if we could run native code inside the browser?
The massive swamp of security vulnerabilities that was ActiveX?
Can someone describe the differences between NaCl (Salt?) and ActiveX? They both seem to be methods to run native code inside a browser sandbox. What are the ways Google's offering is superior? Is it better at all than the current implementation of ActiveX? I like Google, but this particular initiative seems kind of backwards thinking.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
NaCl defines a subset of x86 instructions that are verifiably type-safe, just as .NET IL and JVM bytecode are verifiably type-safe. The browser verifies the binary before executing it.
For crying out loud, what is it with you wheel freaks? Why do you insist that wheels are the only solution to transportation problems? Why do you get so excited about a technique that's actually quite ancient?
Fuck, I first remember using wheels back in the 1970s on some Ford pintos, and it probably wasn't even a new technique then. All through the 1980s, 1990s and 2000s it became a pretty common feature of most land yachts. Hell, even Chrysler and GM have excellent wheel rotating support, and have had it for a long time. That's not even considering Hyundai, Kia, and the other existing and well-established platforms that have wheels! These days we've also got Saab, BMW and many other systems we can run on roads.
Look, wheel rotation is one transportation technique among many. If getting rid of wheels causes you that much of a problem, THEN YOU'RE DOING TRANSPORTATION REALLY FUCKING WRONG!
FTFY
Run native code WITHOUT the browser. Revolutionary idea, I know. You could pass on all the frameworks required to shoe-horn procedural programming onto a stateless protocol, give HTML and XML markup a miss, not write any javascript, and... just... write an application. And maybe it won't need 34MB to run in, and maybe it'll actually be instantly responsive. Maybe... just maybe... that's what you really need to do.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I'm guessing they mean that you are more secure now that you can run apps in your browser which you previously had to install into your OS. The privileges enjoyed by an NaCl browser app are really minimal compared to the same app installed with admin on Windows (which is how most users do it).
Regarding web standardization, note that NaCl is nothing like Flash or Silverlight: rather then replacing standard web technologies with proprietary technologies, it is primarily a way to optimize pieces of web technology. You take your bundle of HTML/CSS/Javascript and replace pieces of the javascript with native code. And you don't do it with some proprietary google language - you do it (eventually) with whatever language you want.
To me it seems like a reasonable way to move the web forward without subverting it (or even altering it much).
Pepper is the plug-in API that NaCl modules use to communicate with browser-managed resource, JS, etc.
Since NaCl == Sodium Chloride == Salt, let's make this discussion more interesting by replacing all instances of "NaCl" with "salt".
"note that [salt] is nothing like Flash or Silverlight". The first consistently taste great, while the others vary in flavor from one OS to the next. I kid, I kid :)
Native Client is like a plugin that makes all other plugins obsolete.
-It can do everything you can do with Flash, Unity, Silverlight, etc.
-You can use any language to develop for it, C, C++, ObjC, Python, C#, you name it.
-Can access everything JS can (using the Pepper plugin API).
-It's from a trusted vendor (Google), so most people will not be afraid to install it.
-Will come pre-installed in the soon to be most popular web browser.
-It's open source
-It's much more secure than existing plugins due to sandboxing.
And, yes, I can understand HTML5 purists, but the truth is that:
1) Not everything can be made into a web application using HTML5+JS.
2) There's way too much code and applications written in other languages..
3) Cross-Platform web deployment is very attractive. Compile for x86 and ARM and 99.999% of the devices on the planet can be supported.
So, disable it if you don't want it, but this is a very attractive idea with a lot of potential for us developers, and even Adobe is trying somehting similar with Alchemy on Flash. It's a much more realistic way to bring actual real applications to the web than the dream that HTML5+JavaScript is.
Implementing something your own way is evil and proprietary.
Native client is open source. So is chromium.
To me [NaCl] seems like a reasonable way to move the web forward without subverting it (or even altering it much).
There are a few big problems with that:
The web is all about open standards, viewing the same web from any browser or any OS, and so forth. So NaCl, that only runs on two archs and on one browser, is a step backwards.
NaCl is not portable. NaCl apps only run on x86 and x86_64, not ARM or PowerPC or anything else.
NaCL binaries are not portable in the same way I can't install the FireFox's Windows binaries on Linux (or the armel ".deb" from packages.debian.org on my amd64 computer), but honestly, who cares? Mozilla and Debian guys just compile it for each supported platform. There is also the possibility of creating a "fat nexe" that supports all platforms.
As a consequence, NaCl apps only run on Chrome (and on x86 and x86_64).
Is open source code on an open source browser. I would prefer it being a plugin (I think at some point there was one) so I can run it in all my browsers. But this is no different than any other proprietary feature on other browsers. I'm currently using Mozilla's proprietary "crypto" JavaScript API for an application, and it only runs on Mozilla's browsers. Not convenient, for sure, but what should I do? Not use the feature at all? Or try to make something valuable from it, so other developers might consider incorporating it?
Think of how most developers are using Javascript nowadays: it's a target language for their compilers.
Whether the source was Java (GWT compiler) or Javascript itself (YUI compressor, Google closure compiler) the fact remains that what browsers are given to run is not what the developers wrote. Which is standard practice in the software business (it's called compilation) and for good reasons.
Now, JS makes for a poor machine language. So we could either beat around the bush with an intermediate bytecode language (Java went there, and Python and all the others too, with varying results) or go for the real thing and come up with a good x86 sandboxing and code verification standard.
Remember, x86 is currently in use by 99% of desktop machines. When other architectures will gain momentum, websites will just offer two or more compiled versions of their code. In the mean time, they will just have to emulate or translate the x86 instruction set, a task for which a large open source code base has already been developed, and which would still be more efficient than parsing plain Javascript, by several orders of magnitude.
So what's the problem with that, again?
And what happens when I'm browsing the web on my MIPS-based TV? I'm at the mercy of the website author to specifically support my architecture. Today, I can visit any website and it will work. There is no dependency on any architecture specific stuff. Most developers will only bother compiling for x86 and ARM in all probability, which will hurt anyone else.
It is a plugin... using a non-standard, non-documented plugin API, which nobody apart from Chrome supports or has any intention of supporting (it's a huge amount of badly documented, totally web irrelevant, anti-Open-Web chunk of code --- why should anyone take it in?). If they had used the standard plugin API (NPAPI), it would work today in every browser.
And I'm sorry, but this is fundamentally different to a lot of proprietary functionality in other browsers. Most of browser vendors are putting in large amounts of effort into removing old proprietary behaviour and specifying anything they wish to keep. Even Apple when it adds new proprietary behaviour to WebKit typically specifies it. Writing a spec is a big deal: it allows anyone else to write a clean-room implementation, which is often desirable (especially for CSS/DOM extensions: it's practically impossible to share much code without all moving to a single engine). Google hasn't released any spec for NaCl (and neither for the Pepper plugin API it relies upon), the spec it has released for Dart is nowhere near complete enough to allow a new implementation (and it had a several year headstart on implementing --- something that makes their implementation very hard to compete with), the spec for WebM is mostly just a dump of the code of the implementation (it's not really a spec: it's just code and the spec just says "match this").
Sensible people, on the other hand, see sandboxing as just one more tool in the toolbox.
So please enlighten us. How do you run untrusted code on your machine without some kind of sandbox?
Root someone else's machine and run it there.