cdjk

We have a fireplace. It's our primary source of heat. It's efficient, however - an EPA approved catalytic model. The smoke from the chimney is very light, and once it's burning dissipates very quickly. Plenty of stoves/fireplaces produce a blue pall of smoke that hangs over the entire area for days, and it's not one of those.

I'd be curious to know if studies included modern and correctly-installed stoves as well.

That's exciting, and something I might be interested in. My question and concern, however, is that Tahoe-LAFS seems better suited for distributed storage among unreliable nodes. I consider rsync.net to be fairly durable storage, especially since the way I use it is as backup and not the only storage location for a file. I have the same question about using S3 as a tahoe backend, which is another thing I've seen.

Of course, you could just use Tahoe-lafs to store everything on one or two nodes when they're reliable and durable, but then why not just use gpg or encfs, which don't require custom clients or gateway/introducer nodes?

I'm not sure how easy it would be to store git repos on Tahoe-LAFS, but there are two other options - 1) duplicity has native support for Tahoe-LAFS as a backend, or 2) use git-annex with a special remote [1].

[1] http://git-annex.branchable.com/special_remotes/

I'm curious about the paper backups - how do they do it, what's their recovery procedure, and have restores been tested?

How did you get to do that? That must have been an amazing experience.

I think there is some value in multiple-rep olympic lifts, but technique still has to be the most important thing. Rippetoe's starting strength program is 3x5 for all the lifts except power cleans, which are 5x3. Going much over a set of 3 or 5 with heavy weight is not a particularly good idea.

I am thankful for crossfit because it introduced me to powerlifting. But I quickly realized I liked the strength portions a lot more than the AMRAP (as many rounds as possible) and other timed workouts.

The official line is "you're only competing with yourself," but in practice that's not the case. Especially when there's a whiteboard and everyone knows what the various times/number of reps are. Trying to force anything with a strong technique component (like olympic lifts) into a time based or number of reps based competition just seems like a bad idea.

Also, with the wide variety of WODs, it's hard to track progress. Yeah, the workouts repeat, but if you only do something a couple times a year it's hard to keep track of progress.

I ended up doing Starting Strength instead. I got my squat from about 80lbs to 245, and then 295 with some intermediate programming. I almost never got sore - only a little sore after the first couple workouts, or if I missed a week or two. I'm currently trying to figure out how to integrate cardio and lifting, which is one thing that crossfit has going for it, but I liked powerlifting workouts a lot more than crossfit.

I always figured if there was a serious claim to that area that Egypt and Sudan would be pretty quick to work out their differences.

I think the primary advantage is that ZFS collapses all the standard filesystem abstractions. With mdadm or hardware raid you have a raid controller (which could be mdadm), volume manager (i.e. lvm), and filesystem (ext4, xfs, etc). ZFS combines all of that into one. It's really a different philosophy, but means that things like creating a new filesystem is almost instant (and CoW, snapshots, replication are all easy - although perhaps that's possible with the traditional abstractions as well).

ZFS has the notion of version numbers - for both the zpool and filesystem. The last FOSS releases are zpool 28 and zfs 5. There have been subsequent releases of ZFS by Oracle, but versions 28 and 5 are the latest used by all the open source implementations.

What the FOSS community has done is to add "feature flags" to ZFS instead of constantly bumping the version number. So encryption is a feature on top of zfs, but the encryption introduced in FreeNAS for ZFS isn't the same as the encryption in Oracle's zpool v30.

I was thinking about that article too - I've read it a couple times, and it's always interesting.

Reading about things like this makes me question whether I should call myself a software engineer or programmer - somehow what I do doesn't seem in the same category of things these people do.

Prospective study was probably not the correct term, since that's an epidemiological study. "Placebo controlled study" is probably a better term. And a placebo controlled study is the best evidence for a medical treatment - doing epidemiological studies to determine medication effectiveness doesn't seem right.

Consider an SSRI study for depression. I want to know if someone who is depressed and takes it does better thank someone who is depressed and doesn't take it, or takes a different drug. I don't care what it does in a healthy population, since they probably won't be taking it. I mean, the effects of SSRIs in healthy individuals is an interesting topic, but not relevant if I'm investigating depression treatments.

War and Peace, Anna Karenina, any recent book by Neal Stephenson - those are all much more pleasant on a kindle than in paper form.

The hardware upgrade doesn't look that impressive - I'm happy with the current papewhite. The pageflip UI looks like it could be useful, as that's one of the few UI complaints I have with the kindle.

Personally I find the FreeTime feature to be the most interesting, or maybe amusing. They're gamifying reading, but I suppose parents were doing that already (read X books, get Y).

Now if only they'd fix hyphenation and justification, or make it easy to enable ragged right text I'd be happy. Currently I have to reformat everything in calibre before I read it.

Only one of the circles on the charger matters (I'm at the office now so I can't check it). It's actually really easy to clean that off with your finger, and that's the only thing that matters in terms of holding it on.

It's still a bad design, but once I figured that out it was useable again.

Uh, no. Risk aversion is rational. It seems like you're equating rationality with risk neutral preferences, which I, and a lot of other people disagree with.

Besides, it's all about risk preference. As long as my preferences are consistent and transitive, I think it's safe to say they are rational. Take the fire insurance example. Suppose I have a job that pays $10k/year. I would gladly pay $200/year to avoid the possibility of a $100k loss. Those are my preferences, and as long as you can't a non-transitive loop, it's perfectly rational of me to have those preferences. In this case, I'd value the guaranteed loss of $100 to be a much better outcome than the risk of loss of $100k.

In short, rational != risk neutral.

Lottery - sure, that's a scam, barring the odd situation where a positive expected value is possible. Insurance on small events (i.e. the extended warranty from Best Buy) could be described as a scam, but homeowners insurance/car insurance isn't.

The whole reason insurance exists is because of differences in risk tolerance. What is a huge risk for me, such as a fire destroying my house, is a relatively small risk for an insurance company that is insuring against fires across the entire state. What I pay the insurance company for is to assume part of that risk.

Consider homeowners insurance, and more specifically fire insurance, in this admittedly contrived example. Suppose that in the next year there's a 1/1000 chance of a fire that will cause damage that will cost $100k to repair. That has an expected value of $100. Well, since $100k is a lot of money to me, I'd rather pay someone $200 than take a bet with an expected cost of $100, even though paying $200 has a negative expected value. That means I am risk averse for potential gains and losses on the order of $100k, and would rather take the more certain side of a bet, even if it means it has a lower expected value.

Take another example. Suppose I'm worried about losing or breaking my cell phone over the next year, and it would cost $500 to replace. AT&T charges $6.99/month for insurance on the phone. Over the course of a year that's about $84. And furthermore suppose there's a 1/20 chance that I'll lose/break/etc my phone during that year. Without insurance, the expected value of the loss is $25. Unlike the $100k example, $500 isn't that big a deal to me, so the insurance is a horrible deal for me, because I'm risk neutral for a $500 loss.

Of course, real life is more complicated. Homeowner's insurance protects against risks other than fire. Risks to the insurance company can be correlated - something on the order of the 1906 SF fire is a large risk, even to an insurance company, which is why there is reinsurance. There are deductibles that change the pricing. But still, as a simple example, that's how insurance works.

In the US that would be illegal, and get you in serious trouble with the FCC.

What is possible, however, is for the prison to run its own cell tower with whitelisted IMEIs - i.e. only the guards' phones.

That could work, but the advantage of an HSM is that the key material is physically prevented from leaving the device, barring acid/x-rays/other attacks. All encryption happens on the device itself. With an open ssh connection you could still remove the key material from computer.

It's called a hardware security module (HSM) [1]. The basic idea is to store the private key in the tamper-resistant hardware, along with a microprocessor to perform the basic encryption options you need. They can be relatively cheap, like a smart card + usb smart card reader, to very expensive, like an IBM 4764. Yubikey sells a usb HSM if you want to run your own authentication server for around $500.

There's a whole chapter dedicated to HSMs in Security Engineering [2], which is available online. There are clever ways to attack them, and yes, the booby trap idea has been done, typically by using something light-sensitive. I'm not aware of any concrete-encased HSMs, however...

It's an interesting topic. That are lots of challenges around them too. It will probably have a battery backup, so how do you allow someone to replace the battery without wiping the keys? Or can only people with access to the keys replace the batteries? That won't work if you're doing mathematical secret sharing, however, since there's no physical way to do that.

  [1] http://en.wikipedia.org/wiki/Hardware_security_module
  [2] http://www.cl.cam.ac.uk/~rja14/book.html

I'm pretty sure that the recruiters are all contractors, and are all fairly independent. I think that's the only think that explains stories like this, as well as some experiences I've had with them.

I interviewed at Microsoft quite a while ago, and the process was fairly pleasant. My only complaint was that eight hours of straight interviews is a little long.

I'm really surprised that's not how it works at Google, both from their perspective, from the perspective of the candidate. I would be extremely hesitant to interview or accept a job at Google if didn't know what I'd be working on, and it seems like you only find that out when you show up the first day.

Unless it's a strict liability crime. In the bubblegum example, I believe you could be convicted of something like manslaughter without mens rea. The CFAA is not a strict liability offense, however, as far as I'm aware.

This is awesome! I've been meaning to use mailgun for some small personal projects, but didn't want to pay to use my own domain. That's the biggest advantage of the change for me.

It looks like there are two books with similar titles - which one are you reading?

Blind Man's Bluff is good, as another poster suggests.

Another fun one is "The theory that would not die," about the history of Bayes rule.

So you have a customer that's just about to buy your product, and you're sending them away from your site? I mean, as a consumer I like discounts, but as a programmer I really want my customers to just click checkout at that point.

True. You can get the same thing with referrer URLs that apply a coupon code behind the scenes, e.g. example.com/store/fifty_off. The logic is the same, you're just hiding the troublesome coupon code field.

It causes noticeable dropoff in stores. I don't remember the numbers, but we did an A/B test and noticed a difference. We switched to referrer URLs for discounts instead. I wanted to try an experiment of putting a bunch of low value discount codes out there that would have been easy to find, and see how that affects dropoff, but we never did that.

This is very cool. For a slightly easier way of experimenting with a lisp machine it's possible to install OpenGenera. There are scattered tutorials online, but here's one I've found:

http://www.cliki.net/VLM_on_Linux

I've been meaning to try this - perhaps I'll write up a better tutorial (or better, an ansible playbook) to set it up.