My eternal gratitude goes out to Ned Batchelder, whose recent post (via the Unofficial Planet Python) has introduced to me the goodness that is The Daily WTF. Enjoy.

Today on the front page of the Toronto Star, the National Post, and the Globe and Mail is the "news" about the "Gospel of Judas" and how it describes a hidden side to Judas that has been covered up for centuries. I realize that everybody loves a conspiracy theory, hence the popularity of things like the X-Files and The Da Vinci Code. But just because something written at least 1,700 years ago was rejected by the experts of the day does not mean there is or was a conspiracy at work. In the article in the Toronto Star, Francine Kopun quotes expert Bart Ehrman that "There is no doubt it is genuine." A genuine what? Yes, this manuscript dates back to the 3rd century. It is genuinely a 3rd century manuscript. But is it genuinely the "Gospel of Judas"? Does it have anything historically accurate to say about Jesus or Judas? Nope. This is not the first time this "gospel" has popped up. St. Irenaeus of Lyons refers to a "Gospel of Judas" in his work "Against the Heresies," written around 180 AD, more than a century from the date of the manuscript being discussed in the news. Kopun quotes Ehrman again: "I think what this gospel does is show us that Christians in the early centuries believed an extremely wide range of things." If Kopun or Ehrman had done their research, they would have found that these writings were recognized as frauds at the time they were written, and had no basis in truth. I guess there's a lesson to be found here. You can write whatever garbage you want, and if nobody buys into it now, just wait a few millennia and people will trip over themselves to show how it was covered up by the established belief system, and write books and make TV shows and movies about it!

Of course, with my newfound screen real estate, everything has become so much smaller... ...which means that I need to wear my glasses to read anything :P I think my eyes are getting worse in my old age!

I've been using Black's for the past little while to get my digital pictures developped. For the most part I'm pretty happy with the prints. I usually end up paying somewhere around $0.30 for a 4x6" print, and the quality seems good. The only time I had a problem with the prints I returned them and they reprinted at no cost. However, getting my pictures to Black's is a bit of a pain. Their only interface right now is an HTML form that allows you to upload 12 images at a time. So when I have a few dozen pictures I have to upload them in batches...and keep track of which ones have been uploaded, and which ones haven't. That means clicking on the "Browse" button for each image, and selecting the image from the list of all images in a directory. If I happen to miss one, I'm basically screwed, since they don't keep track of the original order of uploaded files, and am left to look through each of the images on my computer one by one to check if it's been uploaded. This probably isn't specific to Black's, so don't think that I'm picking on them. It's probably a consequence of the relative immaturity of the online photo processing industry. What I'd love to see is something that lets you upload a whole set of images in one go. I realize that this isn't possible with a standard JavaScript/HTML type application for security reasons. What about some kind of online photo service API? It could be XMLRPC / SOAP or some custom protocol, it doesn't matter much to me. The simplest case of this would just have to support user authentication and image uploads. Then we could write real client-side programs that would integrate much better with our photo management tools. Imagine being able to click "print" on an image in your photo management software, and having an order queued at your friendly neighbourhood online photo processing centre! You could manage the rest of the transaction via your browser if necesssary, like handling delivery and payment options. Has anybody heard of anything like this?

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

With the upcoming changes in Wordpress to enable more CMS-like features (including draft pages!), something else I'd like to have is the ability to preview my changes to an existing post / page. Right now it seems like there's no way to do that; since the post / page is live then as soon as I save my changes, the changes are made live as well. I didn't find this in the Wordpress Trac, so I thought I'd mention it here.

Friends of Melissa and I are currently in Malawi working for Canadian Physicians for Aid and Relief (CPAR). Tess's recent post about the state of medicine in Malawi is pretty scary. We are very very very blessed here in Canada where we do not have to worry about diseases like malaria, where our children have excellent chances of living past their fifth birthday, and the average person can expect to live into his 70's. We live in a society of abundance, of plenty; sometimes of over-abundance and excess. Testimonies like Tess' remind me that I really need to be more generous to those less fortunate.

... 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

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()

distcc is a simple distributed compiler system Avahi is a framework for multicast DNS service discovery. Together, they are better than peanut butter and chocolate...Or peas and carrots...Or something. Back in November Lennart Poettering posted to the avahi mailing list with a patch that would add zeroconf support into distcc using the avahi framework.  I tried applying it at the time, but I couldn't get avahi working on my machine. Fast forward to the present (Jan. 2005).  The patch applies cleanly, and works pretty much out of the box!  I've made my changes available online here:

• My changes against distcc-2.18.3-3: distcc-avahi-debian.patch
• Debian description file: distcc_2.18.3-4.dsc
• Debian changes file: distcc_2.18.3-4.changes
• Debian diff file: distcc_2.18.3-4.diff.gz
• Debian package: distcc_2.18.3-4_i386.deb

Hopefully this can find its way into the main Debian archives soon.  There's already a bug report for it (bug #287832)