One of the things that I think happens in the general area of disasterrecovery is that the terminology gets confused (partly because a lot ofpeople, myself included, sort of have their toes near the water withoutactually being specialists). Because some of my views about disasterrecovery plans turn on what I consider a DR plan to involve, I want towrite down my views.

(I've sort of mentioned them in passing a couple of times recently but Ifeel like making things explicit.)

So I

Here is one core thing about meaningful disaster recovery plans: theyall require preallocation of resources. This may range from actualservers in actual racks in an actual machine room, all humming andready to go the moment that you need them, all the way to simply abunch of money that is reserved for disaster recovery so that you canimmediately start buying new hardware and renting colocation space (orsimply getting more cloud computing capacity).

If you do not have these preallocated resources, you do not really havea disaster

When you draw up disaster recovery plans for your organization'scomputers, there is something very important to remember: theultimate goal of a DR plan for computers is to help the organizationto keep working in the face of a disaster . On the one hand, thissounds obvious. On the other hand, there is a huge differencebetween allowing the organization's computers to keep working aftera disaster and allowing the organization to keep working after adisaster. The difference is that there are plenty of other things that

A commentator on my first entry on this both correctly noted that I had mis-attributed the RFC that originatedthis (I learned it from RFC 822, but it originally was invented in RFC724) and had some reactions to my idea, which means that I need toclarify it and add some additional comments. They wrote:

Comment-folding whitespace? Please, no. No. :( Comment-foldingwhitespace is the bane of people handling email.

In a sense, I entirely agree

Disagreeing with Tom Limoncelli is sort of taking my life into myhands, but sometimes I can't help it. I have large and complexreactions to his All outages are due to a failure to plan , but to start withI want to jump on one bit:

What about the kind of outages that are completely unavoidable? Thatis a failure to plan to have an SLA that permits a reasonable amountof downtime each year. If your plan includes up to 4 hours ofdowntime each year, those first 2

One of the things you often want when designing configuration files andlittle domain specific languages is some way of splitting a single longlogical line into several physical ones. In other words you want someway of marking line continuations. Over the years people have come upwith a huge assortment of ways to do this; you can have a language withexplicit terminators and just ignore newlines, you can put backslashesat the end of incomplete lines, and so on.

(Some languages have several different ways of continuing lines, depending

Since I tweeted aboutthis recently, I might as well explain myself.

Sometimes there are small drawbacks to the perpetually popular file based approached to blog engines. Oneof them is the question of how you handle draft entries, ie entriesthat you're in the process of writing and that you aren't yet ready topublish. The hairshirt approach is to not do anything about them at all;your blog is only for published entries and you have to write draftsentirely outside of it. This is simple but

A commentator on yesterday's entry wrote the standardsort of anti-JavaScript note. Quoted in part:

[...] 99.9% of websites do not need scripting. (Perhaps 100% -- googlemaps should be a standalone program.) I am convinced JS is a make-workphenomenon by a large amount of underemployed web-monkeys, desperateto create "work" that is not needed. [...]

I disagree strongly. Despite my grumbles yesterday and

I've recently formed an opinion about why people keep wantingJavaScript, or perhaps I should say instead 'come to a realization'. Putsimply, people want to increase the interactivity and responsivenessof their websites .

Let's rewind to the old days of basic HTML websites, which you have toadmit are neither very interactive nor very responsive. You interactwith such sites pretty much only by clicking on links (or formsubmission buttons) and they respond by giving you a new web page, whichis usually