P. Oscar Boykin

“All mail clients suck.” Unfortunately, it seems we need to use email none-the-less. Over the weekend I spent some time thinking about my email setup. I used to use Mutt. Unfortunately, it seemed that using it with multiple IMAP accounts was a hassle, so I switched to Thunderbird when I moved to UF. But of course, I would not be long satisfied.

First, why don’t I like Thunderbird (and indeed most graphical email readers): two main problems, speed and vim.

Lots of people are GUI bigots. I used to be one years ago. The GUI bigot assumes a GUI will be faster and better at everything. In fact, GUIs are usually easier to learn, but often slower to use. For instance, saving an email message requires carefully clicking on the message, and carefully dragging it to one of many folders. In Mutt, I say “s folder ” and I have moved the message. There is a very low chance for errors, and I don’t take my hands off the keyboard.

The second problem is no Vim support. Many people never bother to learn how to use a powerful text editor. This is a real shame. Sure it takes a while to learn an editor like Emacs or Vi, but the fact that these programs have been used for the past 20 years should tell you something about how useful they are. Consider industrial tools: it takes an investment to learn how to use them properly and safely, but once that is done, the operator is *much* more productive. Considering that I am at a computer as much as 75-80% of my work week, I can’t afford to loose productivity for fear of learning a new tool. Learning Vi, and using Vim makes me more productive when editing text, which is about 90-100% of what I do with a computer (writing papers, emails, and programs).

Thus, I am back with Mutt since it offers me speed and the ability to use Vim. This time around, I am using a few new tools to make things easier.

• Muttng: the main mutt developer has been a little slow accepting patches, thus in the greatest tradition of free software, Muttng has been created. A fork of the original Mutt, Muttng includes one very nice feature: a sidebar. This allows me to see which folders have new messages in them.
• Offlineimap: this is a tool written in Python, which synchronizes IMAP mailboxes with each other, or local mail directories. Using this tool, I periodically (every 3 minutes) synchronize my various accounts with my local disk. This has two benefits: 1) once I download the message I can quickly access it, whether I am disconnected or not, and 2) I have a backup copy of all my mail in a standard format (Maildir). This is really a great tool, it is probably an excellent solution despite what reader you use to read the mail.
• ESMTP: due to various anti-spam technologies it is getting harder to deliver mail from ones own computer. Increasingly one needs to send mail through well known smtp servers provided by ISPs. esmtp is a program which delivers mail through remote smtps, but works exactly like sendmail on a unix host. This allows existing software (like mutt) to easily interoperate.

Finally, how does one install all these goodies? With debian:

apt-get install esmtp offlineimap

Unfortunately, muttng is not in Debian, but you can get a deb, which may be installed using dpkg.

That’s about it! I am glad to be back in the text-only email world!

As I have mentioned before, I have a directory policy, that helps me keep organized and helps me back-up my files. I use the same policy on all my computers. I finally got around to writing some scripts to allow me to sync my various computers, using rsync. Here is how it works.

My main directory is stored on my server: boykin.acis.ufl.edu. This is the directory all others sync with respect to. I have a script called checkout.sh that allows me to checkout my main directory from boykin.acis.ufl.edu. This does so using rsync, so it only transfers the changes that have occured since the last sync. Any conflicts are placed in a back-up directory. After the sync, I look through the back-up directory and decide whether to keep the old local file (which is now in the back-up directory) or the one that was on boykin.acis.ufl.edu. After I finish this merging, I am ready to work.

After I do some work and I am ready to stop using this computer, I sync again with checkin.sh, which basically does the reverse.

The only special steps I needed to take were to make sure that the backup directories did not get overwritten and I also needed to make sure I exclude checking in any version control directories (from Arch for instance), since overwriting those directories would be bad.

Here are the scripts if you are interested:
checkout.sh:

#!/bin/sh

#Get the latest, and put conflicting local copies into current/bak/[date]
rsync -avzb -e ssh –backup-dir=bak/`date +%F.%H%M` –exclude=”bak/*” $HOST:/home/boykin/current/ /home/boykin/current/

And checkin.sh:

#!/bin/sh

#We exclude the versions directory, since the version control system has
#its own mechanism for handling this.
#Also, do not write local bak directories to the remote system. That
#Does not make sense.
rsync -avzb -e ssh --exclude="/versions/*" --exclude="/bak/*" --backup-dir=bak/`date +%F.%H%M` /home/boykin/current/ $HOST:/home/boykin/current/


A new preprint is on the archive: Functionality Encoded In Topology? Discovering Macroscopic Regulatory Modules from Large-Scale Protein-DNA Interaction Networks. This is joint work with Riccardo Boscolo, Behnam A. Rezaei, and Vwani P. Roychowdhury. Sadly, my name is wrong on the current draft of the paper. Hopefully that will be fixed soon.

The paper basically discusses the results of applying a community finding algorithm to a Protein-DNA regulatory network. Interestingly, a hierarchical structure is revealed that corresponds to known functionality.