For a long time I thought of DRBD as a wayof getting shared storage or networkbased RAID-1 (as its website puts it), and I didn't entirely see thepoint. But there's a different way of looking at it, one that's quiteeye-opening and which I was recently exposed to somewhere.

A standard high availability setup for something like virtualizationhas four machines: two frontends and two backend disk storage machines,with the storage mirrored between the backends and both frontends

Mostly for historical reasons, my office workstation still runs itsown mailer and I still get a very small amount of email to it. I getmany, many more spam attempts, because for very many years (in thepre-spam days) it was the primary email address that I used and Iused it widely. Over the years I've put up an ever-increasing set ofanti-spam precautions that wind up rejecting almost all attempted SMTPconnections.

(Technically I wind up dropping connections after sending

Over the past while, there's been a definite pattern in Linux softwareof moving from a single monolithic configuration file (or a controlfile) to a configuration that is created by scanning a directoryand looking for eligible files. From a packaging system and systemmanagement perspective, there is a lot to recommend this approach;it makes it much easier for packages and sysadmins to add and removeelements to the configuration.

However there is a drawback to this approach as commonly implemented,which is handily illustrated by Ubuntu 1

My little issue the other day with DTrace makes a nice illustration of a variantof programmer laziness . As I sortof alluded to in the entry, although DTrace's function tracing limitationis documented, I didn't actually find it by reading the documentation.Instead I found it the hard and indirect way, by being a systemprogrammer.

When I ran into a kernel function that DTrace couldn't trace, I woundup:

• using the Solaris kernel debugger to verify that the function wasactually present in the

If your software keeps some sort of database or even just reads datafiles, and you want happy sysadmins, make it always be backwardscompatible with the file formats of older versions. If you wantmoderately unhappy sysadmins, give it an automated migration process sothat it reads the old format files and rewrites them in the new format.

(This makes sysadmins moderately unhappy because we can't back out of anattempted upgrade without restoring the old versions of the files, andas a corollary we can't switch back

I have a small suggestion for C programmers: please don't use staticfunction local variables. Yes, I know, they've been part of C for avery long time, they are kind of nifty, and they're sometimes nice. Butstill, please use a file level static variable instead, which has justthe same effects.

Well, almost. There is one important difference; in practice, manymore tools can find and inspect file level static variables than canfind and inspect function static

The fine documentation for DTrace's kernel function tracer contains a little note that you mighteasily miss if, like me, you were just skimming:

For each instruction set, there are a small number of functions thatdo not call other functions and are highly optimized by the compiler(so-called leaf functions ) that cannot be instrumented by FBT.

The first thing to know is that DTrace does not have any useful errormessages when you run into this. Instead of a helpful note about, say,'this

Rather than write an extensive reply to a comment on the originalentry as another comment, I'm doing it here.So, without further delay and in the traditional Usenet style:

Are you proposing every TLS secured service which does not providestrong ciphers shows up as if it were a cleartext service?

In my ideal world the short answer is yes; both bad ciphers and nociphers would show up as plain boring insecure connections. That weakciphers are somewhat harder to eavesdrop on than cleartext is notsomething that users

I'm currently engaged in a slow-moving effort to improve the performanceof Python's os.walk() filesystem walking function (I have a long-standing interest in it and recently wrote about optimizing filesystemwalking on Unix). As part of the work I've been benchmarking severalvariants of my code, and I stumbled over a performance anomaly wherethe normal os.walk() is often faster than what should be a slightlyoptimized version of it.

It's awfully easy to dismiss