Why Google native client will make game developers and consumers happy [video](venturebeat.com)
venturebeat.com
Why Google native client will make game developers and consumers happy [video]
http://venturebeat.com/2011/12/09/why-google-native-client-will-make-game-developers-and-consumers-happy-video/
9 comments
Impressive, everything worked fine (Linux).
Native Unity3D support is a huge thing. Right now Unity games run in the browser via a plugin. The plugin installation is a single click, fairly transparent and doesn't require administrator access, but for the average user it's scary. Who trusts a plugin? It's reported as the number 1 turn-off for users.
> Right now Unity games run in the browser via a plugin. The plugin installation is a single click, fairly transparent and doesn't require administrator access, but for the average user it's scary. Who trusts a plugin? It's reported as the number 1 turn-off for users.
1. This is still a plugin. NaCl uses the Pepper plugin API. That it is bundled in Chrome doesn't make it not a plugin (Chrome also bundles Flash, and that is still a plugin.)
2. The Unity3D plugin will at least work in multiple browsers, while using NaCl will only work in Chrome.
3. It is true though that, as you say, having a plugin pre-installed as in Chrome is less scary for users. However, it still has all the other problems that plugins have, and as mentioned that it is Chrome-specific.
1. This is still a plugin. NaCl uses the Pepper plugin API. That it is bundled in Chrome doesn't make it not a plugin (Chrome also bundles Flash, and that is still a plugin.)
2. The Unity3D plugin will at least work in multiple browsers, while using NaCl will only work in Chrome.
3. It is true though that, as you say, having a plugin pre-installed as in Chrome is less scary for users. However, it still has all the other problems that plugins have, and as mentioned that it is Chrome-specific.
The difference is this one plugin is capable of covering much more ground than Unity3D alone. Once it's there, nothing stopping one from porting, say, id Tech, Unreal, Frostbite, RenderWare, OGRE, Avalanche, Crystal, CryEngine, EGO, Source, etc. to NaCl and running it in the same plugin. Say what you will about Google's strategy, it opens up quite a few possibilites.
> The difference is this one plugin is capable of covering much more ground than Unity3D alone. Once it's there, nothing stopping one from porting, say, id Tech, Unreal, Frostbite, RenderWare, OGRE, Avalanche, Crystal, CryEngine, EGO, Source, etc. to NaCl and running it in the same plugin.
That's already possible with the Flash plugin using Alchemy. There are demos of several of those game engines running in it.
It is also possible to compile those technologies to JavaScript and run them without plugins at all (using Mandreel or Emscripten), but the experience would be less uniform (results would be different in different browsers), which is probably why it hasn't been done yet.
That's already possible with the Flash plugin using Alchemy. There are demos of several of those game engines running in it.
It is also possible to compile those technologies to JavaScript and run them without plugins at all (using Mandreel or Emscripten), but the experience would be less uniform (results would be different in different browsers), which is probably why it hasn't been done yet.
I've worked extensively with Alchemy and Haxe (which can use Alchemy op-codes for near-direct memory access).
And, recently, started with NACL.
Games are extremely performance-intensive. Its simply crazy to pick a platform that is any factor slower when you have a faster alternative to hand.
NACL is a whole new level of possible. I think its going to succeed technically where Flash and plugins failed.
And, recently, started with NACL.
Games are extremely performance-intensive. Its simply crazy to pick a platform that is any factor slower when you have a faster alternative to hand.
NACL is a whole new level of possible. I think its going to succeed technically where Flash and plugins failed.
I don't think there is any disagreement about the speed. NaCl will be faster than Flash and other options.
But consider that Alchemy will run in 98% of web browsers (because that is how much range Flash has), while NaCl will only run in Chrome. So there is a difference of about 4X in market share.
I'm not saying Alchemy is a perfect solution. Each option in this area (Alchemy, NaCl, JS) has different advantages and disadvantages.
But consider that Alchemy will run in 98% of web browsers (because that is how much range Flash has), while NaCl will only run in Chrome. So there is a difference of about 4X in market share.
I'm not saying Alchemy is a perfect solution. Each option in this area (Alchemy, NaCl, JS) has different advantages and disadvantages.
Emscripten is not a viable alternative. The Javascript it generates is too slow for performance intensive things, which is the whole point of NaCl. Flash is too unstable.
> Emscripten is not a viable alternative. The Javascript it generates is too slow for performance intensive things
Is 3-4X slower than native code "too slow"? Those are the results right now. And it will be much faster as JS engines continue to improve.
Is 3-4X slower than native code "too slow"? Those are the results right now. And it will be much faster as JS engines continue to improve.
Absolutely.
Think about it this way: "4x slower than native code" means that 80% of the CPU's cycles are being spent on the platform.
With NaCl, it becomes possible to instead spend most of those cycles on extra application richness without sacrificing the customer experience by requiring an installer or plugin.
Think about it this way: "4x slower than native code" means that 80% of the CPU's cycles are being spent on the platform.
With NaCl, it becomes possible to instead spend most of those cycles on extra application richness without sacrificing the customer experience by requiring an installer or plugin.
That can be true, but based on my experience in the game industry it isn't necessarily the case.
Often a game will be GPU-bound, in which case the JS, Flash and NaCl versions will all have the same bottleneck, GPU shaders (in fact for this reason more and more is done in scripting languages in game engines these days). If that is the case, you might as well use JS, since it will run in many more places than Flash or NaCl.
But again, there are situations where you are CPU bound, and in that case CPU speed does matter - you are very correct in those cases. Currently JS is indeed at a disadvantage compared to NaCl in that area, however, I believe that it will match it in time (through a combination of API additions like Intel's RiverTrail, and further improvements to JS engines like static analysis). The real question is then, will NaCl fix its problems (portability, adoption in browsers other than Chrome) before JS fixes its problem (speed). My bet is on JS.
Often a game will be GPU-bound, in which case the JS, Flash and NaCl versions will all have the same bottleneck, GPU shaders (in fact for this reason more and more is done in scripting languages in game engines these days). If that is the case, you might as well use JS, since it will run in many more places than Flash or NaCl.
But again, there are situations where you are CPU bound, and in that case CPU speed does matter - you are very correct in those cases. Currently JS is indeed at a disadvantage compared to NaCl in that area, however, I believe that it will match it in time (through a combination of API additions like Intel's RiverTrail, and further improvements to JS engines like static analysis). The real question is then, will NaCl fix its problems (portability, adoption in browsers other than Chrome) before JS fixes its problem (speed). My bet is on JS.
Yes, but NaCl provides direct access to GPU interface libraries. You can code for OpenGL directly, rather than running your graphics code through several layers of abstraction, slowing it down exponentially along the way.
There is, to some extent; hardware acceleration for canvas. But I don't expect that to be at all comparable to native OpenGL for awhile yet. JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.
Another important thing to consider is that the native API will always have to exist before a Javascript abstraction can. Many triple-a titles will use brand new GPU features to sell the newest line of graphics cards. That won't work if they are making a browser game and the required interface to do those things doesn't exist yet. Javascript will always be chasing the tail of native.
There is, to some extent; hardware acceleration for canvas. But I don't expect that to be at all comparable to native OpenGL for awhile yet. JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.
Another important thing to consider is that the native API will always have to exist before a Javascript abstraction can. Many triple-a titles will use brand new GPU features to sell the newest line of graphics cards. That won't work if they are making a browser game and the required interface to do those things doesn't exist yet. Javascript will always be chasing the tail of native.
> Yes, but NaCl provides direct access to GPU interface libraries. You can code for OpenGL directly, rather than running your graphics code through several layers of abstraction, slowing it down exponentially along the way.
If shaders are the bottleneck, and not graphics calls, then NaCl and JS will be the same.
If graphics calls are the bottleneck, then sure, NaCl will be faster - but likely you need to do more batching in your GL code.
> JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.
NaCl is essentially also running in a VM: It's sandboxed, so it has performance limitations. There are types of code that run slowly in NaCl, just like in the JVM. However, VM code can be fairly fast in general, the JVM and NaCl are speedy on a lot of code.
The point though is that JS can be fast too - once it has as many years of effort put into it as the JVM and native compilers has, it will be. It's just still very new. "Being in a VM" is not the issue.
If shaders are the bottleneck, and not graphics calls, then NaCl and JS will be the same.
If graphics calls are the bottleneck, then sure, NaCl will be faster - but likely you need to do more batching in your GL code.
> JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.
NaCl is essentially also running in a VM: It's sandboxed, so it has performance limitations. There are types of code that run slowly in NaCl, just like in the JVM. However, VM code can be fairly fast in general, the JVM and NaCl are speedy on a lot of code.
The point though is that JS can be fast too - once it has as many years of effort put into it as the JVM and native compilers has, it will be. It's just still very new. "Being in a VM" is not the issue.
It's depressing to me that NaCl people frequently emphasize the "great piles of existing code" out there, and how "the biggest deal is that there are all these existing code bases", and how well they'll run on NaCl.
I'd feel better about NaCl if they talked more about why their design might make sense for the web in the long term, rather than just why it's going to be popular in the short term.
I'd feel better about NaCl if they talked more about why their design might make sense for the web in the long term, rather than just why it's going to be popular in the short term.
[deleted]
In someways I feel fortunate to not work in gaming. There are so many platforms and languages you've got to hit and probably by the time you've gotten your game's reach maximized the landscape has totally changed. I know Unity is helping to solve this problem but from an outsider's perspective it almost seems like there needs to a really strong standards group like the w3c (maybe there is one for gaming?)
Couldn't help but notice how often he shakes his head as he's saying something positive, as though he doesn't believe what he's saying...
He's an engineer. He probably was thinking about all the ifs and "but technically this is quite exactly like that" of each one of the statements he was making.
I often go to conferences to demo my project and I have the same habit. I try to explain the positive of my project but I know all the dirty secrets ;p
I often go to conferences to demo my project and I have the same habit. I try to explain the positive of my project but I know all the dirty secrets ;p
Had to watch because of that :)
He just looks kind of nervous to me.
First they came for the gamers, and I said nothing, for I wasn't a gamer, and already that industry was infested with proprietary tech.
Then they came for the alternative browsers, and I said nothing, for I was content to see a plug-in extending support for all those games to the rest of the world (even though the alternative vendors all objected verbosely).
Then they came for Google Earth, and I said nothing, for it was a perfect fit to the platform, and I could use Earth from any browser (even though I had to install the plug-in to use it in future).
Then they came for the video codecs, and I said nothing, for what could be wrong with smoother video working across browsers (even though I had to install the plug-in to get there, and YouTube.com suddenly grew a form of DRM).
Then they came for the Internet banks, returning to the 20th century ActiveX-alike requirements for login, and I said nothing (because I needed access to my bank).
Then they came for the well-suited open source projects, and I said nothing, for I didn't care about that, and running Audacity from a browser sounded great.
Then it ran on Android and Chrome OS, and I was pleased (even though I could no longer write native code for Android that didn't target NaCl).
[...]
Then they came for me, and there was no-one left to speak out for me or my app, for there was only one platform left that ran on every device.
Then they came for the alternative browsers, and I said nothing, for I was content to see a plug-in extending support for all those games to the rest of the world (even though the alternative vendors all objected verbosely).
Then they came for Google Earth, and I said nothing, for it was a perfect fit to the platform, and I could use Earth from any browser (even though I had to install the plug-in to use it in future).
Then they came for the video codecs, and I said nothing, for what could be wrong with smoother video working across browsers (even though I had to install the plug-in to get there, and YouTube.com suddenly grew a form of DRM).
Then they came for the Internet banks, returning to the 20th century ActiveX-alike requirements for login, and I said nothing (because I needed access to my bank).
Then they came for the well-suited open source projects, and I said nothing, for I didn't care about that, and running Audacity from a browser sounded great.
Then it ran on Android and Chrome OS, and I was pleased (even though I could no longer write native code for Android that didn't target NaCl).
[...]
Then they came for me, and there was no-one left to speak out for me or my app, for there was only one platform left that ran on every device.
Note that NaCl has shifted from the NPAPI to the Pepper API, so there actually isn't a plugin that extends support to alternative browsers. You have to use Chrome.
NaCl is open source, though, so if it gains traction other browsers will start to support it.
So far, Mozilla has explicitly stated that they won't adopt it, citing philosophical differences.
As has Opera,
http://www.theregister.co.uk/2010/10/01/opera_on_google_nati...
Microsoft and Apple have not bothered to go on the record on the topic yet, but I would bet their position is similar.
http://www.theregister.co.uk/2010/10/01/opera_on_google_nati...
Microsoft and Apple have not bothered to go on the record on the topic yet, but I would bet their position is similar.
That's easy for them to say now. If NaCl becomes the new hot thing, Mozilla will probably change their line.
Sigh, same person, argument and lack of logic as when this conversation played out here 3 days ago [1]. You continue to act like this will destroy HTML, remove it or something. This comment doesn't even make sense in a variety of ways:
>I could use Chrome from any browser
What?
>YouTube.com suddenly grew a form of DRM
How is that related to VP8? So because Google came up with a codec to (try and) avoid the patent mess surrounding h264, they're now going to use it to push DRM on Youtube? What a fantastically unsupported claim.
>returning to the 20th century ActiveX-alike requirements for login
Here you are again implying that somehow the introduction of NaCl will block us from "our data". An accusation that you completely failed to substantiate in the other discussion. Your reply there and continuation here implies that you don't understand what NaCl is [2].
>even though I could no longer write native code for Android that didn't target NaCl
So? What is the difference between writing native code that targets the Android NDK, and writing native code that runs in NaCl. (First of all, the code should be fairly similar anyway, but more importantly,) you still have to make a choice about which platform to target.
>for there was only one platform left that ran on every device.
What platform easily runs on all devices? How does NaCl remove the ability to use any others? Why does NaCl somehow prevent me from using everything in the Chrome stack except NaCl? Am I forced into it?
Again, it's just another technology to be added to the web stack. Hopefully it sees more widespread adoption. Stop your fear mongering. Especially when you couldn't even articulate good responses to the criticisms of your original paranoid blog post.
[1] http://news.ycombinator.com/item?id=3322280
[2] http://news.ycombinator.com/item?id=3322521
>I could use Chrome from any browser
What?
>YouTube.com suddenly grew a form of DRM
How is that related to VP8? So because Google came up with a codec to (try and) avoid the patent mess surrounding h264, they're now going to use it to push DRM on Youtube? What a fantastically unsupported claim.
>returning to the 20th century ActiveX-alike requirements for login
Here you are again implying that somehow the introduction of NaCl will block us from "our data". An accusation that you completely failed to substantiate in the other discussion. Your reply there and continuation here implies that you don't understand what NaCl is [2].
>even though I could no longer write native code for Android that didn't target NaCl
So? What is the difference between writing native code that targets the Android NDK, and writing native code that runs in NaCl. (First of all, the code should be fairly similar anyway, but more importantly,) you still have to make a choice about which platform to target.
>for there was only one platform left that ran on every device.
What platform easily runs on all devices? How does NaCl remove the ability to use any others? Why does NaCl somehow prevent me from using everything in the Chrome stack except NaCl? Am I forced into it?
Again, it's just another technology to be added to the web stack. Hopefully it sees more widespread adoption. Stop your fear mongering. Especially when you couldn't even articulate good responses to the criticisms of your original paranoid blog post.
[1] http://news.ycombinator.com/item?id=3322280
[2] http://news.ycombinator.com/item?id=3322521
Yes, I said "Chrome" instead of "Earth", but if you were so incompetent as to not understand the intent, then I shouldn't be replying at all here, but I'll give you the benefit of the doubt.
I can see nothing but personal malcontent seeping through in this reply. Your perspective seems to be "this person is steadfast in his opinion that this is somehow wrong here, but I disagree, therefore I must accuse him of fearmongering", or something (what if instead I accuse you of "trust-mongering"?).
To reply to your previous, obviously incompletely unanswered comment: the entire purpose of the original article is to read between the lines and attempt to imagine a future where NaCl gets traction. Your original comment seems to be "this is not reality, therefore no". Simply replying by suggesting you lack imagination would have likely have caused offence (and an even more vitriolic response), so instead I chose to define the word 'conspiracy' as a hint for you instead.
The remainder of your comments are asking for science where there is none, please don't do that. If you are unwilling to comment on speculation, understanding the context under which speculation occurs, you have nothing to offer here.
I can see nothing but personal malcontent seeping through in this reply. Your perspective seems to be "this person is steadfast in his opinion that this is somehow wrong here, but I disagree, therefore I must accuse him of fearmongering", or something (what if instead I accuse you of "trust-mongering"?).
To reply to your previous, obviously incompletely unanswered comment: the entire purpose of the original article is to read between the lines and attempt to imagine a future where NaCl gets traction. Your original comment seems to be "this is not reality, therefore no". Simply replying by suggesting you lack imagination would have likely have caused offence (and an even more vitriolic response), so instead I chose to define the word 'conspiracy' as a hint for you instead.
The remainder of your comments are asking for science where there is none, please don't do that. If you are unwilling to comment on speculation, understanding the context under which speculation occurs, you have nothing to offer here.
Your reply on the other thread focused on a word that I even specifically said was not meant as derogatory, and you ignored all of the rest of it, much as you've done here.
I commented on your speculation. Your speculation is an absurdity without any logic as to how we get from "NaCl is available" to "NaCl is the only usable platform on the Internet", which is precisely fear-mongering.
>this person is steadfast in his opinion that this is somehow wrong here
It's fine if you would like to think that, I think you are steadfast and I'm not sure if you're wrong because I flat out don't understand how you reach your extreme conclusion. It's why I keep trying to engage in a conversation about this and understand where you're coming from. And I continue to be surprised that with the veracity of your opinion, you seem unwilling to actually talk about it more than an unsubstantiated extreme. (For example, there are probably 4 other direct replies and criticisms of your logic that you just completely ignored. As well the same thing happening in the previous thread.)
(my apologies on the Chrome/Earth thing, I assure you I wasn't intentionally being stubborn, I was legitimately confused)
I commented on your speculation. Your speculation is an absurdity without any logic as to how we get from "NaCl is available" to "NaCl is the only usable platform on the Internet", which is precisely fear-mongering.
>this person is steadfast in his opinion that this is somehow wrong here
It's fine if you would like to think that, I think you are steadfast and I'm not sure if you're wrong because I flat out don't understand how you reach your extreme conclusion. It's why I keep trying to engage in a conversation about this and understand where you're coming from. And I continue to be surprised that with the veracity of your opinion, you seem unwilling to actually talk about it more than an unsubstantiated extreme. (For example, there are probably 4 other direct replies and criticisms of your logic that you just completely ignored. As well the same thing happening in the previous thread.)
(my apologies on the Chrome/Earth thing, I assure you I wasn't intentionally being stubborn, I was legitimately confused)
My apologies, I intentionally try to make terse replies to keep S/N as high as possible, often people will attempt to highlight the same problem they have from multiple angles. In any case, my reply above was unsatisfactory, and that was most likely due to my alcohol intake at the time (on a revelry weekend with a friend in the middle of the Baltic). :-)
I'll attempt to reply again, and address each of your points. The initial 'suspicion' is largely based on how heavily NaCl has been getting pushed in recent times, it is of strategic importance to the company somehow, and that is what interests me. Whether or not my opinion turns out to be correct or not, largely to me is immaterial, it's just sufficient that it is possible for some strategy involving NaCl to result in an endgame where vendors competing in the platforms space suddenly find themselves with a fundamentally compelling competitor that they can't easily fight against.
As for why there is a conspiratorial tone to the article, well, that's simply because I do not trust the company in the long term (as stated somewhere in the comments).
On to your specific replies:
> How is that related to VP8?
NaCl may well be a vaguely open platform for the time being, but in the long term, and crucially, as it gathers mass acceptance, it is also a platform on which the better resourced players in various ongoing wars can easily be victorious, and that is where the video connection appears.
Video decoding is a natural use case for NaCl (fast graphics output, fast network input, efficient on CPU), I'd be dearly surprised if within 2 years of its mass deployment, some video vendor, somewhere, decided to tie their tweaked h.264-alike together with some crypto code and market it as a "secure content delivery platform", in a similar vein to the kind of capabilities (much loved by content providers) available in Flash today (RTMPE).
It's not a question of fear mongering, it is a question of whether or not it is technically possible, and if so, whether some company, somewhere would be willing to pay for it. In the DRM'd video case, I believe the answer here is an unquestionable yes.
For another perspective, BBC.co.uk only recently switched to Flash for the majority of their content, not because it is somehow technically superior to RealPlayer (their previous choice), but most likely owing to whatever commercial agreements between the two companies finally expired. Faced with a well resourced salesman and a proprietary video technology, guaranteed agreements like this will appear in the future given a suitable platform for the technology implementation.
The (not too far fetched, I believe, and certainly not "fantastically unsupported") conclusion is that if a fast platform for networking/graphics powered by binary blobs becomes widely deployed, it will likely be used to close up or at least occlude the openness of content on at least a few of the larger sites.
> Here you are again implying that somehow the introduction of NaCl will block us from "our data".
This follows in a similar vein to the previous answer: given a technology, you can be assured someone will make use of it in some arbitrarily stupid/inconvenient way. Banks already proved their ridiculous approaches to security in the 00's by wrapping their login processes up in ActiveX controls. I will happily put large sums of money on this reappearing if NaCl or a similar technology gains widespread deployment (many banks to this day still insist on Java).
> What is the difference between writing [...] that runs in NaCl.
> What platform easily runs on all devices? How does NaCl remove the ability to use any others?
I actually did write the answer to this previously. Once a platform gains critical mass and gets deployed everywhere (especially because the controlling company has easy access to a huge audience to which to sell it), and that platform is controlled by a single vendor, you may suddenly find yourself in the undesirable situation of being forced to use that vendor in order to reach your customers (or even before your customers will buy from you!). Given the privileged position of that vendor, you can only pray to your deities the vendor never chooses to compete in your problem space, as inevitably they are in a much better position to extend the platform as they desire to make it much more compelling or economical for 3rd parties to use their solution, rather than yours.
This has happened repeatedly in a million different fields, not least there still exists a huge number of corporations who won't touch anything that doesn't run on Microsoft, or at least talk to Active Directory. Is it so far fetched to imagine a world where a company won't touch your small company's solution because it doesn't speak Google Authentication or Google Contacts API?
There are a million Microsoft comparisons to be made here. Already, in the right light, you could consider Google's approach to advertising their products as abusive. By dropping a single link (at a cost of near zero) on their front page, over half the Internet is likely to see that advertisement at least once a day.
It bares little effort to make comparisons to a time when Microsoft had a dominant technology base and range of products that allowed them to almost force Netscape off the market. A little word in the ears of their sales channel guys (Google home page) a little bundling here ("get Chrome with Google Earth today!"), and a little integration there ("now seemlessly switch to Earth view via maps API.. no code changes required!"), and competing browsers might find themselves increasingly impotent. [Note, I used as an example here Google Earth as being the thing promoted unfairly, at the disadvantage of other mapping providers, however the text speaks about browsers.. just make up some example of your own, it's not hard]
--
To claim this is "just another technology" is as if to claim around the time NT was shipping that Win32 was "just another bundle of APIs". You totally ignore the positioning of the company behind those APIs, the company's long term goals, and totally ignore the company survival instincts, as the profits of each market they enter slowly reaches plateau, and their need to expand yet more in the name of maintaining shareholder yields.
If you'd like, I am happy to reply further to your other comment, but already this one has taken nearly half an hour.
I'll attempt to reply again, and address each of your points. The initial 'suspicion' is largely based on how heavily NaCl has been getting pushed in recent times, it is of strategic importance to the company somehow, and that is what interests me. Whether or not my opinion turns out to be correct or not, largely to me is immaterial, it's just sufficient that it is possible for some strategy involving NaCl to result in an endgame where vendors competing in the platforms space suddenly find themselves with a fundamentally compelling competitor that they can't easily fight against.
As for why there is a conspiratorial tone to the article, well, that's simply because I do not trust the company in the long term (as stated somewhere in the comments).
On to your specific replies:
> How is that related to VP8?
NaCl may well be a vaguely open platform for the time being, but in the long term, and crucially, as it gathers mass acceptance, it is also a platform on which the better resourced players in various ongoing wars can easily be victorious, and that is where the video connection appears.
Video decoding is a natural use case for NaCl (fast graphics output, fast network input, efficient on CPU), I'd be dearly surprised if within 2 years of its mass deployment, some video vendor, somewhere, decided to tie their tweaked h.264-alike together with some crypto code and market it as a "secure content delivery platform", in a similar vein to the kind of capabilities (much loved by content providers) available in Flash today (RTMPE).
It's not a question of fear mongering, it is a question of whether or not it is technically possible, and if so, whether some company, somewhere would be willing to pay for it. In the DRM'd video case, I believe the answer here is an unquestionable yes.
For another perspective, BBC.co.uk only recently switched to Flash for the majority of their content, not because it is somehow technically superior to RealPlayer (their previous choice), but most likely owing to whatever commercial agreements between the two companies finally expired. Faced with a well resourced salesman and a proprietary video technology, guaranteed agreements like this will appear in the future given a suitable platform for the technology implementation.
The (not too far fetched, I believe, and certainly not "fantastically unsupported") conclusion is that if a fast platform for networking/graphics powered by binary blobs becomes widely deployed, it will likely be used to close up or at least occlude the openness of content on at least a few of the larger sites.
> Here you are again implying that somehow the introduction of NaCl will block us from "our data".
This follows in a similar vein to the previous answer: given a technology, you can be assured someone will make use of it in some arbitrarily stupid/inconvenient way. Banks already proved their ridiculous approaches to security in the 00's by wrapping their login processes up in ActiveX controls. I will happily put large sums of money on this reappearing if NaCl or a similar technology gains widespread deployment (many banks to this day still insist on Java).
> What is the difference between writing [...] that runs in NaCl.
> What platform easily runs on all devices? How does NaCl remove the ability to use any others?
I actually did write the answer to this previously. Once a platform gains critical mass and gets deployed everywhere (especially because the controlling company has easy access to a huge audience to which to sell it), and that platform is controlled by a single vendor, you may suddenly find yourself in the undesirable situation of being forced to use that vendor in order to reach your customers (or even before your customers will buy from you!). Given the privileged position of that vendor, you can only pray to your deities the vendor never chooses to compete in your problem space, as inevitably they are in a much better position to extend the platform as they desire to make it much more compelling or economical for 3rd parties to use their solution, rather than yours.
This has happened repeatedly in a million different fields, not least there still exists a huge number of corporations who won't touch anything that doesn't run on Microsoft, or at least talk to Active Directory. Is it so far fetched to imagine a world where a company won't touch your small company's solution because it doesn't speak Google Authentication or Google Contacts API?
There are a million Microsoft comparisons to be made here. Already, in the right light, you could consider Google's approach to advertising their products as abusive. By dropping a single link (at a cost of near zero) on their front page, over half the Internet is likely to see that advertisement at least once a day.
It bares little effort to make comparisons to a time when Microsoft had a dominant technology base and range of products that allowed them to almost force Netscape off the market. A little word in the ears of their sales channel guys (Google home page) a little bundling here ("get Chrome with Google Earth today!"), and a little integration there ("now seemlessly switch to Earth view via maps API.. no code changes required!"), and competing browsers might find themselves increasingly impotent. [Note, I used as an example here Google Earth as being the thing promoted unfairly, at the disadvantage of other mapping providers, however the text speaks about browsers.. just make up some example of your own, it's not hard]
--
To claim this is "just another technology" is as if to claim around the time NT was shipping that Win32 was "just another bundle of APIs". You totally ignore the positioning of the company behind those APIs, the company's long term goals, and totally ignore the company survival instincts, as the profits of each market they enter slowly reaches plateau, and their need to expand yet more in the name of maintaining shareholder yields.
If you'd like, I am happy to reply further to your other comment, but already this one has taken nearly half an hour.
Anybody knows if this will also be available for chrome-frame?
I have a dream that one day we can ditch Javascript (or at least have a choice as to which language we want to write in). It seems so, well, limited.
I have a dream that one day we can ditch Javascript (or at least have a choice as to which language we want to write in). It seems so, well, limited.
this is very cool. Do the native client APIs support alternate input devices such as game controllers?
There is a Gamepad API under development by Mozilla: https://wiki.mozilla.org/GamepadAPI
Just FYI, it's been moved to the Web Events working group:
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.htm...
there's an open mailing list if anyone wants to participate.
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.htm...
there's an open mailing list if anyone wants to participate.
Is this webRTC or something different?
I don't usually post rude "let me google that for you" replies, but I feel oddly compelled to point out that there are faster, easier ways to get that sort of information than posting a comment on a forum. For example:
http://en.wikipedia.org/wiki/WebRTC
http://en.wikipedia.org/wiki/Google_Native_Client
http://en.wikipedia.org/wiki/WebRTC
http://en.wikipedia.org/wiki/Google_Native_Client
This has nothing to do with WebRTC.
WebRTC is a work-in-progress effort by multiple vendors (Google, Mozilla and Opera, and possibly others) to create real-time communication capabilities for the web, like voice and video.
NaCl is a Google-specific technology for running native code inside Chrome.
WebRTC is a work-in-progress effort by multiple vendors (Google, Mozilla and Opera, and possibly others) to create real-time communication capabilities for the web, like voice and video.
NaCl is a Google-specific technology for running native code inside Chrome.
[1]: https://chrome.google.com/webstore/detail/oohphhdkahjlioohba...