simpleigh

> The point of looking at the monetary value is that it's a way to quantify how unavailable they are. Land costs money. Where land is scarce, it becomes expensive. Where land is abundant, it's cheap. If landing slots can be acquired cheaply, it means there is availability.

Sure, but I think you're missing the point about the "non-availability." I don't think the cost shows everything.

When there's lots of slots available then the price will be low. When there's few slots available then the price will be high. When there's _very few_ slots available then prices are harder to compare. There's an upper limit on what a company will pay (a slot can only provide so much profit, after all, even if you expect to own it for many years). Prices will presumably start to depend more on who's bidding for them and what deals can be struck.

Free market economics only works if the market is able to respond (i.e. it's relatively liquid).

I'm a big fan of The Old Reader. The UI is quite similar to Google Reader (as I remember it), and because it's only focussed on feeds it's not cluttered with other functionality. There's even a working Windows Phone app (TORUC) for those of us still avoiding Apple or Google.

I've taken out a subscription in the hope that it will last longer than Google Reader or Bloglines (anybody remember that?).

I don't agree with this strategy. A spare PC under a desk might work perfectly for years without any trouble. Alternatively you might spill coffee over it next week and destroy the server - and your business.

If you don't know how you'll need to scale then chuck up a `t2.nano` instance on AWS and use that. In return for a tiny monthly cost you get: - solid network connectivity - disk snapshots for backups - geographically redundant storage (S3) for static resources so you can survive the server hosing itself - monitoring of CPU load / status / disk usage - the ability to scale the server up vertically with the click of a mouse and 60 seconds' downtime - (with a tiny bit more work and cost) automatic scaling so you cope _automatically_ if the server falls over or load increases

Clearly it's possible for the Swedish prosecutor to find a means to interview him in the embassy. They could use the telephone. They could use a videoconferencing system. They could get on a plane.

Why should they?

They have a valid arrest warrant for a fugitive. Their usual process is for the fugitive to be brought to a convenient location in Sweden for questioning. Why does this fugitive have the right to insist a public servant comes to see them? (Assange's fears about extradition to the US aren't relevant to the Swedish prosecutor if they aren't intending to do that).

If I were a prosecutor dealing with a busy case load I might well do the same: especially when I can leave the whole mess for the UK to deal with!

A few years ago there was a series of adverts in the UK advertising exactly this danger. You might think you're OK with only a broken nose, but you've just crushed the person in front of you to death.

Sorry to sound so melodramatic, but I think that was the point of the advert!

Are you sure the button becomes difficult to use? I might be very wrong here, but I'd at least hope that "release easily even when hanging upside down" might be a design requirement of the average safety belt buckle. Perhaps this is why aircraft belts have very different buckles than car belts? Can anyone provide more detail?

I agree with this - the right place to restrict the number of concurrent database queries is the database, not the whole IO layer!

The article addresses this:

> The -F for grep indicates that we are only matching on fixed strings and not doing any fancy regex, and can offer a small speedup, which I did not notice in my testing.

I guess grep is probably clever enough to choose a faster matching algorithm once it's parsed the pattern and discovered it doesn't contain any regex fun.

I agree with this completely. I think the point of all interviews should be to start a conversation - and the sort of broad technical conversation this question inspires is a really good way to see both what candidates know and how they communicate it.

I've had candidates fail to explain the distinction between the client and the server. I had one candidate exclaim "I hoped you'd ask this" and jump straight into a discussion on the parsing of cache-control headers by proxy servers.