2006-07-19
A sysadmin habit: screen locking
Years and years ago, I bound a function key in my window manager to
start xlock and then carefully trained myself to hit F10 (the
aforementioned function key) the moment I got up from my chair to
leave my cubicle-office. It didn't matter how trivial the errand or how
short it would be; I'd hit F10 and locked the screen. By now I have
this habit so ingrained that it's become one of my little twitches.
We have an access-controlled office area and everyone in here is some sort of system administrator, so it's probably pretty harmless to not lock your display when you walk away from the computer. Probably.
The reason I bound starting xlock to a function key was to make it as
fast and easy to do as possible; the faster it is to lock my screen,
the more likely it is that I'll do it all the time. No exceptions, no
'I'll just be away for 30 seconds and it'd be too much of a pain to find
the menu entry'. I figured this was well worth stealing a function key
away from programs that might want to use it.
(This reminds me that I need to turn off the automatic display locking timeout on Fedora Core 5, because it interacts badly with a KVM; I'm a bit tired of finding the display on my test machine locked just because I switched to another machine on the KVM for a while.)
Using Python to test system behavior
One of the things I like about the Python interpreter is that it is just about right for doing little system behavior tests, like how various systems handled a TCP port binding issue. This is because Python is low level enough to be relatively close to the actual system, so you can be pretty sure that what you're seeing isn't Python-specific behavior, while at the same time being high level enough that you can do the tests in a couple of lines.
Strictly speaking you don't need an interpreter for this, just a language at the right level, but having an interpreter avoids the whole drag of editing and running and re-editing and re-running and so on.
(And theoretically you can write this stuff directly in C, but I'm
certainly not familiar enough with things like the C socket API that I
can toss off test programs for this in ten minutes or less. In Python
I can bind a socket in three statements, and one of them is 'import
socket'.)
So today when I wanted to see how bind() behaved on Solaris 9,
I fired up two interpreters in two windows, and in the first I
typed:
>>> import socket
>>> s = socket.socket(); s.bind(('', 4000))
and in the other I typed:
>>> import socket
>>> s = socket.socket(); s.bind(('127.0.0.1', 4000))
And the Solaris 9 machine promptly spewed a traceback complaining about
'socket.error: (125, 'Address already in use')', just as I expected.
(Yeah, I could have done it all in one Python interpreter; I didn't feel
like seeing if Solaris did something funny if the same process was doing
both bind()s. (It turns out it doesn't.))
Link: 'Document Centric'
Document Centric is about the disconnect between relational databases and regular users, and why people keep stuffing data into spreadsheets and the like instead of 'real' databases.
(They do. Joel Spolsky has written about the Excel team's surprise at finding this out about how real users used Excel.)
(From Carlos de la Guardia.)