This paper is based on a misunderstanding of how Bitcoin transactions work. If I receive 10BTC, then send 7BTC to someone using the usual software, then 7BTC will go to them and the other 3 will be sent as "change" to a newly-created Bitcoin address that's added to my wallet. It's also common practice for websites that accept Bitcoins as deposits or payment to generate a new address for every customer to send coins to, so that when they send coins they can tell who sent them using the destination address alone. The authors of the study don't seem to know this, so they completely misinterpret the patterns they're finding in the blockchain. If everyone followed the suggested practices of generating a new address for every incoming transaction, then every address would be either empty, or have never had an outgoing transaction.

And speaking of websites that accept Bitcoins as deposits, the recommended security practice is to divide coins into a "hot wallet", kept on the server and used for day-to-day transactions, and a "cold wallet" that's kept off-line for security. A cold wallet should almost never be involved in transactions - but it backs peoples' deposits which are used in transactions, so it's not like it's out of circulation.

From the article:

"Ngoc Sinh has been certified as safe by Geneva-based food auditor SGS SA, says Nguyen Trung Thanh, the company’s general director."
"SGS spokeswoman Jennifer Buckley says her company has no record of auditing Ngoc Sinh."

In other words, the article claims that Ngoc Sinh Seafoods Trading & Processing Export Enterprise is using repulsive and unsafe practices, and lying about having been inspected. Bloomberg is accusing them of a crime. The Slashdot headline, on the other hand, converted this into "Approved for Consumers" - accusing a different group, the regulators, which appear to be innocent.

You might be tempted to think that this means ordinary errors aren't as common as we thought. Lots of papers - actually most papers, at least in medicine - are wrong for reasons like the author being confused, doing the statistics wrong, or using a type of experiment that can't support the conclusions drawn. But merely publishing a paper that's bullshit? That usually isn't enough to trigger a retraction, because retracting papers looks bad for the journals. Only an accusation of Serious Willful Misconduct can reliably force a retraction.

Consider giving it to the Center For Applied Rationality. Their goal is to make people more rational, by teaching about cognitive biases and scientific decision making, and studying how to do so effectively. They're doing great things, on relatively little resources; your marginal dollars would go a long way.

If Google had won a wireless spectrum auction (they didn't), then Google Voice could've been the core of Google's competition with the telco network. Pieces of it are probably still useful for Android, and it could give them negotiating leverage with carriers. So it could've been really important, but didn't turn out that way. The thing with software products, though, is that almost all of the cost is in the initial creation; once created, they cost very little to keep around. So Google keeps Voice running, because it costs them little and turning it off would be very disruptive.

The problem has never been knowing whether a worker is tired or the degree. Workers are well aware of how tired they are. The problem is jobs that pretty much require them to keep working anyway.

Workers may know that they're tired, but they can't easily prove it, and they can hide it if they don't want to lose pay. If someone goes to their boss and says they're too tired to work safely, they're likely to be ignored, and told to keep working. But if there's an impartially generated number that says they're too tired to work safely, that can't be ignored - because if a supervisor ignored that, and there was an accident, it would be easy to prove they were at fault.

Also who is liable in a fatal accident caused by a machine?

The insurance company that owns the policy for the vehicle, same as if it were being driven by a human. And while the general public may have a hard time reconciling statistics that say driverless cars are safer with a few stories about them getting into fatal accidents, insurance companies do not have that problem and will support whichever costs them less money in claims.

Lots of comments here that're completely missing the point. This is to prevent you from selling at multiple stores at once. You see, in addition to setting whatever price they want, Amazon also has a rule which says that you're not allowed to set a "list price" that's higher than what you sell it for on other app stores. This means that if you put the same app in both Google Market and Amazon's store, then Amazon's store will always be cheaper - and you can't raise the price to counteract Amazon's discounting without ruining your sales on Google Market.

This is just one of several showstopping issues that ensure that I, as an app developer, will not put anything to Amazon's app store.

I'm an Android app developer, and under the terms Amazon's currently offering, there's no way in hell I'll put my app there. There are three very serious problems with it. First, Amazon controls the pricing, not the developer - they can use your app as a loss leader. Second, they require that you give them your app and each update 14 days before you publish it anywhere else (such as on the Android Market) for their review process. That means no emergency fixes, and delayed releases, even if you're mainly publishing on the Android Market and want to put it on Amazon too. And third, it's competing with Android Market, which is preinstalled everywhere, with no users. It would be one thing if they offered more than Android Market's 70% take, but there're simply no advantages to it whatsoever.

Maybe they'll change their terms, and I'll reconsider. But the terms they're offering now are simply a bad deal for developers, and I doubt many will bite.

You aren't forced to write in Java, you're forced to write for the JVM. There are other languages that target the JVM, including versions of Ruby, Python, LISP, and my personal favorite, Scala. Using the JVM means that Android isn't locked in to using any one particular CPU instruction set (which was what destroyed the original PalmOS), and that all Android programs and libraries are API-compatible with each other without the need for setting up special bindings.

XeY means X*10^Y, not X^Y.

If a company wants to pay you money for software you wrote, then for the love of god, take it, and give them whatever license they want. They don't actually need a different license, but that doesn't matter because what they're really after is support, not licensing. So write up an N-year support contract where you promise to take their calls and promptly fix any bugs they report, and charge appropriately for it.