Ludoo

Every time I boot my laptop in Windows (which happens once per week or less), I am greeted by the familiar Windows Update popup. Every time, I feel lucky to have switched full time to Linux.

What kept my desktop environment tied to Windows for a long time were mainly Word (now I use a combination of ReST and LaTeX), Internet Explorer+OE (Firebird+Thunderbird), a decent editor (J), and good fonts quality (TTF Web Fonts+freetype with the TTF bytecode enabled).

There still are a few things that Windows does better, mainly desktop and apps integration, managing files graphically, scanner support and scan quality. And there still are a few things where Linux needs improvement, but it is definitely getting there. I can't wait to install Sun's Mad Hatter beta on my office desktop next week.

BTW, if you're curious about the MSVDM toolbar you can see in the picture, it's the free Virtual Desktop Manager from the Microsoft PowerToys for Windows XP.

Last night Italy suffered a massive blackout, so this morning I came back from the lake Maggiore to find my server dead. The server, which runs all our mail and web sites, was (yes, was) a very old Compaq Deskpro with a Celeron 300 and twin 4Gb disks configured as a software RAID-1 array. I liked it because it was a very silent and low- consumption machine with no CPU fan, and I don't need more power than that to manage a few mailboxes, a couple of web sites, and my home LAN.

I knew it was in bad shape, but I always managed to reboot it in the past, the very few times I needed to- Today I tried everything, but the bios screen refuses to come up, and no beeps escape from the speaker at boot time.

So I wasted all day trying to let my desktop's twin machine (an Athlon 750 PC I built three years ago) see my server's two disks, and remount the RAID array. The new machine's BIOS screws up the disks geometry, and if I attach both of them on the two IDE channels, I see only the first one. Weird.

So I burned a mini-CD with tomsrtbt, transferred everything on a 20Gb disk, rebuilt the array, hotraidadded one of the two 4Gb disks, reconfigured LILO, rebooted, and LILO started spitting out error messages. Reconfigured, double checked everything, LILO comes up with a checksum error. Hmmm I'm getting old for this, I remember when it was fun but it's not anymore.

In the end I installed Grub, took the 4Gb disk off the array, fscked to death the 20Gb disk who got corrupted in the meantime, and the server is back up. Tomorrow I will buy a second 20Gb or 40Gb disk and add it to the RAID array.

The only good thing to come out of this is that I learned something more about Grub, and I really like it. If things get tough, Grub is your friend. A few useful links if you want to switch from LILO to Grub, boot a software RAID partition from Grub, convert a running system to software RAID (mainly geared towards Debian users, Slackware users may find this more useful).

My fiber optic link where this site is usually served from is still down, something to do with the Catalyst in the basement who serves the whole building, I have called a few times but all I'm getting is it will be fixed RSN. If I knew how to lockpick the rack, and I had not spent the whole day fighting disks and LILO, I would be tempted to connect my laptop and try to bring it up myself (but maybe it's not so easy anymore to reboot a Cisco and get enable permissions). Luckily I have still my ADSL link, who promptly resumed service as soon as power came back. I have switched the DNS to the ADSL address, so this site will slowly resurface on the Web, but it will be pretty slow until the fiber optic link is working again.

I admit it, I'm an architect. Not only as in IT Architect or whatever my job title of the moment is, but as in builder of houses. I graduated in 1995, and though I was totally in love with architecture, for a series of coincidences and some luck I soon found myself working in IT, which had been till then little more than a hobby.

I never got back to architecture, and soon I more or less stopped studying and researching it, but in the deep recesses of my mind things continued to work, though at a different pace. So lately I'm thinking about a research project on a period of architecture I've always found very intriguing, and usually overlooked by historians of architecture. The project will involve heavy researching in the field, which happens to be the city where I live. So it will hopefully soon be time to pick up a camera and start wandering the streets in my free time.

Photography has been the third of my passions (read: obsessions) in the past with IT and architecture, so while I wait for my ever procrastinating self to start working on this new project, I'm digging out my old pictures to scan them and put them online as a sort of mental training.

Since they will use up bandwidth, and very few people will be interested in them, my pictures category will stay confined to a row in the right menu, without making it to my blog pages. If you're interested, point your browser from time to time to my pictures area.

Sometimes being reminded of one's ignorance is not only instructive, but funny too. In a recent message on the armedbear-j-devel mailing list in reply to a non-bug I recently submitted, Peter Graves (the J developer) used an acronym I never saw before, DWIM (Paste would retain its current DWIMish behavior...).

After replying to the message, I made a quick search on DWIMI expecting to find a reference to some arcane editor of days past, but what I found was something completely different, rooted in the world of LISP gurus

/dwim/ [acronym, "Do What I Mean" (not what I say)]

1. Able to guess, sometimes even correctly, the result intended when bogus input was provided.
2. The BBNLISP/INTERLISP function that attempted to accomplish this feat by correcting many of the more common errors. See hairy.
3. Occasionally, an interjection hurled at a balky computer, especially when one senses one might be tripping over legalisms (see legalese).

Foldoc goes on to relate a notorious incident involving DWIM, which is worth reading

Warren Teitelman originally wrote DWIM to fix his typos and spelling errors, so it was somewhat idiosyncratic to his style, and would often make hash of anyone else's typos if they were stylistically different. Some victims of DWIM thus claimed that the acronym stood for "Damn Warren's Infernal Machine!'.

In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed "delete *$" to free up some disk space. (The editor there named backup files by appending "$" to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported "*$ not found, assuming you meant 'delete *'". It then started to delete all the files on the disk! The hacker managed to stop it with a Vulcan nerve pinch after only a half dozen or so files were lost.

The disgruntled victim later said he had been sorely tempted to go to Warren's office, tie Warren down in his chair in front of his workstation, and then type "delete *$" twice.

Sometimes it pays to be ignorant.....

A few days ago I finally got fed up with spam, so I decided to install a spam filter on my server. After reading around a bit, I settled on Spambayes, which (apart from being written in Python) looks a very solid and well maintained project.

I don't use Outlook (I run Linux both on my server and on my desktops), so using Spambayes Outlook plugin was not an option. Since I'm using Maildir as the storage format for both SMTP and IMAP, I initially tried the Spambayes IMAP filter. Unfortunately, the filter is still in its early stage of development, and the IMAP protocol varies significantly among different server implementations. The main problems I had with the IMAP filter were its marking all new messages as read after processing (this is apparently due to my IMAP server lack of support for an obscure IMAP command), and its frequent crashes.

So after a few hours of monitoring the IMAP filter's activity, I decided to change my approach. Reading around a bit, I discovered that the venerable procmail (which I used a lot until five or six years ago) now natively supports Maildirs.

A .qmail forward file, a .procmailrc recipe and a cron job later, I had a flawless Spambayes setup. In the past 3 days, Spambayes has worked admirably with minimal training, intercepting 99% of all spam and generating zero false positives. Definitely recommended.

My .qmail file simply passes everything along to procmail for delivery:

| preline /usr/bin/procmail

My .procmailrc recipe looks like this:

PATH=$HOME/bin:/usr/bin:/bin:/usr/local/bin:.
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
LOGFILE=$HOME/procmail.log
LOCKFILE=$HOME/.lockmail
:0 fw
| /usr/bin/sb_filter.py
:0
* ^X-SpamBayes-Classification: spam
.INBOX.spambayes.spam/
:0
* ^X-SpamBayes-Classification: unsure
.INBOX.spambayes.unsure/

Notice how the trailing slash in the DEFAULT delivery identifies a Maildir storage. The rest is pretty self-explanatory, apart maybe from the folder namespace, which is the one used by default by my IMAP server:

• the first directive instructs procmail to feed the message to sb_filter.py
• sb_filter processes the message and adds the X-SpamBayes-Classification header with two values, the first one marking the message as either spam/ham/unsure, the second one displaying the exact numeric spam rating (from 0 to 1)
• the second and third directives match the header on its first value for spam and unsure, and deliver the message to the appropriate Maildir
• if a message is not matched by the second or third directive, it "falls off" the chain and gets delivered to DEFAULT, which in this case is my inbox

To train the filter, I run a cron job every half hour that looks into two Maildir folders for spam and ham messages (the following lines are ofc a single crontab line):

0,30 * * * * /usr/bin/sb_mboxtrain.py -d /home/ludo/.spambayes_hammie.db 
-g /home/ludo/Maildir/.INBOX.spambayes.train_ham/ 
-s /home/ludo/Maildir/.INBOX.spambayes.train_spam/ 
-n >/dev/null 2>&1

Meaning, every half hour cron runs sb_mboxtrain, instructing it to use the .spambayes_hammie.db (previously created with sb_filter.py -n), and to fetch ham messages from the .INBOX.spambayes.train_ham Maildir, and spam messages from the .INBOX.spambayes.train_spam Maildir.

The Maildir directories where spam/unsure messages get delivered, and where you deposit messages to train SpamBayes, can be created either from your mail client or with the command-line utility maildirmake, provided with qmail and courier.

The last piece of information you need before running this setup, is a .spambayesrc file in your home directory. Mine contains the following lines:

[Storage]
persistent_use_database = True
persistent_storage_file = ~/.spambayes_hammie.db

That's all, efficient and reliable spam protection in 5 minutes or so.

I have always been an avid listener of Internet radios since my favourite music is very specialized (early or "soul" reggae, dub, and some jazz+r&b), and very unlikely to be broadcasted over the air, especially in Italy where I live.

Last night I had a further example of the power of Internet radios. Perugia, which is one of the Italian soccer teams I try to follow, was playing an away match vs Dundee FC. I was at my home office, which has no tv, so I looked up the Dundee FC site on Google, followed the link and connected to their local radio station live broadcast of the match (which I only half-managed to follow due to my unfamiliarty with the Scottish accent).

What struck me is that the above procedure involved almost no conscious thinking on my part. My interest about the match match was followed a few seconds later by a live commentary streaming out of my speakers.

So, coincidences being the stuff life is mostly made of, this morning I was not surprised to find in my aggregator a new entry on Tim Bray's blog on Radio, pointing to Doc Searls' The Continuing Death of Radio as Usual.

Doc Searls makes a few interesting points, lamenting the low quality of radio receivers (AM in cars, FM at home), the slow death of over-the-air broadcasting, and IP broadcasting as the future of the Radio.

Not that it matters to anyone, but I agree with everything he writes, except his statement that There's almost no way to get a good AM radio anymore, even if you want one.

If you don't need to integrate a radio receiver with fancy stuff like a home theatre, or distribute its audio signal throughout a house, there are plenty of excellent radios out there. They are also pretty cheap, have better audio quality than most expensive stereo equipment available on the market, are superbly good looking, and will keep their value well. The picture above should give you a clear idea of what I'm saying.

It shows a Grundig 60s console stereo set, including AM and FM radio, an equalizer, a superb antenna, four speakers, and a turntable. All integrated into a handmade wood piece of furniture. We bought a similar one from the late 50s a few months ago for less than 300 euro, and its tuning and sound qualities are excellent. Of course, sound quality is no surprise since radios from this period use tube amplifiers.

Alan Kennedy has just announced a list of Python-based HTTP proxies, a few of them may come handy when developing web applications.

And if you're wondering what I'm doing sitting in front of my computer at this hour, well this is one of those nights where I just can't get asleep.