EDIT: I should also mention that I have tried several alternatives, like claws-mail or KMail and while they are definitley good mail clients they did not provide the features (especially live virtual folders) and stability I was used to from Thunderbird.

On the the downside: It is “just” freeware (and not open source) and it is “just” VNC and not NX Server (NoMachine, FreeNX) or Remote Desktop but hey, its free its usable and its drop-dead easy to set up.

This way, you can combine the best of two worlds: A comprehensive and current database and fast offline lookup.

It takes a graphviz description, writes it to an output file and includes the generated postscript file. Unfortunately, it ceased to work after processing 15 files. This is due to creating a new latex write channel for every file operation. While I have not found out yet how to free such a write channel (it remains active even after closing the file), I have changed the macro so it reuses the channel. Here is the Modified Graphviz Macro. Be cautious however, as the original macro does not state a license so I am not sure wheter I may change and redistribute it.

This macro provides a really powerfull and elegang combination of two outstanding pieces of open-source software. Now I can create simple graph descriptions right inside the LaTeX document that includes the rest of the Text.

(define % '())
(define %% '())
(current-eval
 (let ([orig-eval (current-eval)])
   (lambda (sexp)
     (let ([result (orig-eval sexp)])
       (set! %% (cons result %%))
       (set! % result)
       result))))


#!/bin/zsh
doReport() {
SINK="$HOME/.micq/scripting"
echo "msg NICK" > $SINK
echo "command: \"$@\":" > $SINK
tail > $SINK
echo "." > $SINK
}
$@ |& tee >(doReport $@)


It also requires a running instance of mICQ under the specified username. Due to the nice scripting interface of mICQ, automated sending of messages is made extremely easy. You have to replace NICK with the intended receiver’s nickname in mICQ.

• Truely distributed (every developer has his own repository), therefore, its fast and disconnected operation is no problem at all
• Native handling of branches. The working copy of your branch will be exactly where your original trunk was (no problems with absolute paths [beware!]). Moreover, while branching is not too difficult with other systems, with git even merging is not only easy but fun. It is so much fun that I deliberatly create several development branches just to be able to merge them later. So you can develop every feature in its own branch. When you get distracted and have to do some other work just make a preliminary commit and switch to another branch, continue working there and at any time switch back.
• Merge history. When you merge several branches you will retain the full history of all branches that you merged.
• Amendable Commits. Like mentioned previously, it is no problem if you botch a commit, because you forgot a file. Just amend your last commit.
• Objects are tracked by content (actually their SHA1 hashes). If you synchronize your repository with someone else’s who happens to share a few commits, files or tags (because you have worked together before) these overlaps will be detected and can be incorporated into your version history. Your history is secured against corruption: The content can be verified to still produce the same hash it had when it was checked in. This makes it possible to give a sensible meaning to signing commits (e.g. for approval).

In short this is one of the nicest software development tools I have stumbled upon recently. You should definitely take a look.