Wandering Thoughts archives

An irritating X Windows limitation with wheel mice

I use what I call 'lazy focus follows mouse' in my window manager (fvwm2 calls it SloppyFocus): the last window that the mouse touched has focus, but the mouse doesn't have to actually stay inside the window. I like this because it means that I don't have to have the mouse cursor obscuring some of the window contents.

(I am not a fan of click to focus, but that's another entry.)

Unfortunately, this exposes an X limitation in how it handles wheel mice. The problem is in two parts; first, turning the wheel produces mouse button events, and second, X sends mouse button events to the focused window only if the mouse cursor is actually over it. Thus I can't touch a window, move my cursor away, and still use the mouse wheel.

(I believe you would see the same issue with click to focus, although I'm not sure.)

How it should work is that mouse wheel events should be like keyboard events, and thus get delivered to the focused window regardless of where the mouse is. I tend to believe that this is actually how people see the mouse wheel; it's less like clicking a mouse button and more like hitting a key on the keyboard.

This issue is one significant reason that I don't like wheel mice. (Another is that the wheel generally steals the middle mouse button position, so that actually clicking the middle mouse button requires more force and is more error-prone; I use my middle mouse button a lot more than I would use a wheel. I would probably like a three button wheel mouse that put the wheel under my thumb and left the middle mouse button alone, but I have no idea if they make such a thing.)

A classical Unix tape gotcha

Here's a classical Unix tape gotcha:

mt -f /dev/st0 fsf 5

If you're lucky when you make this mistake, you were fsf'ing the tape to read from it, and it is merely embarrassing and time-wasting.

The difference between normal and no-rewind tape devices is that one rewinds the tape when you use it and the other doesn't. More precisely, the tape is rewound when the tape device is closed for the last time (usually as the device is closed; the close() system call won't return until the tape has completed rewinding, which can lead to surprising lurching pauses in programs).

The gotcha is that many people expect the tape device only to be opened when you're reading or writing actual data to the tape. But on Unix, just getting the tape's status or sending it commands like fsf also means opening and closing the tape device, and thus having the rewind go off.

Life would be a lot simpler if the auto-rewind tape devices just didn't exist, or failing that at least were not the default devices and took an extra letter to use ('/dev/rst0' or something). But by now we are stuck with the situation in the name of tradition.

(So the safe thing to do is never actually use the auto-rewind names, even if you want to rewind the tape and they're a letter shorter. Suck it up, use the nst0 versions, and rewind the tape with an explicit command.)

Why I don't file bug reports very often

I just finished filing Fedora Core Bugzilla #217080. Between doing research to see if this was already a solved or known problem, gathering all the information, and actually writing everything down, it probably took me around three hours. (And I already have a Red Hat Bugzilla account and know how to use Bugzilla, or it would have taken longer.)

This isn't particularly atypical; writing even decent bug reports is simply a lot of work, much of it tedious and/or irritating. (And if you don't do the work to write a decent bug report, usually you might as well not bother, because no one is going to do anything much with it.)

The amount of raw work it takes to write a bug report is one of the reasons I have strong feelings that filing bug reports had better be as frictionless as possible. (Assuming that you want to get bug reports to start with.)

Why ssh validates host keys using the exact name you supplied

One of the little things that ssh does is that it checks and maintains host keys using exactly and only the name you used on the command line; it doesn't canonicalize the name. (Well, not much; these days it will also try the IP address that the name resolves to.)

The problem around here is that the names of machines can be specified in all sorts of different ways, because of domain search paths; often we have bare name, bare name plus the subdomain, and then two versions of the fully qualified hostname (because we have two top-level domain names, which is its own headache). This causes heartburn if you insist on strict host key checking, or in general if a host key has to change; users may be tripping over alternate names with old keys for some time to come.

(And then there's trying to write $HOME/.ssh/config stanzas that apply to a particular host, no matter how you're typing its name today.)

When I started stubbing my toe on this today I was all ready to curse ssh for not canonicalizing the hostname before it did host key matching and stuff; using only canonicalized names would make a bunch of things simpler. Then I thought about it some more and realized that it would also make ssh less secure.

The problem is that there is no way to tell if the canonicalization that you're doing is the canonicalization that the user expects to happen; if ssh was to canonicalize silently, it would be open to attacks (or just accidents) that change the canonicalization behind the user's back. Not canonicalizing hostnames when storing and checking host keys means that ssh can assure people that if they do 'ssh foobar', either they are getting the exact same foobar that they did last time, or they are going to hear about it. Loudly.

This is the past of least surprise, although a certain amount of annoyance.

(Yes, canonicalizations can change accidentally, or at least without malice. Sometimes the results can be somewhat exciting.)

A small script: bsearch-nums

Sometimes I write little scripts partly in order to play around with a command I haven't used before. Such is the case with today's script, which I have unimaginatively called bsearch-nums. Here it is:

#!/bin/sh
# usage: bsearch-nums START END

lo=$1; hi=$2
while [ $lo -lt $hi ]; do
  mid=`echo $lo $hi +2/p | dc`
  echo "try: $mid"
  echo -n "u/d? "
  read a || exit 0
  case "$a" in
    [uU+]*) lo=`echo $mid 1+p | dc`;;
    [dD-]*) hi=$mid;;
  esac
done
echo
echo "result: $lo"

Every so often, I find myself running down something where the best way to find the answer is a binary search; today's example was finding out which revision of our aliases file introduced a particular alias. But what usually happens is that only the first few steps are a true binary search and then I resort to jumping around to numbers that look vaguely right, because keeping track of the low and high points and cranking the math gets too annoying.

Enter bsearch-nums, which walks you through the numbers for a manual binary search. You get to supply the actual testing (and then tell the program whether the search should go up or down at each step).

As you might guess, the command I was finally trying out was dc, which is one of those hoary old Unix utilities that barely gets any love and attention these days. (Please don't bother to tell me that a modern shell could do all the math with builtins. I'm too old fashioned, and besides, Solaris 8's /bin/sh isn't a modern shell. Although it doesn't do 'echo -n' either, so I guess this script shows where I actually wrote it.)

The good old days of Unix

Ah, the good old days, when Unix was Unix:

awk: record `<A href="http://842d...' has too many fields
 record number 20

In some quarters, it's popular to rag on the GNU tools and by extension on things that make heavy use of them (like, say, Linux distributions); they're bloated, have grown too many features and command line options, they use too much memory, the documentation is in inconvenient formats, and so on.

There's a certain amount of justice in those complaints. But one should not view the past through overly rose-coloured glasses; there are good reasons why people adopted the GNU tools, and in many cases it wasn't because they didn't have other options.

How to quiesce NFS traffic the brute force way

Once upon a time, we had an NFS server. Like sensible people, we immediately put the NFS server on a UPS, which meant that if we lost power, we wanted to quiesce the NFS traffic before we had to shut it down.

There are probably a lot of sophisticated solutions to this problem, involving things like hooking into the UPS monitoring system and triggering events on power loss. We opted for a much simpler method: we didn't put the Ethernet switch that the server was connected to on a UPS.

No power, no switch, no network traffic reaching the server, and it gets to settle down in peace before it has to shut down.

(You might wonder how anyone else could be talking to the server if we'd lost power. The answer is 'different power circuits'; we had machines in other locations, and there was no guarantee that our connection to the campus backbone would be cut if we lost power in our machine room but kept our core switch up.)

In hindsight we should have used two switches, one for the core servers and one for the outside links. That would have let the fileserver talk to the mail server to at least queue up plaintive power loss notices when we actually lost power. (Fortunately, the UPS monitoring software sent those out with a separate process, so the unavailability of email didn't stop it from doing orderly shutdowns as the UPS batteries ran down.)

Looked at from the right angle, we were using our core switch as a fuse. I suspect that there are other applications for this sort of trick if you look for them.