Suppose that you want to fix the SSL CA racket, so that SSL CAs actuallyhad a motive to do a good job (whatever that means). One vaguelypopular approach is to align their economic interests through thetraditional tool of liability, so you pass laws that make SSL CAs liableif they issue bad certificates. However, as I've mentioned before , I don't think that this will actuallywork.

The core problem that I see is jurisdiction, in two forms. The first andmost obvious

To expand on the previous entry , there'sa number of factors that influence how fast Unix script languages and programs written in them can start and whetherit matters.

First off, people are generally not going to notice interpreter startupdelays today, on normal hardware. Modern hardware is more than fastenough to get script startup time below our perception threshold, andmost modern Unix machines are under low load with plenty of free memory(when they aren't, people sort of accept that everything is slow).

A while back I mentioned that one reason I'm interested in Go is that it is compiled, not interpreted.Now it's time to elaborate on what I called 'the interpreter issue'.

First off, on Unix there are some things that interpreted languagessimply cannot do ( I've mentioned this before ).One potentially significant limitation for an otherwise attractivehigh-level language is that you cannot write (script) interpreters in aninterpreted language; the target of a ' #! ...

One possible answer to my testing problem from the last entry is that I should simply get to workcreating the large test data needed. Some times programming involvesdoing tedious work that we don't like, and this is one of them.

I disagree, because one of my firm opinions is that it should be easy towrite (good) tests. What I want is easy automated tests .

Everyone understands why you want the tests to be automated. Having thetests automated means that you will actually run the tests

One of my weaknesses as a modern programmer is that I don't reallyunderstand how to do test driven development. I understand the basicideas of automated testing and unit testing and so on, and haveused them to reasonable effect every so often; where I fall down isunderstanding how to test things in more advanced and challengingcircumstances.

My current example of this is our ZFS spares handling system. Simplifiedslightly, the core program works by reading state information on all ofthe ZFS pools and their components (some

I have a message for developers, and not the one you might think. Hereis my message:

Sometimes memory allocation failures are not because the system isout of memory .

There is a subset of programmers who do not want to really deal withmemory allocation failures, and to be honest I can't entirely disagreewith them; recovering from memory allocation failures in a complexprogram that also wants to use as little memory as possible is quitenon-trivial and rather contorted. Apart from just exiting on the spot

One of the consequences of yesterday's SAN backend failure is that I found a bug in our spareshandling code. It was the kind of bug where the program aborts, and whenthat happens we started getting email with Python exception backtracesthat ended in what struck me as a very odd exception:

KeyError: False

Normally KeyErrors make a kind of sense, in that you see whatyou're looking up and the question is either why you wound up usingthat key or why that key isn't present when

One of my bad habits as a Python programmer is that I am both lazy andimpatient. I will go out of my way to do something overly clever justbecause it saves me some boring boiler-plate code, and because Python issuch a compact language already my threshold for this irritation is verylow.

One of the things that this leads me to is writing conditionalvariable initializations like this:

var = Noneif condition:    var = something()

I've recently come to the conclusion that this is a

Today we had an entire iSCSI backend fail . Itwas a heart-stopping non-event , something that took me perhaps 20minutes to deal with. I'd like to run down some of the reasons whythings worked out this way.

• we have set up monitoring and it works ( the former doesn't alwaysimply the latter ). Smartd onthe iSCSI backend started mailingus about 'cannot open device' errors almost immediately, which arenever a good sign, and the ZFS pool health monitoring