Once upon a time, we had an NFS server. Like sensible people, weimmediately put the NFS server on a UPS, which meant that if we lostpower, we wanted to quiesce the NFS traffic before we had to shut itdown.

There are probably a lot of sophisticated solutions to this problem,involving things like hooking into the UPS monitoring system andtriggering events on power loss. We opted for a much simpler method:we didn't put the Ethernet switch that the server was connected toon a

We had one of our SAN RAID controllers die today (just the controller;the disks and the data were fine), and as a result I ran across anannoying omission in the DiskSuite toolset.

When the controller went kaboom, all of its logical drives stoppedresponding and DiskSuite marked all of the submirrors involved asneeding maintenance. When the controller was replaced, all of thelogical drives came back again, but the problem is that DiskSuite has nodirect way to clear the 'needs maintenance' state on the affected

The difference between

for i in "a b"; do	mv -f $i $i-UBUNTU	...done

and

FOO="a b"for i in $FOO; do	mv -f $i $i-UBUNTU	...done

is subtle (in visual appearance) and easy to accidentally forget, but important .

(Fortunately I am doing test installations in VMWare thesedays, so a mistake is less tedious than it used to be .)

A lot of documentation of Perl-style regular expressions describes \b as'matching a word boundary' or similar phrases. Life would be simpler ifthe documentation used the phrase 'identifier boundary' instead, because\b's idea of word characters includes underscores .Thus \b and \w's idea of word characters makes a lot of sense forpicking out identifiers in languages like C, but not necessarilyso much sense for things like picking out words in written text.

(The same thing applies to

We had a power meter lying around my new office and a differentvariety of stuff from last time , so here'ssome more power consumption numbers.

First, for a random assortment of stuff:

Here's a lesson that in retrospect I first absorbed from seeingpeople fall for what were really rather bad forgeries on Usenet,way back when:

Most people aren't suspicious.

Most people see what they expect to, and don't notice what they don'texpect to. If something is missing, people fill it in automatically; ifsomething is vaguely off, people ignore it. You don't need to be good tofool people; you just need to not be bad enough to force

Over the time I've been using syndication feeds a lot, I've had to dealwith various sorts of feed problems. And I've come to a conclusion: broken feeds are usually worse than no feed at all .

Broken feeds invite you to trust them, but then betray that trust;you wind up doing extra work to make sure that you're actually seeingeverything and what you're seeing is actually there. (Broken feeds arealso frustrating ; if only they weren't broken

To follow up my previous entry , here's the sortof thing I mean by the term 'broken feeds', as taken from things I've beenfrustrated by in the wild:

• advertise a feed on your site, but never update it.
• silently stop updating your feed because it's moved to another URL .
• put in partial entries that look like full entries .
• don't include all of the new entries from your site in your feed.
• include entries in your feed that aren't actually

This week, we:

• got 15,129 messages from 287 different IP addresses.
• handled 21,714 sessions from 1,659 different IP addresses.
• received 193,764 connections from at least 45,843 different IPaddresses.
• hit a highwater of 35 connections being checked at once.

Connection volume is down from last week .The highwater is much higher and was set sometime Thursday; beforethen we had the same highwater as