Question, questions, always with the questions

A couple of classic examples of a bad user questions from ESR's guide to asking smart questions:

Q: My {program, configuration, SQL statement} doesn't work

A: This is not a question, and I'm not interested in playing Twenty Questions to pry your actual question out of you - I have better things to do. On seeing something like this, my reaction is normally of one of the following:

• do you have anything else to add to that?
• oh, that's too bad, I hope you get it fixed.
• and this has exactly what to do with me?

I've looked at a couple of these this morning and in every case, if the user had spent 30 seconds thinking or RTFMing before raising a ticket or getting on the phone, they'd have solved their own problem. If you write a FAQ, but nobody reads it, is it still a FAQ?

I also like this one, which we seem to get a lot round here:

Q: My program doesn't work. I think system facility X is broken.

A: While it is possible that you are the first person to notice an obvious deficiency in system calls and libraries heavily used by hundreds or thousands of people, it is rather more likely that you are utterly clueless. Extraordinary claims require extraordinary evidence; when you make a claim like this one, you must back it up with clear and exhaustive documentation of the failure case.

I've always had the opposite experience: weird, extraordinary problems almost always turn out to be an operating system or hardware fault, no matter how dumb they may sound when the users report them. Like the occasion when a machine booted up with half the banks configured out (but the same amount of total memory) and we started getting funky fresh memory errors or the time when a code failed to barrier becuase one of the CPUs was missing or the time when extra code was added to checkpoint/restart and suddenly jobs started producing garbled output, stuff like that.

On Linux upgrades

I've been working with one of my colleagues on a plan to upgrade the production version of Linux on one of the tin gods. Being supremely laid back about the whole thing, I produced a plan with three steps:

1. Install new kernel
2. Shutdown
3. Reboot

Needless to say, my colleague and the High Commander wanted more detail, so we came up with a plan with ℵ0 steps and scheduled some downtime for next week. Unfortunately, it looks like there's way too much work to do in next to no time, so it looks like we're going to have to ditch a load of stuff. While attempt to cheer up my despairing cow orker, I remembered Karl von Clausewitz' famous quote:

No Battle Plan Survives First Contact With the Enemy.

I bet if he were alive today, Clausewitz would be a sysadmin.