Making bad math puns is the first sine that you've had too much to drink.

No android phone I have has done this. While the screen goes blank, it's still active. If you touch the screen (or adjust the volume), it turns back on. To expose among other thing a big button that says "End Call".

Trust me, I've hung up more than one call on accident.

To be fair, they give you a choice between Headcrab and Facehugger models.

Personally, I don't want anything that restricts my vision. I like my coffee mug not knocked over, and to not whack my love in the face because I didn't see her.
3D is best done in booths where the environment is protected from the 3Dee.

Oh, and let me add: A phone app that can automatically disable screen input while a call is in progress, so you don't inadvertently hang up with your cheek.

I would like just one communications app - a decent PHONE app. One that doesn't use a high-pass filter to cut off half of what my deep voice is saying, making people ask me to speak up even though I'm already making people around me look at me because I speak so loud. One that has voicemail on the phone itself, not as a dial-in service, so you can save voicemails for later use. One that has built-in access to public phone books and yellow pages. One that will let you choose whether to roam or not from within the phone app, not going through settings. One that lets you punch the numbers as fast as you can. One I can disable the ringer on without having to (a) unlock my phone, (b) open a different app to (c) turn all sound off.

Cell phones of the 90s were better at making phone calls than today's "smart" phones are. They're smart at everything except being a phone.

And the network I am on will not allow outgoing DNS requests - the DNS servers are split with different views depending on who queries it. So outgoing access to 8.8.8.8 and other DNS servers are blocked.
Likewise, outgoing web requests are blocked unless they go through an internal proxy server.

So I can't use Netflix because my network doesn't allow promiscuous outgoing traffic?
Hulu, here I come... Take my money!

Then after all blocks on the drive has been written to, you wait for a second while the drive moves data away and clears a sector so there's space to write to.
SSDs have far better average write speeds, but far worse worst case write speeds. Using them for anything timing critical without a battery backed up controller is asking for trouble.

"Use TRIM", I hear from the peanut gallery. Except that there are no RAID controllers (or software RAIDs) that actually support TRIM in practice. Nor does TRIM work for partitions where there is no file system support. Like raw database partitions or swap. Yep, put a single swap partition on the drive, and you will still be subject to the drive not knowing what blocks are free, and can't write to them unless asked to overwrite them.

For guaranteed rate I/O, spinning platter drives and pure battery-backed RAM disks is still the way to go. A RAID of short-stroked HDs have a worst case performance far better than modern SSDs, despite the average being much slower. For a desktop user, an occasional or rare "hickup" of a second might not be noticeable or even a concern if it is, so SSDs are fine, and even great. For real-time data processing, it can very well be a big concern.

In a video game they can. In the real world, they will fail to do so; Google and others are simply positing that the robot can drive better. It can on a test track. In the real world, no.

Again, I love this posting from 2010: (Great thread on this very subject, probably influenced me.) Better informed posters than I.

http://it.slashdot.org/story/1...
This post http://it.slashdot.org/comment...

"we already fixed it. its called 'trains'. (Score:5, Insightful)
by decora(1710862) on Tuesday December 20, 2011 @12:54AM (#38430976) Journal
the idea that a bunch of automatically piloted vehicles is somehow a better solution to city transport than mass-transit, it boggles my mind.
real people do not have money to maintain their cars properly. things are going to break. there are not going to be 'system administrators' to fix all the glitches that come up when cars start breaking down after a few years.
there will be problems. do i know which problems? no, but i know the main problem.
arrogance amongst revolutionaries. it is historically a pattern of the human species. declaring that nothing could go wrong is usually a precursor to a lot of things going wrong. not because the situation was unpredictable, but because human beings in an arrogant mindset tend to make a lot of mistakes, be reckless, and try to cover their asses when things go wrong.
but successful engineering is the anti-thesis of arrogance. nobody worth his salt is going to say 'what could go wrong'? they are going to have a list of 500 things that could go wrong, and all the ways they have tried to counter-act those wrong things happening."
Well said. Proof will be in the testing... on real roads with real cars. Oy.

http://it.slashdot.org/comment... Great thread on this subject. Here's a good post by a better writer than I:

"we already fixed it. its called 'trains'. (Score:5, Insightful)
by decora(1710862) on Tuesday December 20, 2011 @12:54AM (#38430976) Journal

the idea that a bunch of automatically piloted vehicles is somehow a better solution to city transport than mass-transit, it boggles my mind.

real people do not have money to maintain their cars properly. things are going to break. there are not going to be 'system administrators' to fix all the glitches that come up when cars start breaking down after a few years.

there will be problems. do i know which problems? no, but i know the main problem.

arrogance amongst revolutionaries. it is historically a pattern of the human species. declaring that nothing could go wrong is usually a precursor to a lot of things going wrong. not because the situation was unpredictable, but because human beings in an arrogant mindset tend to make a lot of mistakes, be reckless, and try to cover their asses when things go wrong.

but successful engineering is the anti-thesis of arrogance. nobody worth his salt is going to say 'what could go wrong'? they are going to have a list of 500 things that could go wrong, and all the ways they have tried to counter-act those wrong things happening."

http://en.wikipedia.org/wiki/L...

Medical[edit]
  A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of X-rays.[13][14][15]
  A Medtronic heart device was found vulnerable to remote attacks in March 2008.[16]

Funny: I remember this story. The USS Yorktown BSODed at sea when it let Window NT helm the ship.

http://en.wikipedia.org/wiki/U...
Smart ship testbed[edit]

From 1996 Yorktown was used as the testbed for the Navy's Smart Ship program. The ship was equipped with a network of 27 dual 200 MHz Pentium Pro-based machines running Windows NT 4.0 communicating over fiber-optic cable with a Pentium Pro-based server. This network was responsible for running the integrated control center on the bridge, monitoring condition assessment, damage control, machinery control and fuel control, monitoring the engines and navigating the ship. This system was predicted to save $2.8 million per year by reducing the ship's complement by 10%.

On 21 September 1997, while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing an attempted division by zero in the ship's Remote Data Base Manager, resulting in a buffer overflow which brought down all the machines on the network, causing the ship's propulsion system to fail.[6]

Anthony DiGiorgio, a civilian contractor with a 26-year history of working on Navy control systems, reported in 1998 that Yorktown had to be towed back to Norfolk Naval Station. Ron Redman, a deputy technical director with the Aegis Program Executive Office, backed up this claim, suggesting that such system failures had required Yorktown to be towed back to port several times.[7]

In 3 August 1998 issue of Government Computer News, a retraction by DiGiorgio was published. He claims the reporter altered his statements, and insists that he did not claim the Yorktown was towed into Norfolk. GCN stands by its story.[8]

Atlantic Fleet officials also denied the towing, reporting that Yorktown was "dead in the water" for just 2 hours and 45 minutes.[7] Captain Richard Rushton, commanding officer of Yorktown at the time of the incident, also denied that the ship had to be towed back to port, stating that the ship returned under its own power.[9]

Atlantic Fleet officials acknowledged that the Yorktown experienced what they termed "an engineering local area network casualty".[7] "We are putting equipment in the engine room that we cannot maintain and, when it fails, results in a critical failure," DiGiorgio said.[7]

You have no imagination and too much confidence in your coding abilities. The world isn't a video game. As I pointed out in my longer response, robot airliners and other craft have gone wild and hurt and killed people. Refusal to look is not a rebuttal. (But of course it is- any problem can be solved by a more expensive solution combined with a complete refusal to look at any evidence that contradicts the solution).

Software piloting is fine. On a plane, with a priesthood of techs looking after it daily, and with pilots who have (one would hope) both the opportunity and the ability to take control if the computer pilot goes fuckyup. In a car, there is no time to recover, worst case, the "pilot" is playing a video game, the car's maintenance is up to the pilot, and the car is surrounded by other cars that will be in a lot of trouble from the rogue car. No comparison.

You can't synthesize a general rule from systemic failures? Keep It Simple Shithead.
Planes do fail by software errors.
http://en.wikipedia.org/wiki/Q...
http://it.slashdot.org/story/1...
http://en.wikipedia.org/wiki/A...
Antilock brakes are very simple systems, and you have a mechanical backup as well. But, for the record, I don't like computer controlled brakes. I drive a mechanical car.
If ABS do fail or malfunction, I doubt anyone is keeping track as to how or when. As no one keeps track, you can't perceive systemic failure as a problem. They'd have to fail massively for anyone to care.
Robots don't operate very much, and frankly I certainly don't want a piece of software cutting on me. It's not outlawed for the same reason automated cars aren't outlawed. Not enough experience to perceive failure, and an unwillingness to acknowledge failure when it does happen. And civilized countries allow voting via computer programs as well - the ultimate in unpercievable failure.
Pacemakers can fail via deliberate malware infestation, or an EMP attack or accident, or a software bug. Just because you don't know of a failure doesn'[t mean it doesn't happen.
Here's some automated software injuries:
http://en.wikipedia.org/wiki/T...
http://www.ccnr.org/fatal_dose...

As to your point about a software bug failure on Twitter being different than a software bug in a car running half a billion lines of code:

You make my point for me. Twitter failed from one point. Just one point. Half a million lines of code have damn near an infinite chance of:
1. Failure through complexity. Any real-world programmer knows that hyper-complex systems can have cascading weirdness.
2. Failure through sensor failure, processor failures, bus failures, and similar failures we can't anticipate.
http://it.slashdot.org/story/1...
http://www.cs.tau.ac.il/~nachu...
And Google's robot car had to be rebooted twice during its certification run.
3. Failure through an the inability to program a PC to anticipate all the possibilities that a car swarming with other cars in a real world situation. One can't program that.
4. Failure through vulnerability to outside attack. Software on a network is very vulnerable; one hundred percent so. Physically, a high energy radio pulse fired at a car, or a whole highway of cars, would cause carnage. Carnage would be multilation and death, what happens when steel boxes swerve randomly around at 70 mph with no driver.
5. The problem isn't about ALL cars failing. One car can fail and crash the cars around it. For the system to work, all cars have to work 100% perfectly all the time.

An car - driver is eating a sandwich. Car computer failure would crash the car instantly, depending. Carnage.
An airplane - plane is, generally speaking, in the air most of the time. If the computers fail, somehow, the pilot can take control with time enough to avoid contact with other planes or the ground.
Car - failure, milliseconds to react, car may not even let you drive. Plane: seconds or minutes to recover and land.

I'm only pointing out the obvious failure points. Others will happen. I wistfully recall posting on Slashdot about the vulnerability of a NFC card being read without the owner's knowledge; I was mocked as an ignoramus. I just pointed out physics didn't rule out building a concealed reader, or very powerful pulse generator. Both have happened.

I await the stories of failed robot cars in the coming years, and either the panicked response or the determined refusal to acknowledge a problem

Try driving your own cars. If that isn't safe - and it ISN'T, cars kill more people than wars - think about building decent public trans.

Remember this conversation, about five years from now.