This is a grump.

Dear X applications (or any application on any window system): youshould never, ever kill or otherwise force-terminate the screenlocker. In particular, you cannot assume that just because you havebeen run that the user is sitting there in front of the screen and wantsit unlocked. There are any number of ways that you can start up whenthe user is not present, and unlocking the screen in this situation caneasily make things go horribly wrong.

For one example, perhaps

One of my sysadmin rules of thumb for deciding what to automate in scriptsand programs is this: automate where you can make mistakes. In particular,automate where you are specifying redundant information.

This will make more sense with an example, so let's talk aboutconfiguring iSCSI targets. We use static target configuration, whichmeans that you tell the system a target name and the IP address that itcan be found on; each iSCSI server has two IPs, so we configure each ofits targets twice, once

One of the less than obvious things about Python is that it can mattera lot just how you access an object, and not just for performancereasons. Accessing the same object through two different names can havedrastically different results under some circumstances, as yesterday'sentry about frame.f_locals shows.

(This is especially the case when resolving one of the names involvesa C module (instead of just a Python one). C modules generally need'getter' functions to translate their C-level data

Some time ago I wrote that there was no way tochange a function's local variables from outside it (well, specificallytheir name bindings ). As it turns out, I'm wrong;there is one way to do it by going in the back door, although it's nota useful way.

There is specific code in CPython that allows a trace function to completelyalter a function's local variables and even function arguments; this (C)code specifically reloads the internal interpreter version of

The first change we made in the evolution of our mail system was to add a separate machine to be ourexternal mail gateway, putting it in front of our central mailmachine for outside email. We did this for two reasons: first, wewanted to introduce some sort of system-wide anti-spam features , and second, the central mail machine washeavily overloaded by directly handling external email (partly becauseit had a very old MTA that had an unfortunately heavyweight way ofhandling incoming connections and partly because it

One of the problems with our old central mail system is that it was a black-box mailer configuration ; the valid localaddresses and domains were defined by what the mailer accepted, and whatthe mailer accepted was more or less in code, not in handy configurationfiles. This presented an obvious problem for the evolution of our mailsystem .

So our first job was to reverse engineer what addresses the centralmailer accepted, and figure out how to turn these into reusableinformation for the new mail machines we wanted tobuild

Here is something I've noticed lately: when I want to look for tracesof some recent or just-breaking piece of news, such as IPSCa's utterfailure or important potential Solaris licensingchanges , I no longer bothertrying Google or other general search engines; instead, I go to Twitterand search there. And it works. There's a certain amount of noise in theresult but also a lot of signal, more than I could easily get otherwise.

Partly I think that this is because

Way back in the beginning of time, or at least when I arrived here , we had a rather old mail systemconfiguration that was very much an artifactof its time. In other words, it desperately needed to be modernized andreplaced. And replace it we did, winding up with our current mailsystem .

There are two ways to describe how we planned the migration from the oldsystem to the new one. Let me write up the nice one first:

There are at least two possible approaches you can take

A while back I wrote about what disk IO stats you get from the Linuxkernel . At the time I talked only about full devices,not partitions, but recently I've become interested in the subject ofwhat IO stats are maintained for partitions (because sometimes you'reinterested in per-partition information).

The answer depends on what 2.6 kernel version you have. In kernelsbefore 2.6.25, you only have counts of read and write IOs issued andsectors read and written