Bad, vile and meaningless: Bickering Children from Alan's clob

Bickering Children

Watching the contenders for the Free Music Player For The New, Next, Brave Gnu Linux Generations, namely juk and rhythmbox, is a lot like watching two bickering children. Both are silly and mistrustable.

At the other end, we have rhythmbox. This software is just so awful, I don't know where to start. For instance, clicking on the track name at top of window opens firefox with, say, 10 tabs, if your track name happened to contain 10 words. I would not believe these guys have not heard of quoting your arguments. It's silly. That such glaringly obvious bug has made it past one minor release of GNOME just shows what kind of quality control that archive of subpar shite has.

Naturally, being a good GNU citizen, I tried to report the bug, but I can't figure out how bug-buddy works. There is no rhythmbox component there. I can't report a bug against the software. Hmm. But I remember that there were in the past because I used bug-buddy to successfully report bugs against this package. Perhaps I should rm -rf all gnome settings again and see if it helps...

Second problem that crops up is that neither software can survive even around 8000 tracks in collection. They load it for times that exceed 15 minutes. The display updates are slow. Rhythmbox miscalculates the time my mp3 collection would play, claiming it would play 130 days or something like that. It must have some trouble with VBR files! Juk is very very slow in adding the collection initially (spent about 1 hour, I think), but at least the actual usage seems relatively error free and fast after that. I wouldn't mind juk being so slow when adding new tracks, if only its display would appear to update normally. But no. It's slow and forgets to repaint its window, so it's an incoherent mess before long. Bah.

Occasionally, after tagging the files with metadata in juk, it decides to suddenly eat all RAM and crash. It doesn't appear to happen without me tagging plenty of files first. I don't know what's going on there.

Rhythmbox has a "Search" box in which you can type "Foo", to play, I don't know, Foo Fighers maybe? But the problem is that the cursor appears to randomly zag back to the beginning of the search box, so for instance trying to type "F", "o" and "o" can end up the system searching for "oFo". Impressive achievement in its own right. Extremely frustrating, too, just as I expect my GNOME to be.

Rhythmbox crashes on short mp3 files, such as 100 kB files that I had. For instance, on Flower Kings' album Flower Power there's a 5 second drum solo, which happily throws rhythmbox in an infinite loop. I can't believe no-one noticed that either. I bet they're all using xmms in the sly.

Conclusion

You know, every once in a while, I find myself hoping that people would stop reinventing solved problems. You guys need to pick one solution and fix it up to your liking. All this rewriting stuff is awful, when every rewrite is so pathetic with their different bugs and missing features.

In this case, GNOME folks for instance could throw away most of their work, simply because it doesn't work, and maintain GNOME as a simple patch against KDE. The patch is simple to make. Here's how: just hide and choose defaults for most of the features of KDE and produce an empty desktop with a panel at top and bottom. Then you can put your feet on table and sigh at a job well done. And the KDE monkeys, obsessed with making quality software, will give you improvements for free, all you need to do is make sure their improvements stay hidden!

What? Not a good idea? Well, consider this. I understand sometimes earlier designers make a fundamental mistake like going with a plugin architecture.

You know, plugin architecture is one where you get errors like "I can't play DVDs, I don't know what a DVD is" or "I have no clue what this keyword means, perhaps you didn't load everything necessary or made a typo". Plugin architectures are a pain to debug from end-user point of view because they aren't, by definition, capable of producing useful error messages. For instance, I can't ask totem "To what dark god of gnome should I sacrifice so that you would agree to play my DVDs", because that information is in the plugin which it hasn't loaded, for some reason. (It's not gstreamer0.8-dvd. I dunno. Perhaps it's not even supposed to work yet.)

So, if you must go with a plugin architecture, please do a favour for your users and make your system handle the errors of a plugin missing by saying out something useful. At the limit, the main component must know, in rudimentary level, the capabilities of every piece of the system so that it can say "I could do this but to do so you need that 5 MB library installed which you don't seem to have, so please apt-get install libbloat". Distribution packagers' responsibility is ensuring that a novice user gets all the relevant plugins by default, so that unless you go out of your way looking for trouble, trouble shall never find you.