Super Volatile

Very large-scale distributed systems, like ours, demand that time be well-synchronized and expect that time always moves forwards. Computers traditionally accommodate leap seconds by setting their clock backwards by one second at the very end of the day. But this “repeated” second can be a problem. For example, what happens to write operations that happen during that second? Does email that comes in during that second get stored correctly? What about all the unforeseen problems that may come up with the massive number of systems and servers that we run? Our systems are engineered for data integrity, and some will refuse to work if their time is sufficiently “wrong.” We saw some of our clustered systems stop accepting work on a small scale during the leap second in 2005, and while it didn’t affect the site or any of our data, we wanted to fix such issues once and for all.

Since most of us have already sold our privacy to Google company, it's at least some consolation to know that they care even about such seemingly minor issues like leap seconds.

There are two possibilities, and for the briefest of moments, the circuit hovers between them. In a perfect world, it might linger like that forever. But in reality, even a small amount of thermal noise—random atomic vibrations—within the circuitry will send it racing toward one of its two stable states. It's the physically random properties of the thermal noise that determine the outcome of this otherwise indecisive circuit.

In this way, our simple digital circuit can easily harvest some of the ubiquitous randomness of nature. All we need to do is to connect those two extra transistors to a clock that regularly turns both of them on and off. Every time the clock cycles, the circuit generates one random bit.

Generating truly random numbers has always been an impossible task in software, where everything can be at best pseudorandom. Intel engineers have set out to solve it with hardware and the resulting circuit is already present in Ivy Bridge processors.

Link via @adam_craven.

You might wonder why aren't there any robots that you can send in to fix the Japanese reactors," said Marvin Minsky, who pioneered neural networks in the 1950s and went on to make significant early advances in AI and robotics. "The answer is that there was a lot of progress in the 1960s and 1970s. Then something went wrong. [Today] you'll find students excited over robots that play basketball or soccer or dance or make funny faces at you. [But] they're not making them smarter.

From the discussion on the current state of AI research and the direction it should take.

The sad thing is, having worked one-on-one with several recent Computer Science graduates, I don't believe that they're learning much about programming, either. Students with a passion for programming study it in their free time, work on their own projects, and do most of their learning outside of the classroom. Fresh graduates with a BS in Computer Science and no real experience programming just don't have the skills they need to do anything but grunt work. As an undergraduate Biology student, my first CS course was on bioinformatics algorithms and had several Masters students, and when I was able to implement the algorithms quicker and more efficiently than CS students, I saw how lacking my school's curriculum was.

The article suggests making programming degree different from Computer Science degree. Interesting approach, could actually work – CS courses certainly don't meet expectations of neither students, nor the market. Yet dismissing it entirely would not be a good idea either as that would cripple the research done in academia.

• #1 trick: GNU grep is fast because it AVOIDS LOOKING AT EVERY INPUT BYTE.
• #2 trick: GNU grep is fast because it EXECUTES VERY FEW INSTRUCTIONS FOR EACH BYTE that it *does* look at.

Technical explanation of algorithms used by grep.

Experience has shown, however, that descriptive complexity also a powerful tool for fooling yourself into thinking you’ve proven things that you haven’t.

The man who has a fault in recent paper claiming that P≠NP explains his reasoning.

The idea is that 17 will always be the most common answer when people are asked to choose a number between 1 and 20. But neither Cosmic Variance nor Pharyngula offered a reasonable means of testing this proposition. That's where our poll came in. This morning, I took a look at our data, and with 347 responses, I can confirm that 17 is significantly more popular than any number.

It turns out human have very strong and precise sense of what is random and what's not. Which is exactly the opposite of randomness.

In the end, they conclude that NP-complete problems are just as hard on an adiabatic quantum computer as on a classical computer. And, since earlier work showed the equivalence between different variants of quantum computers, that pretty much shuts down the possibility of any quantum computer helping with NP-complete problems.

It's seems like the hope for solving NP-complete problems in polynomial time is gone again.