At the end of 2012, I realized that two of the software I started using in that year started with the letter 'm', and later, I remembered two other as well, so here's this post to document what I used in 2013.
mcabber (console XMPP a.k.a. Jabber client with built-in OTR support)
In the last ten years, I always preferred IRC to XMPP/MSN Messenger/Skype since although all of them has both the option to one-to-one and many-to-many chat, latter is the common use-case for IRC while former is with all the others. That's when Stefan showed me OTR (Off-the-Record) messaging, which provided strong autentication and encryption along with deniability afterwards. We started experimenting with version 1 on IRC using irssi-otr, but found it to be quite unstable, and another big problem was that I prefer to run irssi on a remote server, which defies the whole purpose of the end-to-end security OTR aims to provide.
So I decided to give it a try with XMPP, especially since
H.A.C.K. has its own server – with registration available to anyone – at
xmpp.hsbp.org. Stefan recommended me mcabber as a client, and although
it has its limitations (for example, it cannot connect to multiple servers and
I had to use Pidgin for registration), I found it perfect for my
use-cases, as it has built-in support for OTR up to version 2, and has a nice
console UI.
minidlna (lightweight DLNA/UPnP media server)
I didn't know what DLNA was before I got my hands on a device that actually
supported it, then I started using Serviio, but it had its limitations.
It required Java, updated the local repository really slow, had an awful and
complicated GUI – and had I mentioned it ran on Java? After a week, I started
looking for alternatives, I naïvely typed apt-cache search dlna and
that's how I met found minidlna, which was quite the opposite
of Serviio.
It consisted of a single native executable, a config file
and some docs, and since it's targeted at embedded systems, it ran quite fast
on my dual i3 notebook. The Debian version runs as an unprivileged user by
default, and I added my user to the minidlna group, so I can just drop/link
files into the /var/lib/minidlna directory, and they just become accessible
for any DLNA consumer. In case of content from Bittorrent, I can even
download it to a remote server, mount it with sshfs (also one of my
favorite solutions), symlink it into the directory, and the TV magically plays
the file from the remote server via my notebook over the home Wi-Fi, which
works suprisingly well even in case of HD contents. Also, on Debian, the DLNA
icon is a Debian swirl logo, so it even looks great in the TV menu. :)
mosh (SSH replacement extension for roaming clients and laggy connections)
I think SSH is one of those software that demonstrate the power of “the Unix way” the best. I use it for lots of purposes, but at the same time, I've found it really hard to use in case of laggy connections. I cannot even decide, which one I hate better, both cellular data connections (GPRS, EDGE, 3G, etc.) and suboptimal Wi-Fi networks can make me want to smash the keyboard. After using mosh while uploading huge videos over a consumer-grade asymmetric uplink, I also found that networks without QoS can also make the interactive SSH experience turn into a text-based RPG.
I installed mosh on the two boxes I most regularly log into via SSH, and found it really useful, especially since Daniel Drown patched mosh support into ConnectBot, an Android terminal emulator and SSH client, which makes sense, since handheld devices have the most chance to be connected to networks matching the description above. Although some say it breaks interactive applications like VIM, I had no problems with version 1.2.3 I downloaded and compiled almost two months ago, so if you also find yourself connected to laggy networks, give it a try!
mutt (the mail user agent that sucks less)
I've been a KMail user since around 2007 and although I saw many of my friends using mutt with server-side magic, I used it just like my window manager and my shell – a tool, which I used until it worked without a hassle. When it misbehaved or crashed (it did so quite a few times), I sent bugreports, partly to make myself feel better, partly to evade “and have you reported it” questions, but I also hoped that they'll fix these properly. Then one day, during an IMAP mass move operation, KMail crashed, and did so even after restart. I've had quite an experience in bruteforcing KMail into a working state from the past, but when I couldn't change the situation in half an hour, I decided that it's time to change.
I had three mailboxes on two IMAPS servers with two distinct SMTPSA MTAs to send mails through, and I also used client-side filtering extensively. I migrated latter functionality to procmail on one of the servers, and as of February 2013, I use a transitional setup with on-line IMAP mailboxes and a local header cache. In the near future, I plan to migrate online IMAP access to a solution based on offlineimap and run a local MTA that forwards mail to the appropriate SMTP server, preferably through a tunnel/VPN to avoid password authentication and my endpoint IP address appearing in the MIME envelope.
I only had one problem so far, it seems that the online IMAP functionality is not so well-tested in mutt, so even though I use Debian testing, it crashed in around 30% of the cases when changing IMAP directories, but I managed to solve it by compiling Mutt from source, including the folder sidebar patch. Here's how it looks with the current config, displaying the Python SOAP mailing list.
