The Fifth Wheel of andrewg

I’m trying to reinstall a ThinkPad X41 tablet at the moment, after a bad hard disk crash. Unfortunately, we forgot to make a backup image of this machine’s clean install (like we usually do), so I’m installing Windows by hand. And there’s no network card driver.

It constantly frustrates me that network cards can’t Just Work the same way that keyboards and screens do. No matter what fancy new feature nVidia or ATI put into their latest graphics card, you can be 100% sure it talks to the VGA-compatible driver on your 5-year-old install disk so you can at least see what you’re doing. Why don’t network cards have a basic compatibility mode like this? The marginal costs would surely be cents at the most, and all we need it for is to download the proper driver from Windows Update (and all the other drivers while we’re at it), but it would save a hell of a lot of frustration. How many man-hours are wasted downloading network card drivers by hand?

And something similar would be useful for SATA host controllers too – Acronis 9.1d doesn’t recognise the disk in our new T61s, which has just killed our new laptop rollout plan. Never had that problem with IDE…

Come on, lads.

After spending a frustrating afternoon migrating users to a new email server, I am more convinced than ever that we need an integrated, open-standard mail client protocol. Let us call it imap5.

imap5 would address the following problems with current client/server mail protocols:

1. The need to configure separate incoming and outgoing connections.

2. The use of the same port for both client and backhaul communication, which prompts heavy firewalling of port 25 on corporate networks, often making it impossible to send mail at all.

3. The need to store long lists of configuration options (server, port, authentication, encryption, all twice) on the client.

Solutions to these problems already exist, but are not widely supported.

1 and 2. Sending email via imap is possible on courier-imapd and mutt through the use of smart outboxes -  draft emails uploaded to a given imap folder are automatically forwarded to an MTA process by the imap server. SMTP therefore need not be supported on the client.

3. IMSP allowed config options (amongst other things) to be stored in a directory service, but this was obsoleted by ACAP, which then died a death.

imap5 would include functionality derived from the above. In addition, imap5 should:

1. Encapsulate all communication in HTTPS.

2. Only require the user to input his email address, password and a URL (preferably the URL of his webmail service) into his client. Further settings would be read from HTML metadata.

3. Allow server options to be set, including password, display name, autoreply, forward, and arbitrary settings (e.g. filtering) to be defined in a companion protocol.

However (unlike RPC over HTTPS) imap5 would not try to support address books, calendaring or other groupware features – open protocols for these (LDAP, iCal) already exist.

The advantages of imap5 over RPC/HTTPS would be threefold:

1. Three-field client configuration form.

2. Scope limited to email service provision.

3. Open, incremental improvements to well-understood protocols.

*sigh*

gld has packed in for the last time on me. Since I now use the university system to read my work email, I failed to notice that my personal mail had quietly stopped working.

Well, quietly from my side. From the public side, it was returning internal configuration errors left right and centre.

It was only when my brother noticed he had missed some emails that I looked and found that gld had fallen over again. You would think that postfix would handle this sort of failure gracefully – more spam being preferable to no email at all – but no.

So now I am going to try policyd instead, to see if it is any more stable.

Fon are giving away 10,000 of the little wireless routers that I recently acquired. Go for it, guys!

FON’s first anniversary