codahale

Off the top of my head.

Ah, another person who's never come close to examining Scala's actor implementation. Check out scala.actors.FJTaskScheduler2. It uses threads. That's, uh, kind of the only way to get a JVM process to do things concurrently.

Despite this massive divergence from a common genetic ancestor almost 20-40 times longer ago than our species has even existed, folks still want to base what it means to be a human on what it means to be a gorilla or a chimpanzee.

To make an easier point: do you think you could be typing on a keyboard designed and manufactured by humans using a computer designed and manufactured by humans which communicates with other computers using protocols designed, implemented, agreed upon, and re-implemented by humans in order to use a service provided by a human so that humans could meet and talk about a tiny slice of the things humans meet and talk about if humans weren't embarrassingly social and cooperative?

If one finds a vulnerability, follow the rfpolicy[1] or similar. Send an email to security@example.com, not Kevin Rose. (Seriously—Kevin Rose? What the hell does he have to do with Twitter's security response team?)

[1] http://www.wiretrip.net/rfp/policy.html

First, check http://svn.debian.org/wsvn/ for the package you're lusting after. (In this case, pkg-ruby has the ruby1.9.1 package at 1.9.1.243-2 on trunk.)

Then, use svn-buildpackage to build yourself the damn package.

Finally, install the package, basking in the warmth of replicable, reversible package management.

Caching is equally unlikely to play a role. You're probably thinking of DJB's timing attacks on AES (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf), but that attack resolves around the timing of S-box lookups in which the index of the lookup is key-dependent. In the constant-time algorithm proposed by Nate Lawson and others, the only array lookup is the incremented value of a for loop (i.e., constant-time). The other operations are XOR and OR, both of which are constant-time.

Branch prediction doesn't come into play because a constant-time comparison doesn't involve conditionals until all the data has been compared.

A constant-time implementation of AES? Hard. A constant-time implementation of an array comparison? Dead simple.

Not sure why you're so resistant to the idea.

http://github.com/lvv/git-prompt/tree/master

Although nanosleep() takes a timespec struct that allows you to give an accuracy with nanosecond precision, nanosleep doesn't really give anywhere near that level of accuracy. Under Linux, the kernel only checks on timers once every "jiffie," which defaults to 1 ms under the 2.6 kernel (on older kernels it was 10 ms, and 10 ms is still a compile option in the 2.6 kernel). Once upon a time, nanosleep would busy-wait if the sleep time given was less than 2 ms, but not anymore. On the other hand, don't be too discouraged—as long as you don't need submillisecond accuracy, nanosleep() is very good…

http://www.ddj.com/linux-open-source/184402031

(In some languages—hi Ruby!—you might not even have access to reliable millisecond-resolution timing.)

No idea why Mint doesn't do it. I had always assumed it was because they were share-cropping on Yodlee's architecture.

(Full disclosure: I work for Wesabe, but my snooty attitude is my own. ;)

(And yeah, ⌘⌥T is your friend when it comes to the appropriate typography.)

Crosby et al. conclude: We have shown that, even though the Internet induces significant timing jitter, we can reliably distinguish remote timing differences as low as 20µs. A LAN environment has lower timing jitter, allowing us to reliably distinguish remote timing differences as small as 100ns (possibly even smaller). These precise timing differences can be distinguished with only hundreds or possibly thousands of measurements.

If you'd like to bet that this sort of statistical analysis will get harder to perform over time, I'll take your wager. I'm not willing to wait until someone is publicly compromised before I fix security vulnerabilities—I do not work for an employer who's willing to tolerate a few break-ins before fixing the locks.

I'd also argue that a) a timing attack vulnerability is "weak/poor crypto," b) I don't need to write about the importance of other attack vectors (XSS, CRSF, social engineering, telepathy, bats, etc.) while writing about timing attacks, and c) if timing attacks are easy to understand and fix there would be less of them.

(Edit: fixed the B&B paper link. Derp.)

(Full disclosure: I work for Wesabe.)

http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf

Adding jitter will not defeat timing attacks unless the jitter is dependent on the input, like blinded RSA.

The behavior of the DBs as far as resource consumption is interesting, but the numbers are meaningless.

Further reading:

http://www.ibm.com/developerworks/java/library/j-jtp12214/

http://www.ibm.com/developerworks/java/library/j-jtp02225.ht...

Two slices—75kcal * 2—and a hunk of Nutella—190kcal * 3—is way the hell more calories than I should be eating as a snack (720kcal). Veeeery easy to go overboard.

It addresses self-control: evidence exists to support the idea that human have a limited amount and range of focus of self-control, and can suffer from self-control fatigue:

http://www.stolaf.edu/people/huff/classes/GoodnEvil/Readings...

Hell, that paper was on HN not long ago.

Self-control is not a great vehicle for weight loss, as is evidenced by the recidivism rate for diets, fad or otherwise. "Use self-control" is shitty advice for weight loss. "Avoid the cue-dopamine-behavior-opioid reinforcement cycle by using cognitive psychology self-talk to associate negative emotions with salient cues, consciously pre-determining behavior for when one is presented with salient cues, and avoiding hyperpalatable foods with high levels of salt, sugar, and fat" is closer to the mark, though it's not as punchy. Also doesn't provide the same sense of moral self-satisfaction from being stronger than fat people.

I have no idea where you're coming from with the special snowflake crap. The article was not titled Exercise Won't Make You Thin (So Buy A Mu-Mu And Eat Up Fatty Because You're Never Going To Change And That's OK). In fact, the article concludes with: "In short, it's what you eat, not how hard you try to work it off, that matters more in losing weight. You should exercise to improve your health, but be warned: fiery spurts of vigorous exercise could lead to weight gain."

I fail to detect the self-esteem happy-talk fatalism to which you're reacting.

Or, alternatively, fat people are sissies. It's an, uh, interesting theory you've put forth. Best of luck in getting that paper published.

Weight loss programs have to focus on preempting and managing appetite. There's a wealth of studies connecting exercise to increased appetite (c.f. OP), especially focused, running-at-the-gym, doing-penance-for-those-donuts exercise. (Low-level activity—walking around, say—doesn't seem to provoke the same uptick in hunger. But it also burns way, way less calories.)

Your counterfactual assumes that the runner isn't more likely to eat an additional 2,000 calories, which is to say, they're already managing their appetite. If you can manage your appetite, then go for a goddamn run already. You'll be happier for it. If you're not managing your appetite, work on that—exercise will not help you lose weight until you do.

There's a great book—The End Of Overeating—which details the intersection of modern food science, evolutionary psychology, cognitive psychology, and human physiology. If you're interested, give it a go.

(BTW, bringing up elite athletes doesn't help the discussion—elite athletes regularly have 1.5-2 times the VO² max of even extremely fit people. Hell, five-time Tour de France winner Miguel Indurain could circulate 7L of oxygenated blood per minute compared with the 5-6L of his competitors and 3-4L for the fitter of us regular people. Human physiology has a statistical distribution, and bringing up people many standard deviations from the mean doesn't help any of us regular schmucks. My mutant power certainly does not involve my metabolism.)

They just pass the plaintext right through to RSA. No OAEP, just bang right into the BigInt. There's some random gibberish appended to the plaintext ("hey, this needs some salt"), but they're not padding a damn thing. Bleichenbacher's chosen-ciphertext attack; game over.

The RSA decryption, server-side, isn't blinded at all. Timing attack free-for-all there. Boneh's timing attack might work, as long as you can pin the session down. (And since this is for folks who don't get SSL, I'm sure you could.)

And key generation is equally horrible. The lack of a real CSPRNG was pointed out by someone else. They're also not protecting against Fermat factorization: when they generate p and q they only check equality and primality, not distance. Same with small decryption exponents. Unlikely to be serious, but it sure doesn't speak to their skills as cryptographic implementers.

Jesus H. Christ. What a train wreck.

Just because one has a very sharp knife does not mean one should wave it around in casual conversation.

    Lists.newArrayList(1, 2, 3)

    ImmutableList.of(1, 2, 3)

I'll pass.