platypii

From the Android API docs:

"What a Terrible Failure: Report an exception that should never happen."

http://developer.android.com/reference/android/util/Log.html..., java.lang.String)

good riddance

Something like this, where they put up a 30-story building in 15 days in China. Super impressive timelapse:

http://www.youtube.com/watch?v=Hdpf-MQM9vY

Could you please characterize the difference between "criminal charges" vs "political ones"?

My problem with his remarks was that he was addressing the wrong issue. He was defending the need to access this data without a warrant. He then repeatedly stated that he welcomed the discussion.

But how can a national discussion take place about a secret program??

He never addressed this issue of why the program needs to be secret in the first place.

Maybe Microsoft would have some more interesting products if they had more employee churn...

I was pulled over for this exact reason in CA. I went to court, showed cell phone logs that I had not made or received any calls or texts, and the case was dismissed. The judge said specifically that "I'm not convinced that using maps is any less dangerous than texting, but I have to rule as a matter of law that if you were not communicating with anyone, then it is not illegal." Apparently angry birds would have been okay too.

(note that this happened in 2012, before the ruling in this article)

No, gopro has acknowledged it. I think it's a weak response, but here it is: http://www.reddit.com/r/gopro/comments/1anq5d/gopro_doesnt_l...

When I say relatively easy, I mean compared to the prevailing wisdom that causing a fork requires controlling 51% of the total bitcoin mining capacity.

Also, it doesn't need to be a crypto failure. Just a divergence of the clients on how they handle the protocol. Possibly a discrepancy that would be very unlikely to occur by chance or in testing, and only manifests itself when a malicious user triggers it. This is the threat model bitcoin has to worry about now...

OK, so it's not hard to imagine double spends happening during a fork. This incident proves that as long as there is at least one provider willing to exchange BTC automatically, and is unaware of a fork in progress, then one can exploit the fork and double spend. This is bad, and should be fixed with a technical solution if possible. People will be looking for this in the future.

Here's the scary thing revealed by this bug however: Causing (intentionally) a fork is WAY easier than I thought!

You don't need to control a majority of mining. All you need is to craft a block such that some large % of the mining clients will fail on it. This could be a failure at any point in the bitcoin software. If there is a size limit discrepancy between versions (in this case the DB), or maybe a unicode parsing bug in some library used, or whatever. It doesn't need to be an exploitable code bug. It just needs to cause some % of mining clients to fail and reject a particular block.

It's relatively easy to find a bug that causes some software to crash. Most of the time these bugs are minor, and don't allow any remote execution or anything, so programmers don't necessarily worry about them most of the time. But in bitcoin they could potentially cause a blockchain fork! Which could be exploited, as this incident proves. This seems to lower the bar considerably to exploit BTC.

Right, but that's what I like about Play. They took Netty, and they took Akka and all the other really nice reactive stuff and integrated it very cleanly.

With Akka you get most of the concurrency benefits you would get from a language like Erlang, but with the benefits of having access to the entire JVM ecosystem.

Friend of doppenhe here.

Amazon, heroku etc aren't fast enough for us due to spin-up time. Basically when we get a particular command from a user, we need to do a LOT computation on many parallel machines, but for a short burst of time.

Keeping a whole cluster of machines reserved would be prohibitively expensive at this stage. We would prefer to keep a small base-load capacity reserved, and then spin up a large number of instance for a short time. Response time is key here.

It would be best if they were already up and running, waiting for a command, but idle most of the time. Fine if it's shared with others. Kind of like a computation insurance for short bursts of high-demand.

Anyone know any services like that?

Well I guess I have some citations to read later, but intuitively I just have a hard time believing that lack of training data is the problem. There's so incredibly much data available on the internet. If that was the limiting factor, it would just be a matter of throwing more data at T to increase the amount of information in M, but that doesn't help if we haven't found the right machine learning algorithm L. And searching that space is the real challenge of AI. To search that space we either need human experts, huge amounts of computational power to brute force, or some combination thereof. We've tried human experts alone for decades, without much success, so I think it's likely that we will need some computational assistance to find the right algorithms. That's why AI people love throwing around graphs of Moore's law.

While I believe the author is not wrong in his argument that information theory is a bound on machine intellignce, I think the problem with using information theoretic bounds is that it is not a tight bound. In other words, I don't think information theory is currently the limiting factor.

The author argues that any AI will consist of two parts, the machine learning program L and the training set T, which combine to form the "intelligent" program M. And thus by information theory, k(L) + k(T) >= k(M) [where k is the kolmogorov complexity]. Thus M is bounded by the information in L and also bounded by T. The author argues that since these both depend on humans supplying them, we are limited by the human factor.

But how much information does one really need for AI? Well, how much information is necessary for human intelligence? Assuming that L is our genome (ignoring epigenetics), and T is our life experiences. The amount of data in our genome is on the order of around 3gb. I would argue that's certainly within the realm of feasibility for programmer's output. How about the training set T? That's harder to say; does it include video, audio, touch, etc? How many years until a human is considered intelligent (by AI standards)? I think it's safe to say that a 10 year old blind human could pass a Turing test. So if we ignore tactile and olfactory feedback, we basically just need 10 years of compressed audio as the training set. Generously encoding the audio at 128kbps 24/7 for 10 years = 4.7 terabytes. Which is easily within the realm of current machine learning. We have far more information than that (and much more densely encoded as text), but still aren't close to True AI.

I think the problem is not that we don't have enough Information, I think it's that we have not yet searched enough of the problem space. And that's where more hardware can help us.