Ah, the relief: `Stay Calm April' is over. Of course, the whole exercise was a waste of time, since it is not possible to remain calm purely through an effort of will. I could act calm by refusing to discuss the things that made me angry, but doing so is pretty futile and in any case I didn't muster quite enough self-control to manage it. So I found myself saying things, pausing for a moment, and then saying ``I'm sorry, that didn't come out calm at all, did it?''
Anyway, in true content-free web log style, here's a list of some of the things which challenged the purpose and execution of `Stay Calm April':
-
The local elections
There are four parties putting up candidates in my ward. I only received election literature from one of them, and that was the party for whose candidates I already thought I would likely vote. So how am I supposed to make an informed choice when none of the other candidates were prepared to make the effort to inform me?
Now, admittedly, this ward hasn't changed party affiliation in more than ten years (see Colin Rosenstiel's data for this and other fun and fascinating electoral factlets), and I gather that in local elections opposition parties typically don't find it worthwhile to expend effort on safe seats. But a single leaflet from each candidate would have been nice. Perhaps next time round the candidates can put all their views on one circular and send it 'round by Royal Mail Door-to-Door -- assuming that the Royal Mail still exists by then.
-
The New Iraq(TM)
I see that the fucking Americans are still machine-gunning demonstrators in Falluja. Idiots.
While I appreciate that you can't make an empire without breaking heads, how in fuck's name can these people travel ten thousand miles to take over a country where they know they're not welcome and forget to bring any plastic bullets, so that when some hick grunt in an armoured car gets nervous, the only recourse open to him is to loose off live ammunition into a civilian crowd?
For god's sake. It makes the British Empire look organised.
And some dull, more geeky things:
-
Red Hat Linux
Again, from email.
I upgraded my RedHat machine a little while ago. (This was before Stay Calm April started, so I think it's just about allowable to describe the procedure.) RedHat doesn't have the Debian-style upgrade-everything-on-the-live-system feature, you're supposed to reboot with a RH CD, but that's stupid, so instead the right thing to do is to start a statically-linked shell and manually install the new RPMs. You wind up saying `rpm -Uvh {about a zillion packages}' but eventually it works and it even seemed like it hadn't broken much. Oh, apart from the quote marks, but that's The New UNICODE Reality, so it's to be expected.
And then, about a week later, somebody pointed out that my web page of newsgroup statistics wasn't being updated.
So then I realised that the new RH had squashed all my perl modules. No problem:
cd /software/src for i in */Makefile.PL ; do dir=`dirname $i` cd $dir && perl Makefile.PL && make && make test && make install && cd .. done
So I run the script and it works fine. But the little shell script which gets run from cron and iterates over groups doesn't, and I can't understand why. It's finishing without doing anything, or printing a diagnostic. So I put `set -x' at the top of the script, and it basically does
+ GROUPS=" ... list of news groups ... "
and exits silently. WTF?
The answer: in bash2, $GROUPS is a reserved variable which holds the groups (GIDs) of which you are a member. Trying to assign to it causes a shell script to fail silently. (Actually not quite true -- ``Assignments to GROUPS have no effect and return an error status'' -- but if you have `set -e' on that's basically the result.)
Now, it's not like I regression test my code, but this is used by zillions of people all over the world. Gah.
Now, in general, it's not worth documenting these little frustrations, except for the fact that one day somebody might encounter a similar problem, find this post, and save some time. But really this is just self-indulgent ranting....
(This is the non-rant bit coming up, by the way.)
... on which subject, the UNIX-Haters Handbook has now been released in PDF form. And there was much rejoicing, accompanied, obviously, by the demented ravings of a bunch of Suckdot weenies who obviously Don't Get It At All.
The Handbook is a very amusing book, probably the best extended operating-systems rant which will ever be written. Many of its examples are now out of date, but that doesn't affect its basic message. (It's a pity that the world-wide web has apparently been saved the treatment they give `snoozenet'.) Now, the interesting thing about this is that the book makes two basic points--
- UNIX is a pretty shoddy job.
- It's far inferior to what came before.
The first point can, largely, be ignored: UNIX has got better; mainly, we assume, because vendors have been shamed by the existence of Free software into fixing the idiotic bugs in their code, or, failing that, the users have replaced the broken programs with their GNU equivalents. In any case, it's not like competing systems have raised the bar on `software quality' much.
But the second point is much more interesting.
`What came before' was ITS, TOPS-20, the LISP Machine, and a variety of other weird-and-wonderful operating systems that are now long out of use. Now, Richard Gabriel's The Rise of ``Worse is Better'' is, supposedly, the explanation of why UNIX beat all those systems in the marketplace -- it was smaller and easier to port, basically -- but it doesn't explain why all those systems -- perhaps with the exception of all that LISP inside EMACS -- have decomposed into memories. I haven't even seen a coherent explanation of the ideas in, say, TOPS-20, that describes why it was so great. Have these ideas -- whatever they were -- actually been absorbed by current software, or have they really vanished?
To me, this is a strange business. I'd love to know the answer.
-
Oh, security, thy name is aggravation
(This one is parochial and technical.)
A little while ago, some machines -- none of mine -- here were apparently broken in to, presumably by some hyperactive eleven year old or fuckwit adolescent. Obviously this means that it's imperative to check other machines to determine whether they've been compromised.
Now, it turns out that since I last looked at this crap, `root kits' designed to compromise the security of Linux machines have become slightly more sophisticated. The one in use in this incident, suckit (ho-ho, aren't these people so amusing), is able to patch a running kernel to hide the files it installs, as well as its running processes and network connections. It works by replacing /sbin/init and modifying the kernel through /dev/kmem, then running the original init. The point here is that you can't trivially detect that init has changed, because all of the file-reading APIs get redirected to the original init.
The suggested means to determine whether a system has been compromised is to reboot with a clean kernel and then poke around the filesystem. Obviously this works but it's a pain to do and creates considerable inconvenience.
Now, there is an alternative. This is to look at the raw filesystem on disk, without going through the kernel. You can do this using dd(1), or, slightly more easily, with debugfs(8). Obviously it's possible to spoof this, too -- by modifying the kernel to lie about the contents of raw disk devices -- but this is more difficult than simply redirecting the file APIs.
So, I suggest this on a local news group, and ask if anyone with access to one of the compromised machines can check that this does in fact work.
Now, apparently, nobody in front of such a machine had the five seconds to spare to test this, which is fair enough. Naturally, this didn't stop others from repeating their mantra about how this is not sufficient, and the software can be spoofed, yadda yadda, tedious weenie crap, the whole thing; and all of this without contributing any actual information.
The point being, I know this stuff. I do not need a lecture about it. I wanted to know the answer to the simple question, ``Can I use this approach to avoid inconveniencing somewhere on the order of 200 people by pulling the plug on a bunch of machines to check for a security compromise which probably isn't there?'' in this case. Somehow this was interpreted as ``Please offload some patronising drivel about security onto me.''
This shouldn't have affected my state of calm, since I have repeatedly been exposed to the lesson that you shouldn't expect anything resembling a useful answer to any but the most trivial question on the local newsgroups, but nevertheless it did annoy me, since the tradeoff between how much effort it would take to give a helpful answer to the question and how much trouble it would save me and others to receive such an answer was so enormous.
Somebody did point me to the root kit code above, and, reading it, it's clear that -- in its distributed version -- it can be detected by the means I suggest. Obviously, the code could have been modified, but it looks like it wasn't in this case.
So, I can recommend that you do not try any `Stay Calm' months. They are a waste of time.
I was pondering doing `no technology made after 1950 month', which might work a bit better since so much of what seems to annoy me results from transistor-age technical innovations, but I don't think that's really feasible. That said, I did a quick count and the only bits of post-1950 technology I use are the computers and the mobile 'phone (which I'd rather do without). (I should note that in `pre-1950' I include things which could have been made before 1950, even if they weren't, like my bicycle or my FM radio; things which, though they didn't exist in 1950, are the direct equivalents of things which did, like supermarkets and bar-coded goods; and things which I can't really avoid using, like roads and public transport. In any case, this would be far too difficult to sensibly pull off.)