Just like Firefox, it has a system of add-ons. The Notify Me add-on allows you to get Growl notifications when the song changes. Unfortunately, the add-on hasn’t been updated in 4 months. Here’s how I made it work with the latest version of Songbird.

Download the add-on from the Songbird Add-ons page. The .xpi file is just a zip file, and we have to unzip it to modify the contents. In Terminal, change to the directory where the .xpi file is (mine was on my desktop). Make a temporary folder to put the add-on files into when they’re unzipped. Put the .xpi into that folder and unzip it, then move the .xpi file out of there. Here’s the process in Terminal:

cd ~/Desktop
mkdir notifyme
mv notifyme-osx-1.1.0.xpi notifyme/
cd notifyme
unzip notifyme-osx-1.1.0.xpi
mv notifyme-osx-1.1.0.xpi ../

Once unzipped you’ll find a file named install.rdf. Open that up in a plain-text editor (Not MS Word) and change the maxVersion variable to whatever version you want. I’m changing it from 1.1.0rc1 to 1.2.0a.

<em:maxVersion>1.1.0rc1</em:maxVersion>

Save install.rdf and zip the add-on back up (notice I changed the file name):

zip -r ../notifyme-osx-1.2.0a-unofficial.xpi .

You can then go to Tools -> Add-ons… in Songbird, click Install… and find the .xpi file you just zipped. It shouldn’t warn you about the version being incompatible anymore.

Although I just detailed how to do this and it worked for this add-on, I don’t recommended it. The max version is there for a reason. There may have been changes to Songbird that make an add-on incompatible with a higher version. Don’t blame me if you try this and your computer catches fire.

Here’s the finished product: notifyme-osx-120a-unofficial.xpi

Fast forward 38 years to 2038, when a similar problem will occur. Unix timestamps are used to keep track of time for many systems. A Unix timestamp is the number of seconds since the Unix epoch, which was January 1st, 1970 at 12:00am. Unfortunately, these Unix timestamps have been stored using only 32 bits as signed integers. The maximum signed integer which can be represented in 32 bits is 2,147,483,647 seconds. January 1st, 1970 12:00am plus 2,147,483,647 seconds is January 19, 2038 3:14:07am. When it turns to 3:14:08am on that day, the Unix timestamp will wraparound to -2,147,483,648, so those seconds would be subtracted from 1970, giving you a date of about 8pm on December 13, 1901.

There have already been reports of problems from this. Many programs which calculate dates into the future more than 30 years, and use Unix timestamps, are likely to fail or get very confused at the least. There doesn’t appear to be any easy solution to this problem. Changing from 32 to 64 bits would allow us to calculate time in seconds for another 290 billion years. Unfortunately, the standard 32 bit timestamp is used in so much software and hardware that it’s impossible to update everything that relies on it. We’ll see what happens in 2038… or should I say 1901?

Way back in January I was playing around with this great software called gphoto. It allows you to attach your digital camera to your computer and take photos. This has many uses, one of which is to create time lapse movies by writing a script to take pictures every so often. So that’s what I did, one January night. I wrote a script to take a picture every 15 seconds or so, and set it to run from 6am to 6pm. Unfortunately, my battery died only an hour or two in, so I came out with an 11 second video of a partial time lapse sunrise.