I've used programs that do logging (both well and badly) and I've alsowritten programs that did logging (also both reasonably well and badly)and the whole experience has given me some views on how I like loggingsplit up to make it more controllable.

It's tempting to say that controlling logging is only for exceptionalcases, like debugging programs. This is not quite true. Certainly thisis the dominant case, but there are times when people have differentinterests about what to log even

In the wake of Heartbleed , we've been writingsome password guidelines at work. A large part of the discussion in themis about how to create memorable passwords. In the process of all ofthis, I realized that I have a heresy about memorable passwords. I'llput this way:

Memorability is unimportant for any password you use all the time,because you're going to memorize it no matter what it is .

I will tell you a secret: I don't know what my Unix

If you're faced with a problem of coordinating reads and writes on anNFS filesystem between several machines , youmay be tempted to use NFS locking to communicate between process A (onmachine 1) and process B (on machine 2). The attraction of this is thatall they have to do is contend for a write lock on a particular file;you don't have to write network communication code and then configure Aand B to find each other.

The good news is that this works, in

One of the things said about modern filesystems like btrfs and ZFS isthat their volume management functionality is a layering violation; thisview holds that filesystems should stick to filesystem stuff and volumemanagers should stick to that. For the moment let's not open that canof worms and just talk about what (theoretical) modern filesystems needfrom an underlying volume management layer.

Arguably the crucial defining aspect of modern filesystems like ZFSand btrfs is a focus on resilience against disk problems. A modernfilesystem no longer trusts disks not

In a comment on my entry about NFS's problem with concurrent writes , a commentator asked this very good question:

So if A writes a file to an NFS directory and B needs to read it"immediately" as the file appears, is the only workaround to use lowvalues of actimeo? Or should A and B be communicating directly withsome simple mechanism instead of setting, say, actimeo=1?

(Let's assume that we've got 'close to open' consistency to startwith,

I recently finished reading this LWN series on btrfs , which was the most in-depth exposureat the details of using btrfs that I've had so far. While I'm sure thatLWN intended the series to make people enthused about btrfs, I came awaywith a rather different reaction; I've wound up feeling that btrfs hasmade a significant misstep along its way that's resulted in a number ofdesign mistakes. To explain why I feel this way I need to contrast itwith ZFS .

A commentator on my entry on the warnings problem pointed out the existence of the warningsmodule as apossible solution to my issue. I've now played around with it and Idon't think it fits my needs here, for two somewhat related reasons.

The first reason is that it simply makes me nervous to use or even takeover the same infrastructure that Python itself uses for things likedeprecation warnings. Warnings produced about Python code and warningsthat my code produces are completely separate things and I don't

Supposes that you have some shiny new SSL certificates for some reason . These new certificates need a chain ofintermediate certificates in order to work witheverything, but for some reason you don't have the right set. In idealcircumstances you'll be able to easily find the right intermediatecertificates on your SSL CA's website and won't need the rest of thisentry.

Okay, let's assume that your SSL CA's website is an unhelpful swamppit. Fortunately all is not lost,

Python has a well honed approach for handling errors that happen at alow level in your code; you raise a specific exception and let it bubbleup through your program. There's even a pattern for adding more contextas you go up through the call stack, where you catch the exception, addmore context to it (through one of various ways), and then propagate theexception onwards.

(You can also use things like phase tracking to makeerror messages more specific. And you may want to catch