Yes, the password is based on dictionary words.
Except there are several of them in a row.

Say that there are 5'000 common words in English.
The phrase has to make sense, so actually there's only a subset of those 5000 which can follow a given word without breaking grammar rules.
Let's say this subset of "next grammatically correct option" is 1000.

A string of five word gives you a space of:
1000 ^ 5 = 10 ^ 15 possibilities

When using a combination of 80 sings (small and capital letters, numbers and a couple of punctuation marks), this is exactly the same as :
ln(10^5)/ln(80) = 8.4

Thus picking such a phrase would give roughly the same password strength as using 8 purely random characters (enough for the usual requirement for most passwords).

If "at least 8 characters long, including capital letters, numbers and punctuation" passwords are good for most situation, this phrase should do the trick, even more so because most passwords people will provide won't actually be purely random strings but modified words ("(hick3n!", "sHit_666", etc.) which are much more easy to crack than purely random strings.

Now of course, a completely alternate strategy would be to generate 64-caracters long strings of purely random shit, and then use a keyring manager to remember them for you.
(If the authentication supports non-ASCII caracters, that would give you roughly 10^149 combinations. Down to 10^126 if you use only 96 printable symbols)

Or even move to public/private key strategy for authentication.

According to the article, the low power increase the relative error to 7.5% (quite huge) but reduce the power requirement 15x (massive benefits).

A possible explanation:
Some mathematical computation (like trigonometry) is done with lookup table and interpolation.
By using as simpler (like linear instead of polynomial)- or even doing away with- the interpolation step, you can quite speed up and lower the power requirement for corresponding ops.
By doing this you only increase the expected relative error. Not occasionnaly producing garbage.
Thus only get more approximative DCT step in you video decoding, and the output is more "blocky" (see the attached JPEG in the article).

Another explanation:
TFA speaks about reduced precision multiplication and addition.
So you could also use a simpler (but more error prone) circuitry for handling the least significant bits (TFA mention lower voltage).

Or situation where you don't actually need exactly 1 answer pro input, but where you somewhat statistically combine ("reduce") the output. (example: you only need an average of all results) and the b0rked-bit-flipped-results would be dropped with most of the other outliers.

You trade a loss of precision (the final mean will be done on less sample - you loose p.pp% of them as outliers) against a massive power requirement decrease (15x less power).

Again, that's not how the chip works.

In which case it will be ran on a workstation instead of the smart phone it was developed on, which will either not have the "low-power fudged mode", or could atleast switch between "low-power" (say for desktop eye candy. Where TFA's 7.5% relative error is acceptable) and "high precision mode" (for any general purpose calculation done)

No bridge will fall.

In the first generation of CUDA devices, even those where tiered. You got either fast 24bit-only integer ops, or full 32bits integer ops.

Well, you can expect that the amount of fudging will be different for different type of video frame, or different part of the computation pipeline.
And that the error will be created in such a way as to be a small relative error (the wrong part being mostly in the less-significant bits) instead of a completly random error (any bit could be flipped, including the most significant part, or even the exponents).

Thus you'll get video noise (similar to the kind of picture degradation you could get by disabling post-processing or using fixed-point implementation), instead of random splashes of colour (similar to the king of degradation you could get with a packet error in the stream).

Exactly that.

Prepare to see GPU which go into "fudged mode" when dealing with graphics (3D, Video, etc.), and which go into "high precision mode" when doing science (OpenCL, CUDA, etc...)

Then further down the line, be prepared to see the "high precision mode" to be a paid-for only option.
(Buy a GPU marketed as tablet/latptop/entry-level desktop: Only "fudged mode available",
Buy a GPU marketed as high-level desktop/workstation/cluster: "High precision mode" available too, costs 2x more, although it's exactly the same chip (only perhaps with a different number of disabled/enabled core) )

That's already the case with other pro features:
- ECC mode is only availble on cluster OpenCL/CUDA cards (although they don't use ECC DRAM chips. Instead, they reserve a small portion of the memory to do checksumming in firmware/software). They are identic. Or in fact even cheaper (the graphic output is disabled or not even soldered-on).
- Quad-buffer stereo OpenGL is only available on "workstation"-grade cards, although there's no peculiar hardware requirement (and a subset of the same capability is available as proprietary gaming 3D-Stereo DX3D/OpenGL on some mid- and high-range models).

So, yeah, one more caracteristics that will be artificially price-tired through a pure software setting!

And one more opportunity for the open-source drivers to shine...
Well, except maybe they will lack the necessary man-power, due to the required additional reverse engineering, or due to the seldom needed feature.

(Although, we maight see a better chance with AMD hardware:
AMD supports the development of open-source drivers by providing documentation for almost everything (except Video DRM), and the computing part is recent enough (OpenCL was recently developped and is only on version 1.2) and relies on less quirks and optimisation than graphics: so performance shouldn't be lagging that much behind the closed source drivers.
When you also take into account that being open-source these drivers are easily packaged-with and maintained by distributions, thus making them a little bit easier to deploy (no need to add a manufacturer's 3rd party repository, no need to recompile a separate kernel module, etc. always compatible with up-to-date Xorg/Wayland API & ABI), we can expect the AMD hardware to see more open-source usage for computing, and thus the computing feature being more sought after and also developed by the opensource drivers).

Yup and this is the logical next step.

Once you have spatially organised a bunch of photos (what was done in Microsoft's Photosynth tech demo), the next logical step is to use them to create 3D reconstructions.
The researcher (and apparently at least one of them is the same) now build 3D point clouds out of the photos.

Now someone should sell/license the technology to google.
By combining photo albums with the data they already have from street view, they could build some really nice 3D models of towns buildings, monument, and so one.
(AFAIK the current 3D objects they have are still manually done)

And the obligatory PHDcomics: http://www.phdcomics.com/comics/archive.php?comicid=1174

In addition of the media needing "the latest hottest news" and thus over blowing the latest new subject (which merely has 1 study using a sample of 10) instead of making a deep review of a well studied subject, there are also problems comming from within the scientific community too :

Lots of research groups are under "publish or die" pressure: they a under pressure to publish as many papers as possible, and thus will tend to publish whenever they got a small "bump" in the signal - "which may under some circumstance be interpreted as something unexpected" - specially when it was never seen before (= unknown, more chance to attract attention, than being study number #23 that confirms that the well studied substance "XyZ-wateverocetone" and disease "Somethingitis" have no interraction, no matter what a paper published 13 years ago). There's a preference for original research in the scientific media, conferences, and so on.

Also, most research groups need funding, and thus whenever something has a slightly above average correlation factor, the paper will automatically jump to the conclusion "could one day be used to cure cancer" trying to whore some investments (this is the life sciences equivalent of putting "might also have some possible military applications" at the end of an engineering paper).

Also, pharmaceutical industries have the need to patent the crap out of anything remotely interesting, and think about actual uses later on, just to be sure to be able to secure potential revenue if the substance turns out to be successful. (This also leads to a patent minefield, where some substance aren't investigated much, because they are patent covered by company AbCorp, which doesn't study at all the diseases which might benefit from it).

All this has a rather negative result both on the scientific community :
- too much hype which ends up making a bad signal-to-noise ratio in the litterature, and difficult to mine the litterature for leads, inspiration or good data upon which to build.

and on the general population:
- because a lot of hype in the media turns out to be fluke or overrated or simply not further researched, they tend to think that most science is based on wrongs.
In practice, one might be right to be sceptic about a single paper making wild predictions out of 10 samples, but on the other hand, when there has been absolutely massive amount of research all bringing the same conclusions, there's no need in being sceptical (like evolution...)

Partial explanation why people didn't get it : http://xkcd.com/1050/

Another explanation is that some of the signature are from people playing along the joke.

But still didn't kill the girl on the spot, but "just" put her in a situation lacking insuline (dangerous on the long term, requires medical supervision on the short term, but no imediate killing involved).

There's a couple of difference between a pump and a pacemaker:
- pacemakers are implanted. So you get a human wrapped around the device and functioning as a meat-shield against lots of different radiations. Backscatter and mm-wave don't affect them. A drug pump is an external device (to make it accessible to replenish the drug) and thus is much more exposed to abuse.
- pacemakers are though as life-critical device. They are designed keeping in mind that if the device stops, the patient could die on the spot. Thus, their are much likely tu use rad-hardened components and designs. Whereas the pump probably makes compromises between costs (rad-hard costs more) and benefits (none was imagined back when the device was designed. Future device will probably start taking into account TSA's marvelous new addition to the security theater).
- changing a pacemaker require open thoracic surgery, changing a pump costs money, but only requires some needle work. Again, one argument for the second being quasi off-the-sheld components.

In fact, it's quite an achievement that the device was able to fail safely upon undergoing a stress from something that even didn't exist at the time the device was designed.

FTA: The device just stopped working.

Whereas, the pump could have gone beserk, and suddenly decide to dump the whole insuline reserve into the girl's blood stream and cause an insuline shock.

Yes, indeed. You need to have physical access to the device to change the insuline supply.

it's not trivial to temporarily remove one and put it back. As the device is indeed external and the insuline has to be delivered in the blood flow, you might guess that there are sterile needls involved and similar. not something that is easy to improvise in a security line. also, between shutdown and restart of the device once re-attached, there's also risk of manipulation errors.

So either:
- the doctor make sure the patient is properly educated and able to remove / re-attach the device (she's 16, but even younger kids can have Type 1 diabetes, and might not be able to do the whole procedure without parents supervision).
- the doctor provides all the necessary equipment to remove and re-inject the needle (bio-hasard box for used sharp object where to discard previous needle, sterile swipes, new steril needles, steril bandages, etc.)
- the doctor provides all the necessary documentation so the patient get proprer clearance to carry around the equipement past the security check, including the pointy needles.

Or:
- the doctors just write a letter saying that it's just better to "opt out" of the scanner (as she has the right to do any way).

Getting disconnected from the pump for prolonged periods of time without proper medical supervision isn't what's best for the patient's health, as the girl explains hefself in the video.

Removing the pump and relying on syringes for insuline, basically amount to a switch of medication, including an overlap period where the body still cointains leftovers from the previous type of therapy and new drugs are injected (or at least a completely different new therapy plan has to be followed). Such switches might require medical supervision.

It should be possible to design a pump whose on-baord computer is able to calculate and print out recommandations how to continue from that point on with a classical syringe). But it's just much more easy to recommand "opting out".

You can bet that massive government backdoor will be hidden in those slight differences.

Or use the simulation and see if a wave occurs as predicted by it.

Nowadays, you hardly have to use windows, indeed. In big part, thanks to all the on-line companies which managed to turn most of the important stuff into on-line services accessible from any standard compliant platform, thus rendering the whole question of OS irrelevant.

But in a not-so-long-ago past, Windows was the only way to go because most of the software one needed only existed as win32 application, lots of the hardware one could buy only came with windows drivers instead of being a generic USB class with generic drivers, it wasn't easy to buy computers without windows and replacing the OS wasn't easy either, and Microsoft had managed to leverage their OS monopoly to almost get a monopoly in office suite (everybody considering Ms-Office as a de facto standard, which was problematic because not only their format wasn't standard, it wasn't even consistent or compatible between versions) (or, buy pushing their bundeled-in Internet Explorer, Microsoft could almost have managed to create their own ecosystem of weird microsoft dialects instead of the standard driven web that we know today)
Of course, today, thanks to on-line service and opensources equivalent like LibreOffice or Firefox (or Google's own Chrome and Google Docs), thanks to gizmo vendor using stuff like UVC (Universal Video Class) for their webcams instead of obscure proprietary interfaces, thanks to reverse engineering efforts, thanks to developpers paying for alternative OSes (including Google's own support of Linux), etc. You can go without Microsoft.

It took massive effort from every one *else*, and it took some revolutionary shifts in paradigms (on-line services making the OS irrelevant), before we reached a situation where you don't need to go to Microsoft.

Now compare with Google: You don't have to use google's stuff, and google is indeed making it easier for you, by making it as easy as possible to interoperate with their service. Their e-mail servers speak standard IMAP and POP, so should you decide to move to another provider, it's damn trival to get your mail with you. And the contacts are easy to export, too. Their chat system is using XMPP/Jabber, so it's possible to interoperate with any other fully complient XMPP chat provider that does support federated chat (basically anyons but Facebook. FB's XMPP is just a compatibility layer above their proprietary chat system and a doesn't not interoperate with anyone else). Their Google Docs documents can be exported both to industry standard (Open Document Foundation) and de facto standard (interroperate with MS-Office). Most of their software is availble as opensource. (Android, Chrome, lots of libraries, ...)
At no point in time have they done anything to prevent people running to other solution. They insist in trying to be as much interoperable as possible, and people stick to them because they are damn convenient.

About your privacy considerations : well if you really want to keep your life secret, nothing prevents you from using encryption. You can even send and receive encrypted mails through your gmail account as long as you're accessing it with some standalone IMAP/STMP compatible client (say Thunderbird). You can chat with encryption as long as both ends support end-to-end encryption like OTR (Off The Record - supported by the whole libpurple family like pidgin, adium, etc.). In fact it's possible to use Google services without revealing much of your private life. (Unlike facebook where it's fundamentally much more difficule to avoid revealing anything, due to the nature of their service).

Google has a core business - advertising. But pretty much everything else they do, they do it nicely - use standards, publish source, etc.
Of course they play nice, not because they're pure-hearted angels, but also to avoid alienating their user base and thus loosing ad viewers. But no matter what their motives are, they mostly stick true to their "do no evil motto".

The only point on which they do have an advantage to leverage: the size of their database. They have unbelievable amount of data collected from the web, from the streets, from stored content, etc. that they can use in creative ways. (For example, as mentioned elsewhere on this slashdot entry: statistical translation has been attempted before, but google are the first to have a nice implementation of it... because they can leverage all their huge data collection to provide the statistics powering the translation engine). For a newcomer, it's going to be difficult to gather the same impressive amount of data.

You mean, beside their constant advertisement for AdWords ?! I think if you missed that they are an advertising company, you need to be blind.