Bad Software

There are horrendous amounts of bad software around. The motivation to write this page stems from witnessing a posting to news.groups with the following header lines:

Path: cs.tu-berlin.de!fu-berlin.de!zib-berlin.de!Germany.EU.net!EU.net!Belgium.EU.net!idefix.CS.kuleuven.ac.be!chaos.kulnet.kuleuven.ac.be!usenet
From: Not configured (change c:/user/winvn/winvn.ini) (Not configured (change c:/user/winvn/winvn.ini))
X-Newsreader: WinVN 0.92.6+

Well, what can one expect from a software with version number "0.92.6+"? Sigh. Software that makes its user look like a fool is IMHO a serious problem. Of course, Ron Newman saw the posting and commented

That's got to be the illegalest From: line I've seen all year.

(in case you don't know it, see Ron's good netkeeping seal of approval proposal.)

(27.04.95) The problem seems to be endemic with this piece of software. Today I saw a posting to a german newsgroup with the following header:

Path: cs.tu-berlin.de!fu-berlin.de!news.dfn.de!xlink.net!sbusol.rz.uni-sb.de!sbusol.rz.uni-sb.de!usenet
From: Mailadresse (Vorname Nachname)
Organization: Institut
X-Newsreader: WinVN 0.91.4

So the horrible "defaults" are even internationalized!

Then there are these UNIX tools. You know, tools for real power users. The other day, I wanted to test a statistics script on our WWW log and thought the most recent, oh, 10000 entries, should do (the whole log is 35M).

tail -10000 logfile > last10k

should do it, right? Wrong. Witness these interactions:

mfx@lenin [181]% tail -100 /home/www/log/access_log | wc
     100    1000    8867
mfx@lenin [182]% tail -1000 /home/www/log/access_log | wc
     371    3707   32768
mfx@lenin [183]% tail -10000 /home/www/log/access_log | wc
     371    3707   32768

While it is nice to see that "tail" is efficiently coded and needs only 32k of memory for its internal buffer, that is small consolation for me. The whole idea of combining small tools to create bigger ones goes down the drain when each tool has its own undocumented restrictions creeping in and silently modifying the results.

Oh yeah, documentation: the man page for tail(1) mentions

BUGS
     Data for a tail relative to the end of the file is stored in
     a buffer, and thus is limited in size.

Nice to know that there is a limit. How large is it? Enough to keep, say, 40 lines? Or 100? We don't know. As it is, this tool is theoretically unusable if all you have is its documentation, and practically unusuable if you want to use it in a context where you can't guarantee that you'll need <32k space.

Hey, adding one lousy switch -B<buffersize in K> would have removed the whole problem, without even a change in the basic mechanism of the program! But no, hard-coding the limit is the way to go. (Of course, using backwards-fseek, when possible, would have been even better, removing the need for a buffer in at last some cases.)

Built-in fixed sizes are a known problem of many programs: witness lex, yacc, and TeX. At least they give errors, and you can parameterize lex and re-compile TeX. But you often don't have the sources for yacc, so that a re-engineering of the grammar is the only way to go.

I had this note on the top index of the trash heap for a week:

If you have problems accessing links on this page, you may have a browser that doesn't know about "base" tags. The correct address of this page is "http://mfx.dasburo.com/t/index.html"; if your browser displays it as "http://mfx.dasburo.com/trash.html", it is broken. (I stumbled across this when i saw that 7 people had tried to access a non-existent "~mfx/etc.html" page (instead of the very existent "~mfx/t/etc.html"). A systematic search of the last month's log revealed 238 accesses to my pages that ended in a '404 Not Found' responses, nearly all of them to /w/ or /t/ pages, with the redirection missing. What crappy web browser is responsible for this? (Of course, there may exist a monstrous mis-link somewhere in my pages. In this case, please tell me! Why are web 'surfers' so silent? On 238 occasions, someone out there thought "shit! what's wrong with this link?", and none mailed me a note about it!)

On 01.04.95, I made all links on this page absolute, to remove the probable cause of the problem. Since no-one who encountered the problem since i wrote the preceding note (accesses from a dozen sites) sent me a bug report, I still don't know under what conditions it occured! Sigh.

(13.04.95) I found the first culprit: Sun's ultra-modern, just now pre-released HotJava (formerly known as WebRunner) ignores <base> tags. No reaction to my bug report yet.

This page is part of the Rant Space.