This website contains various write-ups, articles and other pages about the various things I fill my spare time with. You can find an overview of the most recently changed articles just below this introductory message.
Most of the time i'm working on IRC related things. I'm an author of Anope, an IRC services package, and various other open-source projects. More information about these projects and other IRC related stuff can be found via the Coding and IRC links at the top of this page.
Time for some small bits bound together into a blogpost. First of all I have a new monitor which I really like, but that's not really all too interesting for you i guess.
Something more interesting is a package for highlighting Qt/KDE C++ sources in LaTex. I found it at some blog and it looks quite nice. I'm sure to use that when i need to put C++ code into a LaTeX document once.
A bit less recent is the discussion about Canonical's new notification system. Some KDE usability expert wrote a pretty detailed analysis on this proposed notification system. I must say that I'm quite positively surprised with the detail of this analysis. I wasn't that aware that there is much research for free software applications being written. It sure is nice to read about that once and I would like to see more in-depth research regarding free software.
Another find on the internet told me that the laptop screen in my Thinkpad T60 is one of the best laptop screens ever made. I have always been very happy about the screen on my laptop, and this only reassures that my laptop really is kick-ass. It's mine now for 2.5 years and only now do i get the feeling that not-too-expensive notebooks are having better specs than my laptop. I like it a lot.
The last thing I want to share is a lengthy article about QWERTY vs DVORAK keyboard layouts. It seems that the 'DVORAK is better than QWERTY' arguments are mostly false, although I haven't read the entire article yet.
I've spent another large chunk of my time on something I've wanted for a long time: keeping all my mail in one IMAP account. The idea is that I want all mail i receive to enter that one IMAP account and be automatically sorted server-side into the correct folders.
Sounds as something which enough other people want, so there should be enough tools to help me. Setting up an IMAP server is quite easy, dovecot does a good job. The quest for good software to download my mail and filter it into the correct folders is slightly harder.
I quickly found two programs for downloading mail: Fetchmail and getmail. Fetchmail requires a seperate MTA to actually deliver the mails, while getmail can nicely write into the maildirs I want to use. So on with getmail it is.
Downloading mail works just fine with getmail, sorting them into the various folders requires seperate programs. The biggest problem is on what criteria I want to filter my mail. I have a large number of mail addresses enabled on my domain, and I usually want to sort depending on the mail address of my domain the mail is meant for. The mail daemon for my domain however forwards all mail to one catch-all address which it then nicely puts in all usable header fields for the receiver. So the actual receiver of the mail is unusable.
On the other end of the forwarding pipeline there are other issues. Quite often mail is forwarded to various mail addresses before it reaches me. For example a server sends errors to it's local root address, which is set to forward to a general server administrators address, which then forwards to me (and others). This means that the original receiver is not usable either.
My problem should be clear by now :) I found that there is some header I can use to find the mailaddresses I want to filter on: the Received header. It contains information about all hops the message passed on it's way to me. The downside is that the mail address is within loads of other information somewhere halfway the body of this header.
The simple way to fix this was to write a program which would extract the useful mail address and put it by itself in a separate header which getmail can then easily filter on. So i set up getmail to filter the messages through that program and than abuse the multidrop system to read that header. Problems. The multidrop header is expected to exist when the message is downloaded from the server, while I only add it in the filter. Solution failed.
For more advanced filtering, getmail refers to maildrop. It's a nice program with a perl-like syntax to write scripts in which determine where your mail goes. It can put the mails into my maildir just fine, so another win. I configured getmail to use maildrop to deliver the mails and started to write a mailfilter file for maildrop.
The syntax is actually harder than it should be. I very often make mistakes which basically mean that no mail is being processed anymore. So i thought: why not write an easy maintainable script to filter the mail addresses myself? Same idea as I had with getmail: put the destination in the headers in the script an let maildrop figure out where the maildir for that destination is. This works, but it seems that mail headers are pretty free-form and parsing them well is probably something that would take me days to do correctly.
So that's where I am currently. It will all work eventually, but in the end it will have cost me days to set it up and migrating everything will take quite some time as well. Let's see if I want to put that much time in it still, or am I missing an obvious, much simpler approach to my problem?
I've spend today updating the site. As a reader you shouldn't notice much, apart from the spam being gone. The code is entirely rewritten and more maintainable now.
There's only one thing left to do tomorrow: rewrite the backend for adding and editting pages. It's not terribly complex, so it should be doable without too much hassle. I can then finally start looking into providing an archive for all my past posts.
So anyways, have fun with it. I should be updating this site more regularly from now on.
So I've finally gotten back to doing something here. I'm aware of the spam in the comments. I need to finish the admin interface for comments so i can delete them all. Apart from that I'm still alive and doing stuff. Today I've decided to try Arch Linux only to realize that it's not for me.
I was interested by the 'rolling releases' they have. Instead of fixed releases, their repositories always have the most recent available packages. I deciced to start reading into their docs to see how easy it would be to install a system. They want the distro to get out of the way as much as possible, resulting in a lot of manual configuration to get things working. Having years of experience with Linux on both servers and desktops, that shouldn't pose a problem.
First problem: I can't get the USB images to boot on my laptop. I still have some empty CD's around here somewhere, so no problem. It finally boots quickly into a clean system with a very simple installer. The installation itself is no problem if you already have some knowledge. A reboot later and there is my nice and freshly installed system.
Next step: basic packages up to KDE. Their package manager (named 'pacman') is quite simple and therefore nice. It reminds me of apt-get, but there is a lot less clutter in the packages (it's a shame the -doc packages are seperated in Debian for example). All installing went fine until I had to configure X. First boot, no input devices. Hard reboot. Turns out i forgot to run the HAL daemon so X didn't know about any of my input devices. Next try, slightly better. My keyboard and trackpoint work, but not my touchpad. Quite a time of googling later I discovered that HAL didn't expose the device just fine. Instructing HAL with a few lines of config did the trick.
X works; installing KDE (using KDEmod) is a breeze. It boots just fine from the first time on. A reboot to see how fast stuff is shows boot times of less than 20 seconds, impressive. Next step: getting GTK to look a bit like KDE/Qt. Two options: an oxygen theme for GTK or the GTK-Qt theme engine. Installed both, could not find a place to configure either of them. Restarting KDE gave me the options for the GTK-Qt theme engine, but that looks quite ugly with Oxygen. After some googling again I found the syntax for gtkrc files so I could plug in the Oxygnome theme there. Save file et voila, beautiful GTK apps.
Some more beauty: bootsplashes. I nicely follow the instructions to install fbsplash/gensplash. First error: vga mode unsupported. I look it up in another table than provided on the site and I can get the correct one. So it boots and halts half-way init, saying it's unable to check the root filesystem. Despite whatever I try, fsck refuses to identify my root partition as ext3. Right now it still does not boot.
Time for a quick overview of what I've reached today. I spent the entire evening working with Arch Linux to get it setup, only to have a non-booting system by the end of the night. It's nice to play with Arch, but Kubuntu just works for me and it will take me only an hour before I can get productive again on Kubuntu. I do like the ways of Arch Linux, but it's just not for me. I want a distro that works and allows me to do what I want quickly. Arch just doesn't do that for me.
Next thing to look at once my laptop is up and running again: cleaning my desktop so I can reinstall Kubuntu on it sometime soon. I'm still running feisty and being unable to install software the simple way starts to get annoying. Another thing to look at: updating the software behind this website. I guess my vacation will be filled with things I haven't had the time for recently.
Today we have released Anope 1.7.20. The bugtracker is nearly empty -- the one bug remaining is probably fixed but we're waiting on full confirmation -- and we're confident that the current codebase of the 1.7 series is pretty stable.
The next step is to fix up all documentation and other documents included in the release so that they are all up-to-date and do not give old instructions to people. Once this is done we can pack up a first release candidate for 1.8.0. Basically this means that 1.8.0 will finally hit the streets in the upcoming 2-3 months.
What will happen once 1.8 is the new stable branch? We will be working on Anope2, a rewrite in C++. The core of this rewrite will not be exclusive to Anope: any project building some sort of u:lined service should be able to use this core. The core will be developed together with the people from Denora. This helps to assure that the core does not get Anope specific, and it reduces the development effort required per developer to a doable level.
The core has been labeled IRC Cantus. There is not much official for that yet, apart from a very early web page with the logo on it. Once there is more info available I will post more updates on IRC Cantus.