procrastination diagram

Actually, the T510 arrived ages ago, but here's a summary (and a size comparison):

I installed Debian squeeze (with 2.6.32). Sound just worked. Wireless (iwlagn) mostly works (I have some trouble with MIT's (multi-AP) deployment, but there is some chance of pilot error there). X just worked with the free (nv) drivers (but see below). Suspend... mostly didn't work, crashing the ACPI driver on the way down such that it would lose the ACPI interrupt when it came back. "Oh well, I'll bet 2.6.33 will fix it." (Strictly speaking it would resume successfully to text mode, but spew kernel backtraces, and generally seem sad.)

Suspend-to-disk worked (sort of unsurprisingly), but hung on a return to X. (Even if you suspended and returned to the text console, the machine would hang when you switched to the X VT.) Some googling around suggested that the non-free (nvidia) drivers didn't have this problem, and lo, the suggestions were correct. (And no, before you ask, the system shows no sign of exposing any Intel graphics hardware.)

With a SSD, suspend-to-disk is tolerably slow, so I kind of got a working laptop out of it with almost too many pixels (1920x1080, beautiful color, good contrast), although apparently the T60p had more. I'll bet this screen size is cheaper for some strange mass-production reason, though. :-)

An excellent article on procrastination.

I would have some verbiage about Most Secret War by R.V. Jones here, and some oddly not entirely unrelated talk about in-progress adventures in ham radio here, but I put that off to add pubsubhubbub support to my blogging software.

(Although I have to say that I am thankful for transistors)

We all set our clocks forward (or, more likely, had our clocks "mysteriously" set themselves forward) today, and eastern Massachusetts is back in the the timezone that it probably should be year-round, and I find myself wondering whether the Iron Blogger script is going to get the right local time. "Hopefully, I won't be testing this." Anyway...

I alluded to some in-progress ham-radio stuff. Most of you know what the Green building is (and if you don't, well, follow the link to the Wikipedia) and that it is not, in most relevant ways, green. You probably know (now, at least, that is it has a large golfballish structure on the top):

That structure is a radome, housing an 18 foot dish that was used for an experimental weather radar between when the building was built in the sixties until the early nineties. The dish uses a pedestal az-el mount adapted from a SCR-584 radar, which was developed at the Rad Lab at MIT during World War II. (Yes, I considered making those Wikipedia links as well. No, I don't feel too good about it.) Anyway:

We changed the oil in the mount Friday night. One of the oil reservoirs looked remarkably clean-but-old. The other... looked kind of greenish, which is odd because the MP-61 pedestal doesn't have a coolant system. Regardless, it now squeaks less, but unfortunately it still squeaks. Apparently the bearings were designed to be greased at the factory and not subsequently serviced... I don't think they were thinking that they'd last for sixty years. More to come.

About a year ago, after having been exposed to Extreme Programming at my new job, and observing how it spilled over into system administration practices, I scrawled out an outline for a manifesto in a paper notebook. I remember googling for "Extreme System Administration" and being disappointed by the number of relevant hits I got, but it seems I should have been searching for "Agile System Administration".

It turns out that this is sort of thing is happening more from the developer direction, and seems to have turned into a movement called DevOps (thanks, Adam), although the grumpy sysadmin in me grimly suspects that some of these developer types (which I'm being paid to be at the moment, I should mention) are going to find the hard-real-time aspects of the job a bit of a surprise. Also, from the perspective of someone who prefers the phrase "Systems Programmer" on his business cards, it has seemed to me that a good sysadmin was already sort of between the pure-development and pure-operations cultures.

So anyway, in the spirit of "The useful things we were doing, let's do more of that"...

Obviously, from XP/Agile:

• pairing/review

  A second pair of eyes should be nigh-mandatory

• planning game/customer communication

  perhaps kanban?

• daily standup meetings
• refactor mercilessly/you aren't gonna need it/DON'T REPEAT YOURSELF
• everything possible in version control

  (really, the key thing is that everything needs to be reversible)

• testing/continuous integration

  (perhaps cruise control for your installer in a VM)

• test, test, test

  If you're not testing it, you don't know it works

But also:

• AUTOMATE

  If you do something twice, automate it the second time.

• MONITOR

  If you're not monitoring it, it's down

• TICKET

  If you're not keeping track of it, you'll forget it

• INVENTORY

  If you don't know where it is, you don't have it

Emergencies, once dealt with, are an opportunity to ask

• How could we have noticed this faster?
• How can we make this impossible or correct it automatically?
• How do we test for this?

User communications/Ticketing:

• Support vs. Trouble

  These are distinct processes and need to be handled differently.

• Support is a customer relationship thing:

  You need to figure out what the question is and answer it

• Trouble means something needs doing
• Tickets have potential many/many relationships
  • Many people may have the same problem, and the same problem may be several different problems
  • Potentially exposing to users that other users are having similar tickles the tension between privacy and transparency, on one hand, users will be embarrassed, on the other hand, encouraging them to help each other is always good.
• Every support ticket should end with "This was answer [link]" or "This is now answer [link]"
• Users should be walked past the current problem board on the way to complaining; possibly given a "I am also having this problem" checkbox

What Problem Do You Think You're Solving?

• This is something that needs to be have a clear answer for every task

Values

• Repeatability
• Transparency
• Privacy
• Communication
• Accountability
• no ad-hoc techniques
• Rational Security (realistic threat models)
• The Plural of Anecdote Is Not Data

Transparency vs. Communication

• Transparency

  What your users find when they go looking

• Communication

  How you tell users things or how you find things out from users

This is obviously very rough, and is an only slightly cleaned up version of my notes. I don't actually claim that this is new, or interesting, but it's something that is more useful outside my head than inside.

Also, I really need to get these posts done before midnight...

And another thing: Record; take notes.

I've often thought that the biologist's lab notebook is something that computer types should pick up. When you're trying to fix something, writing down what you tried, what hypotheses you've eliminated, can be invaluable later when you run into the same (or similar) simple problem again, and can be absolutely indispensable for avoiding tail-chasing when you're dealing with a complex problem. If you've ever tried to fix something under pressure and find yourself wondering "Have I tried this already?", you need to be taking more notes.

I went to PAX, since they bothered to hold it so near by. My feet hurt. It was nice hanging out with friends who came to town to go to the show, and the spectacle was certainly impressive, but gosh that was a lot of people for an introvert to deal with. And I found myself not as interested in gaming as I could be, or as... much as everyone else around me seemed to be. There were some neat costumes around, but I didn't have my (good) camera on me. (And I suppose treating it as a photo-expedition might have given me enough psychological distance from the crowd that I might have felt able to do more than barely leave the house today.)

Oh well... maybe next year?