I forgot my password.

I had this brilliant idea of protecting the documents on my laptop with encryption some time ago in-case it ever gets stolen. And of course, encryption is useless without a good password. And now I forgot the password. And the backup doesn’t cover the latest stuff…

At least I decided to cut down on the number of unique password I have to remember. If only I could figure out what the password was for this particular set…

Amending the checkin

After finishing a particular software feature, I like to check in my work. The problem is, I get into a dilemma. Do I check in now, or wait until I’m sure the feature works as advertised. If I check in now, then I might discover that forgot to add something else to the checkin. If I don’t check in now, I might start on another feature, and then it gets messed up.

git has a wonderful feature that fixes this. git commit –amend. Basically, you commit your changes. Later on, you realize there were some other files that should have been committed alongside the first commit. So you just amend the previous commit with your new files. Really nice feature, and should make the history logs much nicer to look at.


I’ve been playing with KDE4 for awhile now since Kubuntu released 8.04. Although it’s a little more polished and useable than when I tested the 4.0 release, it’s still not quite there yet. That is, it doesn’t give compelling reason to switch from KDE 3. That said, KDE4 is beautiful.

One of the complains against KDE that it wasn’t very beautiful. It was very functional, but beauty… To me, it was like most enterprise level software. Functional, does what you need it to do, but it’s not a thing of beauty (if you want beauty, check out what Apple is doing with their stuff). KDE4 is beautiful. The artwork team in KDE has done a really good job. And with the addition of 3D accelerated graphics, it actually feel smoother too.

I really look forward to what the KDE team has in store for v4.1 and beyond. It’s going to be an exciting year.

cross-platform development

One of the problems of doing cross-platform development, is that you don’t necessary know what the environment will be at the person who is compiling your software. So, you need to be able to check this and maybe notify the user what additional software needs to be installed. You also want your build system to be flexible enough to maybe work around issues and options.

I used to write the build system for the unix development at my previous work. Since the target was limited to HP-UX and Solaris, it was somewhat easy to just create a script which figured out which platform we were at, and then copy the platform specific Makefile to the right location. When I started working on my own private projects, I wanted to make it more robust. Initially I was looking at the automake/autoconf systems. I found it a little too complicated for my needs, although autoconf by itself might have been useful. I still find it somewhat troubling to have to learn another language (M4) to write the configuration files. To me, configuration files that generate the Makefiles should be as simple as possible.

While I was investigating and trying out build systems, I heard that KDE had started using cmake. This made me at least a little curious about it.

The initial impression was that cmake makes it really easy to get started. I was up and running faster with cmake than I did with the autotools chaintools, and almost as fast as writing my own Makefiles. Now, my projects aren’t as big as the KDE project, but if it works for them, it should work for me.

One of the problem I found is the some problem I have found with most cross-platform tools: it has to target the least common denominator. Some of the features seem to indicate that cmake was first developed on Windows, or that developers were primary Windows developers. For instance, there wasn’t a good way to clean up custom generated files using cmake, as in you could make clean target in Make have a dependency on something else, so that that something else also got removed when clean was called. Reading the faq, this seems to have been fixed in 2.4.

Although I haven’t done anything complicated with cmake yet, so far I have been pretty happy with it. It isn’t much more complicated than handwritten Makefiles, and it should save me tons of work on porting.

Kubuntu 8.04 (Hardy Heron)

I’ve decided to reinstall my Linux system, and in the process upgrade to the next Kubuntu version, 8.04, also known as Hardy Heron. I usually don’t like to reinstall my OS when I upgrade to a new version. One of the reason I decided to move to a Debian distribution was that I didn’t have to reinstall during upgrade. Unfortunately, when I initially installed Kubuntu 6.06 (Dapper), I made the / partition too small. Although it was big enough for normal usage, during upgrades, with multiple versions of the kernel, firmwares and kernel modules, it got too tight. Hopefully, the current size of 1 Gb should be enough.

In general, I hate reinstalling an OS. Mostly because I spend some time customizing it, writing scripts to help me in the day-to-day work. Most of the time, I forget to backup these scripts, so I have to recreate them once I notice they are missing. Mostly finding everything to make the desktop look and feel exactly as I had it before I made the upgrade do take time. Of course, I’m also finding functionality that I’ve never noticed because they have been hidden because of customization, or I just hadn’t looked.

Although I stopped installing beta software (unless force to it), I’ve been pleasantly surprised by the stability of Hardy. Stuff like hibernation and suspension that I previously had problems with, works now. I never got the kernel in Gutsy to boot, so I had to be content with the kernel from Edgy, but 2.6.24 works perfectly now. And Kontact seem more stable than previous versions. The addressbook has gotten a much needed speedboost (when using LDAP), although it still doesn’t expose all the fields. This version seems to be a keeper.

Distributed Version Control Systems

I recently moved all my development over to a distributed version control system (dvcs) called git. I’m not going to write about dvcs and the difference/advantage/disadvantage between it and central version control systems, like Subversion. There several good articles and blogs on that topic around already [1][2][3]. This is more about my journey.

I started my (development) career using SCCS and RCS slowly moving towards CVS. They worked, with some warts. Some of the weaknesses are well-known, but for tracking individual files, they work really well, and I still use it. Once Subversion came on the scene and stabilized (with the introduction of fsfs repository type), I was hooked. One of the thing I really liked was the concept of change set, that is set of changes that logically belongs together. Like say, a header file and the source file. Change the header file and the source file needs to be changed too.

I recently got in trouble with my svn repository when my working set got into an invalid state as far as my repository was concerned. What happened was, when I moved back to Norway, I shipped my computers. I had made a backup, but had continued developing. And the shipping had taken time, so I had created a new repository from my backup. But since my working set was at a different version than my backup repository, svn wouldn’t let me checkin. Frustrated, I started looking at other vcs.

What got me first looking at git was the google talk by Linus Torvalds. I then read up at the current state of dvcs before I started testing out git, and I was hooked.

What I find interesting is that git feels ‘natural’. The impact on my development process is minimal. As an example, to create a tag in svn:

svn copy svn+ssh://server/path/to/project/trunk svn+ssh://server/path/to/project/tag/{version}

The same command in git:

git tag {version}

Branching is similarly easy in git. But I think the main advantage is that I now can I have multiple repositories for the same project.

My current work process is like this:
edit edit edit
checkin into local repository
edit edit edit
checkin into local repository
happy state
push to private server
edit edit …
once stable state
push to public repository

At at any time during the editing phase, if I’m unhappy with the track I’m on, I can always throw out the changes without messing up my private or public repository.

I really think you should at least take another look at the dvcs and see if it’s something for you.

[1] Wincent Colaiuta’s development blog
[2] Dave Dribin’s Choosing a Distributed Version Control System
[3] Ben Collins-Sussman’s The Risks of Distributed Version Control

mail labeling

Following the previous post, I’ve been playing around with labeling my email. Mutt has really good labeling support, mostly because of its flexibility. With it, I can pretty much do anything I need using labels (add, delete, modify, limit views to a given label etc), so it has become my primary email client these days.

I used to use Kontact, and I still like some of its functionality (like setting up search folders), but not being able to edit and add labels make it hard to use. It’s also not that stable when you’re using imap. Looking forward to trying it out again when KDE 4 turns stable. Hopefully, it is more stable there.

Being, the lazy bum that I am, I really don’t want to manually add labels to email from people I know when the computer can do as good a job as I can. Enter maildrop. One thing that I noticed was when I wanted to the system to add multiple labels to a given email because multiple people was on the mail list. I therefore wrote the following maildrop rule (procmail users can probably write a similar rule for their system):

# Get address from the From, To, and Cc line
foreach /^(From|To|Cc): .*/
    foreach (getaddr $MATCH) =~ /.+/
        # check if the address is in the label file
        # label file has a key/value pairing looking like this
        # exlabel
        # where first part is the address and second part is the label
        TMPLABEL=`grep $ADDR labels`
        if ( $RETURNCODE == 0 )
            # if message already has a label, keep it
            LABEL = `echo $TMPLABEL | cut -d' ' -f2`
            if ( /^X-Label: (.*)/ )
                xfilter "/usr/bin/reformail -I 'X-Label: $MATCHLABEL, $LABEL'"
                xfilter "/usr/bin/reformail -I 'X-Label: $LABEL'"

So far, it’s been working really well.

Organizing Your Email

One of the problems of organizing your email is how to do it. I don’t really like deleting old email. Mostly because I like to go back and read some of the older email. One problem with that is since the outgoing email (from me) got stored in the Sent folder, I didn’t do a really good job at storing those email. So the threads and context are often broken, especially if people didn’t quote the whole email (and people who used email back before 2000 did a much better job at trimming quotes). Another problem was, how do I file it the email? I used to file everything job related into a job, anything academic into school, anything from friends into letters. Of course, then I start getting email from coworkers not job related. Do they go into jobs or friends? Same with fellow students…

Last summer I read two brilliant (related) posts on email handling: one from Scott Yang and the other one from Aristotle Pagaltzis. Basically, stop filing your email. Just archive everything (similar to the Gmail model). Don’t worry about categorizing. Trust your email client (or search functions) to retrieve your email.

I’ve been using this scheme since last summer, and so far, it has worked brilliantly. I keep all my email conversations in my inbox until the conversation is finished. Then I archive it, without thinking about where to file a specific thread. Mailing lists are special in that they go automatically into their own folders, but then again I don’t really subscribe to many mailing lists anymore (mostly security related). Otherwise, I just get them through the gmane service. One thing I did modify was that I set up my system to automatically archive the archive by year. So that December 31 at 23:59 (or so), everything in archive gets moved to archive.YEAR.

I do miss some of the features that Google introduced with gmail, though. The labeling facility is gmail is pretty brilliant. So, you can manually give an email a given label, and you can then search on that label. I miss that functionality. You can use search folders (in kmail, that I use and probably other email clients), but it’s not the same. One problem is that some people change their email, and then you need to update the search parameter. It would be much easier if you could just click on a button that said tag this as that. One problem would be that the tag wouldn’t work across email client unless there was a unified way for email client to read the tags, say x-tag or x-label. Of course, this mean that the email itself would have to be modified by the client, although some clients already do this.

In any case, currently the new email handling scheme works fine, and certainly makes me more efficient.

Hmmm… 8/8. 8 being a lucky number in Asian mythology, or stuff or something. Forgot about that.

Thinking about redesigning my website again. I want to do some more AJAX on the site, and I really need to rewrite the gallery section. Right now there is no text, and the gallery sucks… Probably would have make some more server side scripts, then.

Currently in Norway visiting the old folks. I’m going a little crazy. Need to get out, back home, to the US. I miss my car and TV, and just being alone. I really need to cut down how much time I spend in Norway.

Finished my first year of Graduate studies. One more year to go. It’s been interesting going back to school, meeting new people again, and just worry about learning stuff. Really enjoying myself. Well, it’s vacation time now.

Two programs that people who are running Linux should try out are amaroK and digiKam. amaroK is a really excellent music player, but a killer music management capability. Never used iTunes, but I think Amarok is probably one of the best out there. digiKam is a photomanagement program. Another killer app. Check them out.