I spent most of my free time in the last four days setting up a new mail server for myself.  The old one, you see, decided that it’d had enough.  I can’t be too upset, considering it’d been running on an old IBM ThinkPad for about three years straight.

In recent years, I’ve become quite fond of the UNIX way of doing thingsâ„¢.  This time, I thought, I was gonna use all open source code to run smtp, pop, imap and webmail.  Since I’m quite familiar w/ mail servers, I thought this’d be fairly easy/straight forward.

Not so.

After I had a go at it for a while, I came to realize that it just wasn’t going to be worth my time to learn all of the intricacies of running a unix-based mail server, so I resorted to falling back to what I had before.

The brief stint w/ researching this unix server reminded me of an article that I read on KernelThread.com, which seems to be down, atm.  Here’s the article, provided courtesy of Google’s cache.  It’s a bit long, but the point is that it’s easy to get caught up in trying to do something geeky just because you think there’s merit in doing it.  Sometimes, the quickest way is actually better.

This is a phenomenon I have experienced, and I believe this applies to many others as well. Consider the typical Linux experience of a Linux aficionado, although this is not Linux specific. I can speak for myself. Everything on Linux, including the “problemsâ€?, was a pleasure. Particularly the problems. I used to enjoy the installation. I would go through each package, reading its description and dependencies, selecting or de-selecting it, etc. I would carefully partition my disk, arranging things such that a minimal amount of space was “read-writeâ€?. Although distributions have become much better in supporting various hardware out-of-the-box, there are always things that do not work without proactive effort on your part, which is fun and feels like an accomplishment. I maintained bleeding edge versions of various packages under /usr/local. A few years ago, if somebody complained about lack of software on Linux, my own response would have been: “If you need something, look if it’s already in your distribution; otherwise look for it on the Net; if it doesn’t exist, then write it yourself …â€? Well, Richard Stallman did it, but I don’t think that can be a general prescription.

The “trapâ€? is to get sucked into this cycle of tweaking, configuration, tinkering, hacking, figuring out how to make things work, which files go with which daemon or application, … and be happy about it. While such pursuits are noble and academic in their own right, the sense of accomplishment you get from doing this could be misleading – even false! There is a very thin line between doing something worthwhile (whether it be for yourself or others), or just believe that you are, but it is possible that your time, talent, and creativity could be better used elsewhere.

Consider an example. I was with a friend once who is a Linux convert, but doesn’t have much experience on Linux. His attempts to plug-in his USB digital camera to the Linux machine were failing, because the usb-storage module did not recognize his camera. Since he asked me for help, I looked at the error messages, at the files under drivers/usb/storage in an online Linux kernel tree, and found that unusual_devs.h did not have an entry for his camera. He did not have kernel compilation support installed, I didn’t want to do more work than necessary, so we just patched usb-storage.o and replaced another model’s entry with his camera. My friend was impressed beyond belief, not by me, but by Linux! He noted down the steps we took, and is probably patching the module with every kernel update, unless his model is in there already. This is a typical example of the Linux approach, which is why so many people like the platform. My contention is that the sense of machismo you get out of such things can lose its charm after a while, if you can find better things to do with your time.

Finally, I understand that it could be that you need to do repeated tweaking and configuration because that’s your job – you could be a system administrator. I was one myself for many years while I was an undergraduate student. Even in that case, you would want to optimize your efforts – prevent your work from becoming dull and dreary – invent ways to automate tasks – in which case it’s not a waste of time because you are creating something that’s useful. System administration could be a chore or an art – depending on how you do it.