My title was misleading, sorry. I don't mean to say there is no value in stereo video. Just as stereo and 5.1 audio improve the experience, stereo video has the ability to improve the experience. But I'm tired of the media treating this as though it's a whole new paradigm. (Ever been to an IMAX movie and watched the beginning where they show off the 10 speaker surround sound system? My reaction usually is "That's really cool. But start the movie already")

Personally, I'd rather they spent their efforts on adding more resolution and better touch accuracy to cell phone screens. Hardware space/development time is finite, and 3D screens are going to draw effort away from things that affect my everyday usage of these devices.

The one good thing about this technology catching on is that people may start to record more data in stereo video, which could lead to interesting use cases in things like photosynth and 3D model scanning (this time I mean real 3D as in three axes, not stereo).

Lame... I was hoping this article was about phones getting better EGL or WebGL support for Video Games.

I remember one time when I was testing a "3D" (stereoscopic) device, and it seemed like the coolest thing ever--I felt I really noticed the 3d effect, and it seemed "awesome".

Turns out, the left eye of the glasses wasn't working, and I guess the 3D effect was my own brain inferring the depth the whole time. I'd suggest trying this out if you're ever testing a "3D" technology: cover/close your left (or right) eye and see if it looks more "realiztic" or "cool" than with it open.

Also, as an analogy for audio, how many times have you played mono audio files and not noticed? (hint: anything recorded on a phone or microphone is not stereo) Video is hardly different.

Mod parent up! (Though please don't put WTF and idiot in your subject, or you sound like a troll)

Why are we wasting our time with screenshots when this barcode technology has existed for ages. I'm actually surprised that QR codes haven't really taken off in the US--I guess if the iPhone doesn't support it, nobody cares.

Thanks for that bookmarklet--it'll come in handy.

Why? They still have "dselect" with its intuitive interface (s /), not to mention this "aptitude" thing that I keep hearing about.

Why do we need all these different GUIs anyway?

Because going after the sugar mountain wasn't enough?

Google Translate is really good at what it does -- it's one of the best systems, but it's fundamentally not a human level translation, except for those cases where it's seen something translated word-for-word by a human (e.g. UN documents), and even those can be wrong if they are used out of context.

There's a big difference between readability and accuracy. Most existing machine translation systems do not understand the semantics behind what they translate. It's not super hard for a computer to generate pages of readable, on-topic output, but to produce a "human-level" translation requires something more than computing power alone.

Google translate regularly mixes up negatives or uses the wrong definitions for some words, which can sometimes completely change the meaning, and you don't always notice this until you find a self-contradiction. Asian languages come out hardly readable, much less accurate -- I often get more accurate "translations" by putting each word into a dictionary.

Why use flash in an x64 browser?
FTFY

I don't have flash in my 64-bit chrome. I rarely even notice that I'm not using flash. When I really want to see something in flash, I pop open the 32-bit firefox installation I have, and paste the url in there. More often than not, Vimeo and YouTube's HTML5 players work fine. The only trouble comes with any videos that embed ads, or DRM-heavy video sites like Hulu. (Exchange Chrome with Firefox if you want)

I've been using this solution for a while, and it's much better than having an old/vulnerable Flash version or being subjected to the horrors of the 32-bit world for my everyday browsing.

Of course, UPS doesn't ring the doorbell. They knock. Three times.

The Motorola CEO, while I disagree with the concern about the open market, is spot on about the performance issues. I don't want to pay for a more powerful phone, and I don't think I should have to. My Moto Droid with its 300MHz processor has actually had very good battery life -- several days outside the US in airplane mode, and two days with basic 3G use. I don't think a phone should need a 1GHz processor, and indeed the original iPhone had a "slow" processor and the UI is more responsive for basic UI tasks than my friend's Droid X (aside from the smooth home screen scrolling which is just a GPU hack anyway).

The battery issues I have dealt with are almost exclusively issues with the built-in OS, leaving no solution aside from restarting the phone. For example, "android.process.media" taking 100% CPU after rescanning the SD card or playing a song, and no visible feedback aside from the phone getting hot; or MediaService taking hours to update the list of photos in the Gallery app.

Aside from a couple apps that run as a service, I've almost never had issues with applications eating up battery life unless I'm using them -- and I'm fine with using battery in that case, because I want to use those apps. However, unlike iPhone, Android allows applications to run in the background, and with background tasks, Android has the responsibility to keep the Phone functioning when those apps are running.

Android should always have a usable UI (10 seconds to answer a phone call when CPU is busy is absurd), in addition to a way to learn about CPU usage and disable faulty background apps. A message like "Service X is consuming excessive battery life. Disable / Ignore / Don't notify me again about X" would probably solve half of the issues I have had. I put the blame on Android itself for not having put any thought into this problem--Every android release adds dozens of useless features but no innovation on solving these basic usability issues.

Read this article from a Mozilla dev:
http://blog.jprosevear.org/2011/05/13/webgl-security/

Note the last paragraph:

Nevertheless, claims of kernel level hardware access via WebGL are speculative at best since WebGL shaders run on the GPU and shader compilers run in user mode.

Therefore, unless something is horribly wrong in a particular graphics driver (and Mozilla/Google were careful which companies they whitelist in this regard), the worst case is a bug in the code compiler -- which is probably about as likely as a bug in any Javascript interpreter or Adobe Flash.

Also, they would need the "triple-step dance" for each different buggy driver, each of which would get patched in weeks at most, and each of which probably affects 0.1% of the market due to the diversity of hardware, OS and browser -- you have to consider payoff of exploit as well.

You said usually. That's not true in 99% of cases -- if you read the article (which is unfortunately slashdotted), the specific crashes in this case are in locking up the GPU itself by taking too long to render frames. This means that the computer will reset due to its watchdog timer, not because any malicious code was executed on the CPU.

You are correct that the occasional graphics driver might be buggy, and that's why Mozilla has a whitelist of graphics manufacturers and cards that are actively patching their drivers, and a blacklist of any drivers which are out of date, incorrect, or may otherwise have a bugs.

Not to mention a shader validator both in Chrome and Firefox (The ANGLE project) which will check for any malicious code. Yes, there may be bugs in any of these components, but this is defense in depth, and all of these components are going to be quickly patched and/or blacklisted if an exploit is found.

This is nothing more than a scary article about the well-known risk of denial-of-service and using shaders to extract pixels from a remote image -- and the media is slurping it up, using senteces like "run arbitrary code on the GPU ... render an entire machine unusable". Ugh.

It's a completely over-hyped article about something the spec designers have known since day one. The article takes the fact that bad OpenGL drivers can crash a computer to mean a security hole, something which driver vendors are actively participating in resolving for future cards.

I wasted my time reading that whole report a few days ago, and it basically said nothing that wasn't obvious and well-known. The only thing new is they are showing that there is no way to stop GPU code from extracting pixels from remote images embedded in a canvas, which is a real "security" hole, though there's not a whole lot of use for this.

Basically, the extent to which this *should* affect webgl is that they will disallow textures from remote sites -- in other words, it could add an extra annoying implementation step for collaborative spaces that could include models from multiple sites. Also, they might choose to add an Infobar to prevent arbitrary websites from crashing the computer or making it run slowly.

However, thanks to the media slurping this up and using words like "run arbitrary code on the GPU", "render an entire machine unusable", etc., people who read these articles and know nothing about the subject (i.e. idiots) will start to ask browser vendors to turn those features off. But to be honest, I hope people aren't this stupid and "FUD"-y articles like these are forgotten.

Also, the title is plain misleading -- a denial of service attack on buggy drivers should not be described as "Leaves GPU Exposed". A website can not in any way take advantage of crashing a user's computer, and browser vendors will quickly respond with a blacklist patch when they learn of the affected GPU.

If you disagree with anything I said, feel free to comment and I'll explain in more detail why what the article describes are not "security issues" in WebGL.

I must say that I felt safest in Germany. They don't have any of the stupid rules the U.S. inherited over the past 10 years--I didn't have to take off my shoes or get any patdowns, but they thought out the whole process much better. They actually check where you are going before you get on an international flight, they have multiple people look at your passport and they stamp it both coming into the country and going out (and I had a close friend who was interrogated and put on a watch list because of a missing stamp--so they actually check them).

UK is a lot more like the US. They don't have the newfangled full naked body scan machine, but aside from that, London airport feels a lot like any of the U.S. airports--and the airport was so confusing that I wouldn't be surprised if there were some way to inadvertently bypass the security checkpoint by going through a couple back doors.

The U.S. security is a sad joke. Sure, their security checkpoints might be very secure, so no explosives will make it through -- but their entire process feels like it is not thought through at all. For example, I once made it all the way through security for an international flight looking at the wrong boarding pass, and it seems like this sort of thing shouldn't be possible.

I wish things were as you say. However, many applications written in e.g. LAMP stacks allow the web server full read access on the entire database, and often even write access.

I would hope Sony isn't so stupid, but for example you will often find a configuration file which contains this username/password and can connect to the database. This file often needs to permit read access by the webserver because the application itself needs this access. Hence, given access to the webserver, it would be fairly trivial to gain access to the entire database on such a simple setup. This is sadly true in just about every PHP application you can install, as well as every custom-made software stack I have seen used in small organizations.

However, note that I said small organizations. Having a single database server in a company as large as Sony would make sense, so they would have to design a better system. Plus, sending SQL over the clear in a large network is a horrible idea. I would expect better security, in which access to the webserver would only compromise transactions going through that system and not the whole database (you would steal 100 credit card numbers, not 10 mil). For example, using a very narrow layer between the webserver (which is accessible to the outside) and the database service, where you only have commands for valid actions, e.g. "purchase(sessionID, game)" or "login(username, password)"

Furthermore, using virtualization, user account isolation, and operating-system sandboxes like SELinux, you should be able to restrict any damage should the webserver itself be compromised. I would expect any large tech company to have this level of security.

Thanks for the explanation! I would mod your post up if I had points.