Ok, well maybe a bit of an exaggeration, but partly true :) Linus Torvalds has just been accepted as a Debian Developer, which means that, "Debian will have the advantage of being the distribution with the most official Linux kernel." World domination is one step closer....muahahahahahaaaaaaa... (seen on Planet Debian)

At least that's the way it feels! I just realized that my laptop supports 1600x1200 resolution! And I've been running it at 1024x768 all this time! So after fighting with the fglrx drivers for Debian, I can finally surf the web and read e-mails without having to scroll left and right all the time! Setting up fglrx was less than painless to put it mildly. For future reference, I had to do something like this:

aptitude install fglrx-kernel-src

cd /usr/src

tar jxf fglrx.tar.bz2

cd modules/fglrx

export KVERS=2.6.16-1-686

export KSRC=/usr/src/linux-headers-${KVERS}

debian/rules binary_modules

I would have hoped that m-a a-i fglrx would have worked, but alas... Oh, and other thing. ATI: it isn't cool to lock up the machine just because your driver doesn't support 16 bit colour. I had set my default colour depth to 16bpp previously in an effort to get higher resolution with the radeon driver, but when I started using the fglrx driver things would just lock up.

I've finally finished version 0.2 of splittar. In addition to some bug fixes, I've added a few new features:

• Generate files with more consistent file sizes
• Keep multiple files open so that smaller files can be added to archives with a bit of room left
• Ability to tweak how splittar estimates how well a file will compress. This is a weighted average between the actual file size, and the file size multiplied by the current compression ratio

Ian Bicking has inspired me to start keeping track of the little things in Python annoy me a little bit whenever I run into them. They don't really get in the way of development, but it would be nice if I didn't have to deal with them at all :) Maybe I'm just slow, but I didn't know about the os.statvfs() method until just yesterday. Up until then I've been parsing the output of 'df -k /mnt/drive' to find out how much free space a drive has! Of course, os.statvfs() is pretty much useless by itself. Try it out: import os os.statvfs(".") (4096, 4096, 19107656L, 2773425L, 1802799L, 9715712L, 8529635L, 8529635L, 0, 255) Great. What does that mean? Oh, I need the import the statvfs module to be able to usefully interpret this data. This module contains nothing other than a set of constants that index into the above tuple. So to get the free disk space, I would do something like: import os, statvfs s = os.statvfs(".") freebytes = s[statvfs.F_BSIZE] * s[statvfs.F_BAVAIL] Note that I'm not sure if statvfs.F_BSIZE or statvfs.F_FRSIZE is the proper entry to use. And the python documentation doesn't clear it up for me. There are really two things that bug me about this. The first is that the only reason for the statvfs module's existence is to make the os.statvfs() function useful. I would prefer that os.statvfs() returned a dictionary with meaningful keys, or an object with meaningful attributes. The stat module is another violator; it exists to make os.stat() useful. The second thing that bothers me is that I don't really think something like os.statvfs() is the best way to be calculating the free disk space in Python. Maybe I'll rant about this more in a future post, but functions and modules in Python that exactly mirror the underlying C library bug me. Sure, there may be times when you need access to the raw system call, but I can imagine that many people just want to know how much free space there is in a certain directory. Something along the lines of os.freespace(dir) would be a welcome addition to the standard library.

... with a few bug fixes. But what I'd really like to see is the ability to save a page (as opposed to a post) as a draft. I never get things right the first time so I like to write something, then come back to it a bit later. Luckily I'm not the only one who thinks this way! See Wordpress bugs #2194 and #1820

Here's another little script I'm sharing with the world. It's a plugin for vim that will look for aborted svn commit log messages and read the latest one into the current buffer. For more information, check out my svn-commit page.

Hate it when you write a big long commit message in subversion, and then the commit fails for some reason and you have to commit again? Tired of reading in the aborted commit log message into new commit log? Can't remember what subversion calls the aborted log messages? Me too. So I wrote this little plugin for vim that will look in the current directory for any aborted subversion commit logs. It will pick the newest one, and read that in. Just put this script into ~/.vim/ftplugin and name it something starting with "svn" and you should be good to go!

" SVN aborted commit log reader

" Reads in the newest svn-commit.tmp log in the current directory

" (these get left behind by aborted commits)

"

" Written by Chris AtLee 

" Released under the GPLv2

" Version 0.2



function s:ReadPrevCommitLog()
    " Get the newest file (ignoring this one)
    let commitfile = system("ls -t svn-commit*.tmp | grep -v " . bufname("%") . " | head -1")
    " Strip off trailing newline
    let commitfile = substitute(commitfile, "\\s*\\n$", "", "")
    " If we're left with a file that actually exists, then we can read it in
    if filereadable(commitfile)
        " Read in the old commit message
        "echo "Reading " . commitfile
        silent exe "0read " . commitfile

        " Delete everything from the first "^--This line" to the last one
        normal 1G
        let first = search("^--This line", "")
        normal G$
        let last = search("^--This line", "b") - 1

        if last > first
            silent exe first . "," . last . "d"
        endif
        normal 1G
        set modified
    endif
endf

call s:ReadPrevCommitLog()

For some reason the idea came into my head to try to apply Lennart Poettering's avahi patch to distcc today. Success! I've packaged up the result for Debian (with some small changes) and put it here on my site (check out the Software section).

For those of you who used to chat with me via ICQ and are wondering where I've disappeared to, I'm still alive. I've just stopped logging on because I've been getting way too many spam messages, with apparently no way to prevent them. You can reach me on MSN, my screen name is the same as my e-mail address.

I've just uploaded my first version of splittar - a small utility that will create tar files for you, but limit the size of each one. I wrote this because I couldn't find anything that would generate tar files of a certain size for me, and splitting one giant tar file isn't acceptable to me because that means in order to recover any data out of the piece, you need all of them assembled back into the original file...Which can mean several tens of gigabytes for me. You can check it out at https://atlee.ca/blog/software/splittar