Back in this entry I said thatlarge writes to pipes blocking instead of immediately returning with ashort write was a sensible API decision. Today let's talk about that,by way of talking about how deciding the other way would be a bad API.

Let's start with a question: in a typical Unix pipeline program like grep , what would be the sensible reactions to trying to write a largeamount of data returning a short write indicator? This is clearly notan error that should cause the program to

I've danced around this subject before when I've written about bugreports (and making bug reports), but I want to come out and sayit explicitly: far too often, making bug reports is an exhaustingexperience that is frequently frustrating and stressful .

This is not because the tools for doing it are terrible, althoughthat doesn't help. It is because the very frequent result of tryingto make a bug report is having to deal with people who don't believeyou, who don

In comments on my entry about CentOS bug reporting , opk wrote:

If it is essentially an upstream bug and not packaging I tend to thinkit's far better to wade into the upstream swamps as you call it. Ionce packaged something for Debian and mainly gave it up because ofthe volume of bug reports that were basically for upstream but I hadto verify, reproduce, and forward them.

Then Pete left a comment that nicely summarizes the problems withopk's suggestion:

[...] But

Suppose, not entirely hypothetically that youhave an Illumos (or OmniOS or etc) system that is experiencingsomething that looks an awful lot like kernel contention; forexample, periodic ' mpstat 1 ' output where one CPU is spending100% of its time in kernel code. Perhaps following Brendan Gregg's Solaris USE method , you stumbleover lockstat and decide to give it a try. This is a fine thing,as it's a very nice tool and can give you lots of fascinating output.

I mentioned yesterday that I had notmade any sort of bug report about our NetworkManager race bug thatwe found on CentOS 7. The reason why is pretty simple: where can Ireport it that will do any good?

I can't report it to Red Hat as a bug against Red Hat Enterprise 7. RedHat does take public bug reports against RHEL the last time I looked,but I'm not running real RHEL, I'm running CentOS. Even if I could,reinstalling a machine with

When we set up CentOS 7 on our new iSCSI backends we (and by that I mean 'I') leftthem using NetworkManager because it worked and I generally believein leaving systems in their standard state when possible. Thingshave changed since then and we're now in the process of droppingNetworkManager.

The direct reason we're doing this is that we discovered that ouriSCSI backends will not boot reliably with NetworkManager; some ofthe time the machines would have one of their iSCSI networks beunconfigured after the

Every so often, developers come up with really clever ways tofrustrate system administrators and other people who want to golook at their code to diagnose problems. The one that I ran intotoday looks like this:

if (rval != IDM_STATUS_SUCCESS) {	cmn_err(CE_NOTE, "iscsi connection(%u) unable to "	    "connect to target %s", icp->conn_oid,	    icp->conn_sess->sess_name);	idm

I recently mentioned some stats about how many clients do TLSwith my sinkhole SMTP server . Today I was planningto present some broader stats from that server, showing how manyclients made it to various points in the SMTP conversation with it.Then, unfortunately, I discovered that I'd shot myself in the footas far as gathering this sort of stats was concerned.

(If I was running a pure 'accept everything' SMTP server theseshould be pretty boring stats. But as it happens I'm not

A while back I tweeted :

Programming in #golang remains fun. I'm not sure if this is true forme for Python any more, but maybe I need the right project.

One of the problems for me with Python programming is that I kind ofhave a millstone and this millstone intersects badly with Python 3, which I kind of want to be using .

I have a number of Python projects, both work and personal. Thestuff for work is not moving to Python 3, in significant part because