Slashdot Mirror
Google Is Grooming Chrome As a Game Platform
An anonymous reader writes with this snippet from Conceivably Tech: "On Friday I noticed that Google is heavily pushing New Game, a game developer conference that is focused on HTML5-based gaming content — and, of course, content that runs in web browsers. The fact that such an event already exists and that there is game content being developed in HTML5, is quite stunning by itself. However, Google also noted that a sandboxed native client (NaCl) with 3D (in addition to 2D) will be available in Chrome soon, which will allow the browser to connect to traditional C and C++ code via its integrated Pepper API."
I know Commander Taco used to like games, and now he's not alive to see this. Very sad.
So is Chrome Google's current attempt to finally cut Java out of their web application strategy?
Does anyone else see this as a giant security hole? As in, various schemes like this have been tried since the days of ActiveX, and the only reason ActiveX has the worst reputation is because it's the only one that gained widespread use?
"First they came for the slanderers and i said nothing."
How is using Pepper different than ActiveX with Internet Explorer?
If you use pure html 5 with WebGL or Canvas 3D (for IE 9 or IE 10) you can create 3D games using the hosts GPU. Chrome's 3D and hardware acceleration for html 5 does lag considerable behind Firefox and IE 9/10. I wonder if it is because they want you to use Pepper instead?
Either way their actions go agaisn't the spirit of HTML 5. You can do all of that properly in the latest versions of the browsers that is cross platform.
http://saveie6.com/
I would love to hear the howling if it was microsoft introducing this sandboxed native client.
In other words, a saltbox.
Anybody want a peanut?
This is actually the way its been in Corporate IT for quite a while. It's much easier to make a web app that gets update once on the server than to manage thousands of client updates, worry about security issues, etc. The current place I work about 80% of the applications are web apps with a few ones yet to make the move (MS Office being the primary one, but even that might be changing with Microsoft's cloud pushes).
I've had to use them at work and it doesn't work anywhere near as well as folks think. Granted it probably does work if you've got the server onsite, but really, you shouldn't have a server onsite without a backup. The problems we had were that the server was being run offsite, and consequently whenever the gateway would be down we wouldn't be able to do portions of our job. And even when it wasn't completely down it might be as slow as molasses, which again would hurt productivity.
Sure it's convenient and all, but we're hardly at the point where having a web server handling this sort of thing is wise.
Actually, Google wants to introduce LLVM bytecode, which will run on both x86 and ARM. They're making an OS for ARM processors, you know, they are aware it exists.
x86 is just the first step on the way.
Arguably, we Do Not need ActiveX all over again; but we do need an (actually competent) implementation of what things like ActiveX were trying to accomplish...
.exe that somebody offers them, which isn't exactly a triumph of security(particularly since prompting for elevated rights is standard behavior for installers...)
While it is possible, and sometimes desirable, to increase security just by paring away as much power as you can get away with, that doesn't fly in the broader market. People want their games, and their videos, and whatnot. If they can't get them in-browser, they'll get them by downloading every friendly
If you cannot protect somebody from something running in-browser, you don't actually solve the problem by not trying, you just shove it off onto the OS, which hasn't shown a brilliant track record of protecting people from the things they run, and offers less convenience in things like install/uninstall/update/synchronization...
Turning it on, without prompts, for all domains, by default, unless you are very, very certain is, of course, a terrible plan; but there is nothing fundamentally more hopeless about protecting people from browser plugins than protecting people from downloaded binaries, and history suggests that if they can't have what they want from the former, they'll enthusiastically click through whatever the latter asks them for...
hiring better network personnel might be a concept to consider. Or even a one-time consultant after getting bids and proposals from a few.
or find out who's downloading all the porn.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
This is actually the way its been in Corporate IT for quite a while. It's much easier to make a web app that gets update once on the server than to manage thousands of client updates, worry about security issues, etc.
And before that it was Lotus Notes, and before that it was mainframes and AS/400s, etc. It has always been easier (and arguably better) to run certain types of applications on servers, particularly when the application's purpose is to give an arbitrary number of employees access to the same information store. Where the model has yet to be proven, IMHO, is when the purpose of the application is to enable an individual to perform an individual task (e.g. a word processor or a graphics program).
Breakfast served all day!
you just shove it off onto the OS
But we already did and it is widely accepted: anti-virus software.
which hasn't shown a brilliant track record of protecting people from the things they run,
But that the point of the responsibility separation. If user explicitly wants it, then you can't do anything against it - against the will of user. After all, computer exists to fulfill the commands given by the user.
You are sending us back to the old Outlook dilemma: how to send installer of a hot fix to a customer who urgently needs it? Because Outlook too can police attachments and instead of giving AV software a chance, simply drops anything with extension .exe. Or any archive which contains an .exe file. Or anything what looks to Outlook even remotely suspicious.
But you are sort of suggested solution: this Google's effort should be concerted with the AV vendors. Or the effort would go either the way of ActiveX (permanently disabled) or the way of Outlook (let's be smarter than user, making software in the end even more useless than it was to begin with).
All hope abandon ye who enter here.
And legacy applications, and Excel macros.
How about thinking of it more in terms of marketing, developer and consumer acceptance. In creating games to suit a platform, a market ecosystem must be built up of developers and consumers. This can be more readily created with relatively simple games in a web environment using the Google's cloud and aligned ISP's to provide the processing power for consumer to access and play games on relatively low cost devices.
From that basis the gaming environment game of course expand, no different to the expansion of the PC gaming environment over the years of development, into more complex and demanding games and obviously more powerful gaming platforms.
Basically from the phone, to the tablet, to the smartbook and tad dah, the desktop (the desktop either being a more powerful notebook or an actual desktop, perhaps even an open console or more likely a big screen built in optional accessory). Google thrives in an open market and the more areas of the computer ecosystem that are open and available to it the more opportunities it currently has.
Chaos - everything, everywhere, everywhen
You could have saved all the trouble of typing out the poorly reasoned tripe and just said "get off my lawn."
It must be the right way, because all the old programmers who don't want to learn anything new hate it.
For what else would you like a native client in a consumer product.
Except it uses HTML5 instead of running through another box full of rendering.
Could be much more interesting from an interactivity standpoint.
Some Googlers seem to appreciate wordplay :)
I would argue that this is doable: we now have a very good handle on sandboxing applications, and we even have good, almost-native-performance VMs. If we can make it so that all untrusted apps automatially run in a sandbox or VM, then this will work. So long as the "least work" state has the application running in a sandbox, that will prevent 90%
of infections through this vector.
Also, don't forget the fact that this will run cross-platform, and thanks to qemu(if it's x86 bytecode), on other arch's as well! So long as the Pepper API and source code is available, I can't see any problem with it. It will basically put *all* OS's on the same footing, without quite so much in the way of hacks like Wine. ...And who wants to bet that this api uses OpenGL/webGL instead of DirectX, at least internally?
They're [sandboxes] a theoretical concept that have never worked well in the real world. They've been tried time and time and time and time again. They aren't a new concept, but nobody ever seems able to implement them properly, even when some of the biggest names in the field are involved, and even when they have nearly unlimited resources and people to throw at the problem.
Well, except Apple with iOS, Google with Android, the NSA with their SELinux improvements, a crap-ton of people who worked on and use TrustedBSD, Bitfrost in the OLPC, and every security researcher for the last 20 years who has relied heavily on VMs. But yeah aside from those and probably a bunch more I don't know about, no one has successfully implemented sandboxes.
Maybe what you meant to say was that Microsoft hasn't been able to implement them properly.
You're correct. In this case it was the fact that the person managing that infrastructure wasn't qualified and the gateway was kept in a room without adequate cooling.
That being said, there's other reasons why this isn't a wise idea, some of which are related to what happens when infrastructure 3 states away is having issues. I remember times when that would cause slow downs and problems. Granted that shouldn't be an issue these days, but then again companies should pay to have these things done correctly.
And ultimately, mission critical infrastructure should only be off site as a backup or in cases where the users aren't all in one place. If you've got most of your employees in one or two buildings, then its' really not a great idea to have the infrastructure somewhere else completely without some means of caching or otherwise working when the machines are down.
Once Google gets this out - knowing competitors will not pick it up - and leverage it's massive weight by paying devs and advertising everywhere - we may actually get some decent games done for it.
But only Chrome will play them, the open standard is just a trick there, as, once again, no one else will implement it for a long while.
Once Chrome has captured market, Google has end-to-end web control, and that is a little bit scary.
But we already did and it is widely accepted: anti-virus software.
Ha. AV software is an old dog that should be taken for a walk.
Someone flopped a steamer in the gene pool.
Even the browser (another name for 'program suite') runs on the server.. A real thin client is just a keyboard and a monitor
For justice, we must go to Don Corleone
What is the benefit other than porting native apps to run in a browser? The article linked to says that the Pepper interface is a binding layer that converts the native calls into stuff that can be done in HTML5. That's great but ... native apps will now be limited to the performance of the HTML5 engine unless I'm missing something. So yeah you can get platform independence as long as you are willing to have an interpreted layer between your code and the OS. Isn't that the same thing Java gives you? How about Windows game developers Direct X support etc? Are developers really going to just throw that away and redesign things to perform well on an interpreted HTML5 interface rather than port the program over to a web language entirely?
And SQL Server, and Visual Studio, and a bzillion different vertical apps put out by ISVs.
You hinted at that with "legacy applications" but the fact is that very little of the installed base of Windows applications counts as "legacy." Most are being actively developed.
Actually this is kind of exciting for if it seriously takes off, that means one can do some gaming in a linux platform.
I've been playing games using only GNU/Linux for many years and the main problem was lack of time to try them all, especially since the Humble Indie Bundle. Let alone all those games for Android. I highly doubt that I somehow travelled in time and started using NaCl even before Chromium was released.
I agree it can result in more cross-platform games, though.
Who cares if they're making HTML 5 games when they're doing browser detection that blocks other HTML5 capable browsers instead of doing feature detection to tell if the browser supports all the features needed to run?
How is keeping the thin client updated any different from keeping any standard set of programs updated on the computer?
we do weekly updates to our web apps, i shudder to think how you'd roll that out to hundreds of computers, laptops and mobile devices when it takes us something like 10 minutes per application to push them to the production server.
This is a joke. I am joking. Joke joke joke.
If only they let the bytecode access directly the underlying opengl graphics primitives, we could implement our own rendering engines in this bytecode language and be done with html5 compatibility problems forever... (of course assuming that other browser vendors will use the same bytecode).
If Pandora's box is destined to be opened, *I* want to be the one to open it.
They should start to re-enable it. I use XP on a netbook which has a ION, it's a very powerful GPU for a netbook, I can play movie on 1080p because it uses the GPU to render it. Flash video *were* also accelerated, but not now. Google decided that on XP, they disable all GPU acceleration. So now all the video (like youtube), all flash games, etc, are driven by the poor Atom...
Why they forced a disable is beyond me, there is no way to re-enable it except by going back to Chrome 7 or something like that.
"Science will win because it works." - Stephen Hawking