Positive negation, negative affirmation, or else?

It is easy to notice that our cognitive abilities have much less problem processing a positive than a negative assertion. That is, it is just plain easier to understand that something is right, than saying something is not wrong, specially in long discourses like a mathematical demonstration, a lecture, thesis or paper.

I think this is the reasoning behind most lists on how to fail at something: instead of saying "don't these otherwise you you fail", one says that "do these in order to fail", often in a satirical mood. Interesting examples include a book called How to Fail: The Self-Hurt Guide, and this quick guide to fail in biology fields.

Scientific fields don't fall short of this trend, though. For example, an article was published last year entitled How Not to be a Bioinformatician. Rob Hyndman, in his blog (which I recently discovered looking for some LaTeX examples), has the post How to fail a PhD.

To contradict this trend, he also compiled the straightforward guide called How to avoid annoying a referee (which anybody in the scientific business should read and follow), expanding from this post in stats.stackexchange.com (which, in turn, follows the mindset described so far).

Of course one does not necessarily need to write guidelines in a jocular manner. One such (must-read) example is 1990's article from Gopen and Swan called The Science of Scientific Writing, in which they convey that most of the effort in communicating a result lies on the writer, and should not be deferred to the reader.

I find myself amused by the positive "how to fail" guides, though. They can make the point they want to address, while using a lighter tone. Maybe these are better ways of planting the seed of understanding something important, without taking the change of being perceived as boring.

Migrating mail filters from MUA to MDA

I like freedom of choice. A lot. I even like to be able to choose different alternatives for common tasks during the course of the day. Call it a whim, but when it comes to mail programs, I can never decide, really, what's the best for me. Maybe this is because I never found one that suits all my needs.

Nevertheless, I used to use KDE before I became an Ubuntu user, and from that time I kept my whole PIM suite in the KDE stack from Dapper 6.06 to Hardy 8.04. Enough is enough, and if I'm not using KDE I wasting precious RAM and cycles keeping all those libraries loaded just for kmail and amarok. I will surely miss amarok, and kmail was great but it's time to move on.

I wanted my PIM to sync both from my Palm PDA and my home desktop, laptop, and workstation at work. I'm not a big fan of third party cloud services, if I can't be sure who has access to my data, so I decided to go back in time and migrate from a fully-featured-MUA centered setup to a home cloud-like setup. Provided I can access my PIM data from whatever MUA I choose, I can use pretty much anything that talks IMAP (which is anything these days). I'll be truly free, then, to use a great GUI app for the daily routine, a light GUI app if I need RAM to do more resource intensive work, and good old pine (ressurected as alpine) if I need to access my mail remotely, via ssh.

The project is basically to store everything in the desktop an imap server in my desktop machine, POP3 accounts fetched by fetchmail , and fed to an MDA (procmail or maildrop).

I already had kmail store my mails in maildir format, so installing an imapd server was a matter of installing the package. After a brief poll in ubuntu-users mailing list I installed dovecot, and kept using kmail for a year or so later to pull my gmail mail via POP3. Now, I'm only accesssing my mail via IMAP since the upgrade to Jaunty, so my home cloud project is kind of stalled.

I'm in the process of testing gnome-pilot and opensync to keep my PIM and Palm PDA synced.

All that remains is to migrate my mail filters from kmail to an MDA (be it procmail or maildrop), and then use fetchmail to get mail via POP. This is where I'm stomped. So far, the only think I've found that resembles a solution is this perl script, except it's the oposite of what I want. I'm not even sure I can use it to create the reverse solution I need.

I've drafted a little perl script, and I'll probably have to do it from scratch since my needs are pretty modest. I have 100+ filters (too many to convert manually), but most or all are the kind of 'match and move to a folder' simple filters. I'm just trying to scratch my own itch, not create a general purpose application, so it's probabl y a matter of simple Perl, once I decide what exactly will I output to.

Since time is always in short supply, if anyone knows a way to convert filters to either procmail or maildrop, I'll be glad to hear it. I also welcome suggestions on which of these MDAs to use.

Upgrading Ubuntu from Hardy to Jaunty directly

I originally intended to upgrade only my laptop because of NM, and waited until Jaunty beta was released for the laptop upgrade, but decided the corrected procedure was safe enough for my purposes to do it also in my desktop.

The following is what I compiled after doing it twice, and correcting the errors from both these attempts. What this means is that this is what I think I should have done on both times, but is not exactly what I did, i.e. on both attempts I had issues, and was able to overcome them.

I decided to follow loosely the upgrade instructions from Debian's Release Notes, and it mostly worked. I found out, unfortunately, that some tweaks were necessary, and in the second time I tried, I could bypass most of the problems I had.

First, a brief review of the process, then a brief description of the problems I had, and how I solved them.

The instructions start with obvious recommendations on backup, notification of users, and contingency plans. I back up fairly often my mission critical files, and did a full backup of my home dir and /etc. Since it was just my personal laptop, I didn't have to bother much about a contingency plan or warning anyone else. Check, check, check.

If you're trying these instructions, you should definitely read the Debian Release Notes sections 4.1 to 4.4, skipping only 4.2.4 and 4.2.5, which are debian specific, before doing anything to your system. Instead of these, make sure you disable every unnoficial repositories (meaning, everything that doesn't seem like archive.ubuntu.com). I made an exception for the partner repo, archive.canonical.com, which is where I get adobe-flashplugin from. If in doubt, read the Repo Howto.

A nice tip from debian is to do the upgrade from inside a screen(1), and also to use script(1) in order to have a full log of everything. Just copy and paste the commands from section 4.5.1:


screen -S upgrade
script -t 2>~/upgrade-jaunty.time -a ~/upgrade-jaunty.script
sudo aptitude update


Then proceed to section 4.5.3 to make sure you won't face an epic fail because of disk space, specially if you have a separate /var partition.

From 4.5.4 onwards, it gets very Debian specific, and although it might be interesting to read, we have to stick with our Ubuntu specific issues. This brings us to the point in which I describe what can go wrong if you follow the Debian instructions.

All the problems I had stemmed from the fact that the packages python and python-minimal was never pulled as a dependency in this whole process, and was only upgraded in the final step, too late for most python apps, that expected a clean python environment, but the above entioned metapackages kept at their 2.5 versions. I was actually surprised that this turned out to be a problem, especially because I thought all these apps were also in Debian.

I say many errors in packages upgrading returning messages like:

Instalando language-selector-common (0.4.2.1) ...
INFO: using unknown version '/usr/bin/python2.6' (debian_defaults not up-to-date?)
Traceback (most recent call last):
File "/usr/bin/fontconfig-voodoo", line 101, in 
main()
File "/usr/bin/fontconfig-voodoo", line 56, in main
fc = FontConfig.FontConfigHack()
File "/usr/lib/python2.5/site-packages/LanguageSelector/FontConfig.py", line 36, in __init__
self.li = LocaleInfo("%s/data/languagelist" % datadir)
File "/usr/lib/python2.5/site-packages/LanguageSelector/LocaleInfo.py", line 41, in __init__
et = ElementTree(file="/usr/share/xml/iso-codes/iso_639_3.xml")
File "/usr/lib/python2.5/xml/etree/ElementTree.py", line 546, in __init__
self.parse(file)
File "/usr/lib/python2.5/xml/etree/ElementTree.py", line 586, in parse
parser.feed(data)
File "/usr/lib/python2.5/xml/etree/ElementTree.py", line 1245, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 52, column 11

And a lot of other packages with less verbose errors, containing only the first INFO warning line. Crossing fingers wasn't enough, and when I saw most of the interface apps were hosed, I got this kind of errors when trying to run apps from the command line:

Traceback (most recent call last):  File "/usr/bin/software-properties-gtk", line 44, in 
from softwareproperties.gtk.SoftwarePropertiesGtk import SoftwarePropertiesGtk
ImportError: No module named softwareproperties.gtk.SoftwarePropertiesGtk

These messages made it somewhat clear that python modules were missing, but I made sure their packages were in fact installed. Reinstalling ( sudo aptitude reinstall [package] ) the package made the problem disappear for the application. I'm not knowledgeable in Python, but I think this has something to do with python byte compiling the scripts during package installation (please correct me if I'm wrong in the comments).

Luckilly I didn't have to reinstall the whole OS, just the python apps that were misbehaving. I had to go back and forth through dependency trees in order to find everything that depended on python and python-minimal, and reinstall them, and there were a lot of them. This was a good opportunity to use the script(1) log that was created in the process. It took me more than one hour, but I was able to fix everything without reformatting and reinstalling (kudos to aptitude interactive interface!).

I'm not sure why this issue affects Ubuntu, and not Debian, but I did run into this in my two upgrade adventures, so I thought it was worth to share the (probable) correct routine.

Now that the issue is covered, let's see what the upgrade routine would look like.

The first step in Debian instructions, is to upgrade apt, which will also pull libc and other essential stuff. However from the experience above, it would be useful to also upgrade python or python-minimal as soon as possible. It was only later that I found out I could probably have done both in a single step:

sudo aptitude install ubuntu-minimal

This is a meta-package that depends on apt, and python/python-minimal, so I think it would suffice. It will pull python2.6 and python-minimal2.6 as dependencies, so all python apps will already have their bed made, when it's required.

As a second step, let's make sure a second base meta-package kicks in, which will pull another batch of essential stuff:

sudo aptitude install ubuntu-standard

After that, you can safely issue the first step of the Debian release notes upgrade:

sudo aptitude safe-upgrade

Depending on which packages you you have installed, you might need to repeat this step until it upgrades no more packages. This is because although aptitude has a great dependency resolution algorithm, it's not perfect (but this is being worked on ;-) ).

When you come to the point that safe-upgrade can't upgrade any more packages, it's the time when most of the other stuff must be resolved, which is:

sudo aptitude dist-upgrade

This command should be the first time where packages are removed by conflict resolutions. Again, you might need to issue it more than once, but there's nothing to worry (unless you get errors, but they are being logged by script, and you can go over it whenever you want).

Now, as a final step, make sure the basic meta-package is upgraded, if it wasn't already:

sudo aptitude install ubuntu-desktop

Your kernel will be upgraded in this step, if you use the generic flavor, but your current version won't be removed. You might want to remove it manually afterwards. You can keep more than one, but it's mostly clutter, specially if you, like me, have a separate /boot partition.

Now you can logout of script, logout of screen and boot your new Jaunty. Computer Janitor (System>Administration>Computer Janitor, or whatever it is translated to for your language) will help you cleanup afterwards.

Note: Expect this mini howto to be updated.