davehayes.org

If you’re a Gnome user, like me, you’ve probably spent a little bit of time wondering what the best music player for Gnome is. Most people will readily agree that Amarok is the uncontested music playing champion of KDE, and many people run it with Gnome. I, however, would prefer to use an application built with GTK+ at the very least. Full Gnome integration would be ideal, but what exactly is out there?

Banshee

Banshee, in a word, is cool. It’s a great looking program, for one. It’s very feature rich with integrated CD burning, ripping, tag editing, podcasting, Last.fm support, music sharing (via DAAP), music recommendation as well as lots of other nifty plugins. Banshee is also one of the premier applications built with Mono, which makes it even more interesting. The only problems I see here are performance issues. Banshee (especially the search feature) tends to choke on my 18,739 song library. However, Aaron and Gabriel have some very exciting things in store for us that should make slow searching a thing of the past.

Exaile

Exaile is written in Python and aims to be a GTK+ equivalent to Amarok. I’ll be honest… I don’t like Amarok, so It’s probably no surprise that I don’t really care for Exaile, either. It seemed to deal with a large library pretty gracefully and has a lot of nice features like a cover art finder and a large number of plugins. If you like Amarok, but want something that will integrate well with Gnome, give this a shot.

Listen

Listen is truly an amazing piece of software. Its interface is very easy to use, probably the best execution of a “play queue” arrangement I’ve ever seen. It’s ability to dynamically grab cover art, Wikipedia articles and lyrics from the web make it very appealing to metadata junkies. It’ll also integrate somewhat with Last.fm and do some web radio and podcasting stuff. My only complaint is that I’ve had some stability issues, though I’m told they have since been resolved. Definitely give this one a shot.

Quod Libet

I haven’t spent much time with Quod Libet, but the degree to which it can be customized is staggering. You can choose from many different views including the iTunes style paned view or the pictured album list. In the album list, you can customize (with html, apparently) exactly how the albums are listed. The depth in which in utilizes metadata is striking and the included tag editor (Ex Falso) is handy to boot.

Rhythmbox

Rhythmbox is written in C so it’s quick, it doesn’t choke on large libraries, it’s competitive in terms of features and it will actually monitor my music folder and remove songs when I delete them or add the new ones in a sensible manner. One thing it does do that is rather unique is the integrate with the Magnatune and Jamendo online music stores. It’s really just a great all around player. That’s not to say it doesn’t have it’s own little shortcomings, like how it manages to be slightly offensive to the eye, though I can never put my finger on why.

Conclusion

There is a basic feature set shared by pretty much all the players. They’ll all show you cover art (most of them will even find and download it for you), most of them will let you share your music or listen to other people’s shared music via DAAP, they all offer some level of integration with Last.fm, they’ll all provide notifications via libnotify… there are really only a few major differences in terms of features, and even those are rapidly changing due to the fact that most of the players are extensible.

Things are looking pretty good for those of us using the Gnome desktop environment. All of the players we looked at today are feature rich and very usable and give you a lot of room to decide exactly how you want to manage your music. That freedom of choice is exactly what is so special about open source software, and it’s great to see that exemplified in software that we use every day.

So which one do I use? Well, I use Sound Juicer to rip my CDs and I tag and rename all of my music with MusicBrainz PicardQT and do most of my listening with Rhythmbox and burning with Serpentine. I find Rhythmbox’s speed and stability to be the deciding factors (rather than things like integrated ripping and burning), as it’s the player whose search isn’t painfully slow. That could very well change, though, with the upcoming release of the new generation Banshee.

You’ll also notice I didn’t make any mention of iPods. I don’t own an MP3 player, especially not an iPod. I’m a very big believer in open source software and Apple and their iPod are the antithesis of that in every way. If iPod support is important with you, I’d recommend you check the sites for each individual player and see where their support is, but not before you consider picking up a more Linux-friendly player.

Here are the goods thus far:

Message ends… for now.

Those of us using Gutsy were lucky enough to get a peek at the GIMP 2.4 release candidates during testing. Now that Gutsy is out, and GIMP 2.4.1 has been released, we’re still stuck on that old 2.4.0~rc3 release.

If you want to run the latest version, there are several ways to go about it. You could just download the source and do the standard ./configure --prefix=/usr && make && make install, but then our package management wouldn’t be aware of the new files and we could run into some trouble down the road. But we don’t want to wait for an official .deb (which could come as late as April ‘08), so it looks like we’ll have to make our own. This is actually very easy, here’s what you do…

First off, we need to make a directory in which we can work, and then enter it like so:

mkdir ~/Projects
mkdir ~/Projects/gimp
cd ~/Projects/gimp

If you get an error like “mkdir: cannot create directory `/home/dhayes/Projects’: File exists
“, you can just ignore it. We’re also going to need a couple packages, so let’s make sure they’re installed.

sudo apt-get install fakeroot devscripts

Now, we need to get the source package for the current version of GIMP in Gutsy (which is 2.4.0~rc3). We do that like this…

apt-get source gimp

That command will probably take a while to finish (for me it was about 15 to 20 minutes), so go get a cup of coffee or watch a couple episodes of Squidbillies while you wait. When it finishes, we’re going to need several development libraries to be able to successfully compile the GIMP, and we can use this command to make sure we get everything we need:

sudo apt-get build-dep gimp

You probably have time to watch another episode of Squidbillies while this one is going. Now, once that’s done, we need to get the source code for the new version. We’ll just use wget to download it.

wget ftp://ftp.gimp.org/pub/gimp/v2.4/gimp-2.4.1.tar.bz2

Again, this might take a couple minutes. Once that’s finished, we need to enter the old package’s source directory and tell the system where the new source code is.

cd gimp-2.4.0~rc3
uupdate -u ../gimp-2.4.1.tar.bz2

Once that finishes, we can change to the new package directory.

cd ../gimp-2.4.1

Now, we just have one more tiny little thing to do before we can build the package. The older Ubuntu package contains a patch that fixes a bug which no longer exists in the newer version. Therefore, before we can build the package, we need to remove that older patch. Here’s how we do that:

rm debian/patches/04_ubunut_bug_148380_upstream_fix.patch

Now we just need to build the package.

dpkg-buildpackage -rfakeroot

Now just kick back, watch a couple more episodes of Squidbillies and wait for that bad boy to compile. When it finishes, you’ll have some nice shiny new .debs that we can install like so:

cd ..
sudo dpkg -i *.deb

And that’s it! Bask in the goodness of the GIMP 2.4.1!