Insurance is all about sharing risk. I'm unwilling to risk my house burning down. I know it's not likely that it will, but if it does, the loss would be devastating to me. Most people feel that same way, so we all get together and share the risk. In return for a promise that none of us will ever have to suffer the catastrophic loss, we all chip in a small fraction of our home value every year and create a pool from which to compensate those who are unlucky enough to have their house burn down. What the insurance companies do is essentially act as a market maker for these risk pools. Rather then me have to go out and find 1,000,000 people to share the risk with, the insurance company does it for me (and takes a small fraction of the pool as their profit)

Now, the insurance company doesn't want risk any more than I do. To avoid that, they need to make sure they charge enough in premiums to pay off all likely claims. And to do that, they need to be able to accurately evaluate the probability of a claim. For open-ended liabilities (i.e. a replacement cost homeowners policy), they also need to be able to accurately estimate the maximum size of a claim.

For things like fire insurance on houses, there's tons of history to base these estimates on. They've insured hundreds of millions of houses, and have been doing it for many years. They've paid off millions of claims. For a given location, type of construction, age of house, etc, they know exactly what the risks are and can price the policy accordingly. Ditto for group health insurance, automobile insurance, and so on.

But, bitcoins? Insurance companies have no clue about bitcoins. There's essentially zero history establishing what they're worth, and likewise there's essentially zero history establishing what the risks are. How often do bitcoins get stolen, lost, destroyed, etc? What best practices exist to reduce the risk of these losses? What types of fraud might exist in bitcoin loss claims, and how can the company determine if a claim is fraudulent or not? For the most part, there are no answers to these questions. At least not today. Thus, it's unlikely that you would be willing to find an insurance company willing to accept any bitcoin risk. And if you did, it would probably come with a very high premium, fixed liability limit, and onerous conditions. For a large insured value, you might also find that the only way a company would take the risk would be if there was a consortium of companies which all took a part of the risk (this is what places like LLoyds of London are all about).

Tell me about it. I used to work in a hospital (not as a member of the medical staff). I had a labcoat that I kept mostly to keep warm when the air conditioning got too cold. If I put it on and wandered the halls, there was pretty much nowhere I couldn't go. I'll bet if I hung a stethoscope around my neck, I could have walked into the OR and nobody would have said "boo".

Adjust the costume to fit the venue. Hardhat at a construction site. Trial case in a courthouse. If you saw a guy with a pitchfork and covered in manure walking through a stable, would you stop him and demand to see his ID?

I'll go along with us not knowing a whole lot more about aerodynamics today compared to 60 years ago, but materials have improved. Carbon fiber has trumped the aluminum-titanium-unobtainium alloys they had then, both for strength/weight ratio and the ease of making complex shapes. Obviously, the avionics are a whole different world, but I assume you were talking airframes.

Consider, for example, the Russian Soyuz rocket. It looks like something out of the 60's, because it *is* something out of the 60's. And the Russians are still flying them for the much the same reason we're still flying the U-2. Because it still works. Maybe it's not perfect, but after 1700 launches, they're pretty much got it figured out. The Space Shuttle was a lot sexier, but when it came to putting mass into orbit cheaply and reliably, Soyuz won hands down.

Filter error: You can type more than that for your comment.

I could, but there's no need. The title says it all.

I had to read the headline a couple of times before I realized it wasn't "LDAP cameras".

When I worked for <Fortune 500 Tech Company>, we spent a lot of time making sure this didn't happen. Every single release involved an audit for new open source code and the lawyers had to sign off on each and every one. This was both to ensure that we were complying with the license and to give them a chance to reject license they felt were too onerous (i.e. GPL-3). Still, it's not hard to imagine something slipping through the cracks. I'm sure there are companies which don't care, but most places do try to work within the rules.

That being said, isn't after your code has already been released a little late to start trying to understand the license under which you released it?

That sounds like a reasonable plan only if the existing cabling is Cat-5 or better. Most dedicated phone cabling (especially if it's more than about 10 years old) is almost certainly not Cat-5.

Revision numbers are easier for humans to deal with. For example, here's a common flow I use every day:

$ hg pull
$ hg log | less { see some change I'm curious about and note the change number }
$ hg export 3742 | less

With change numbers, it's easy to remember 4 (or even 5) digits for the time it takes to type the export command. If I only had hashes, I'd have to copy-paste the string. Things like this matter less to people who only use GUIs. For command line folks, however, being able to easily read, pronounce, remember, and type change numbers is essential. Even if you're just talking with other people, it's a lot easier to say, "Oh, I see what happened, in change 2456, you did..." than to refer to hash strings.

I've used rcs, cvs, clearcase, perforce, dabbled in svn, dabbled in git, and am currently using hg. Of the centralized bunch, perforce is my favorite (not free, but reasonably priced and amazingly excellent tech support). I can't see anybody wanting to use svn for any new projects today. When it first came out, it was a a significant improvement over cvs and people naturally flocked to it, but there's just so many better alternatives today.

Clearcase is an interesting beast. For sure, it's overpriced bloatware that's on life support, being kept alive mostly by big legacy customers with neanderthalic IT and Release Engineering departments who still believe IBM can do no wrong. But, it did have some interesting ideas. That every revision of every file exists simultaneously in the file system namespace is really powerful.

Between git and hg, I'd say they are fundamentally identical in capability, but I find the hg command set easier to get my head around. All the people who say, "X is the best possible vcs. I used to use cvs and when I switched to X my sex life improved overnight", fail to understand that "X is way better than cvs" is true for pretty much any value of X, and says nothing about the relative merits of the various X instances.

There is an old saying: "Aviate, navigate, communicate". Once you have the airplane under control, then you worry about where you're going. And only after you've got that sorted do you bother to talk to ATC. Nothing is more important than flying the airplane. From what I can tell by reading the report (http://tinyurl.com/3wo95a3) these guys had their hands full doing that. Talking to ATC is way, way, way down on the list of things to worry about.

When I bought my current 15" MBP (about a year ago?), I paid for the 1680 x 1050 upgrade. Absolutely stunning. And it's not just "looks pretty". I do most of my work in terminal windows. If I need to see a lot of text, I can crank the font size way down and get 330 columns x 84 lines on the screen, with it still being reasonably easy to read (even with my 50-something eyes). Popping up a couple of sizes, I can get 236 x 62 and it's entirely comfortable. Good to see they're continuing to offer that option. Worth every penny for the upgrade. I got the matte screen (which, IIRC, was a no-cost option vs glossy).

Part of it is the raw pixel resolution. Part of it is that Apple's fonts (I use Monaco 13 pt antialised for most work) and font rendering machinery blows the doors off the competition. My Ubuntu system running X-11 at the same screen res isn't in the same ballpark.

The "Advisory Circular" mentioned briefly in the interview video is FAA AC 91-57, "Model Aircraft Operating Standards". You can download a copy of it from http://tinyurl.com/28wko9o . As the "A" in the name implies, ACs are advisory in nature. They do not carry the force of law, but generally if you can show that you've complied with an AC, the FAA is happy.

It's pretty clear, however, that he didn't comply with several points of the AC. The Verrazano bridge towers are 690 feet tall, and clearly he was above that, so he obviously didn't stay below 400 feet. The reason for the 400 foot limit is because "real" planes are supposed to stay above 500 feet, per 14 CFR 91.119(c). If you stay below 400 and they stay above 500, nobody swaps paint.

Given the areas and altitudes he flew in, it's unlikely he caused any hazard to jet traffic flying in or out of the three big NYC airports, but there's a lot of low-level seaplane (East River below the 59th street bridge), and helicopter traffic (numerous busy heliports all over the place) in and out of there. A plane like this is essentially invisible to the pilots of those aircraft. "Big sky, small plane" works in your favor here, even more so than usual.

It looks to me like he stayed mostly over water, so I'd guess the hazard to people on the ground was minimal. Although, I don't know what would happen if he had lost radio control. Do these things have some kind of dead man switch which cuts power to the prop if radio signal is lost? If so, then it's hard to imagine doing any kind of major damage.

The weather observing issue is tricky. Yes, it's true there are a lot of weather observing stations, but they're mostly (for very large values of most) at airports. There is also a network of about 10,000 cooperative observing stations (http://pafc.arh.noaa.gov/coop/weatherstation.php). I don't know how much overall value the coop stations add into the total weather observing system (I suspect very little, except in remote areas).

The problem with mobile sensors is that they're difficult to calibrate. A real weather observing station (AWOS, ASOS, etc) has the temperature, pressure, and dewpoint sensors in a carefully designed structure to ensure that it has free air circulation but is not in direct sunlight. The location is surveyed, so the exact elevation is known. The wind and sky sensors are likewise put in carefully controlled locations to ensure they're not blocked by buildings, trees, etc.

It's not as easy as just bolting an instrument package to the roof of a truck and driving it around. The truck itself is a significant heat source. Getting useful temperature and dewpoint readings would be virtually impossible. It also moves, so wind readings would be equally pointless. When it's at rest, it's likely to be near a building or under a tree, so even stationary wind readings would be worthless.

PHP and C are nothing like each other, beyond the most shallow typographic similarities of using curly braces and semicolons.

PHP is a high-level (albeit, brain-dead) object-oriented scripting language. It has dynamic typing. Built-in strings with automatic memory allocation. Built-in hash tables and vectors (both bound up in some kind of bizarre composite container thingie they call an array). Exceptions. Run-time symbol lookup. Introspection. Built-in hooks to integrate with a web server front-end. In short, it's nothing like C at all in any way that matters.

PHP is really Perl on steroids, with a marginally nice OO layer slathered on top.