There were a number of reasons why I abandoned Slackware and moved to (K)ubuntu back in 2005, but the root cause for almost all of them can be condensed into a single word: Laziness. Back then I was getting weary of compiling software that was not provided by the package system and Slackware's release policy seemed a bit slow and conservative to me. Also, (K)ubuntu appeared to be something like a more bleeding-edge variant of Debian which still provided reasonably stable releases that - unlike Debian's sid distribution - could be used without fear of installing completely broken packages just by performing an upgrade at the wrong time.

Now I know that complaining about bugs in FLOSS projects is generally frowned upon, but the upgrade from Kubuntu Jaunty (9.04) to Karmic (9.10) really made me wonder whether Canonical is going a bit too far with it's tendency to go for bleeding edge versions of the software they package. So far, I've had my share of troubles with the various incarnations of Ubuntu, but this time, being hit by 3 show-stopper bugs on only 2 systems was a bit much. Let me whine about them for a second.

While booting my newly upgraded desktop system and even before the X server was up and running, I could already witness the first issue: The kernel failed to establish a working connection to my UMTS modem (a Huawei E169 / E620) and conveyed this failure by spamming the terminal with messages like ''option_instat_callback: error -108" (see bug #446146 on Canonical's Launchpad). „Great! So no internet access for now“, I thought and logged into my KDE session, or rather, what was left of it. While X11 reported that it could successfully load AMD/ATI's proprietary fglrx driver, it failed to initialize the DRI. Then the KDE session started with a dialog indicating that kwin had just crashed repeatedly and asking me to choose a different window manager (from a list containing one entry: kwin). And just as the prospect of a cozy afternoon started to dwindle away, plasma-desktop fired up – and crashed.

Not entirely satisfied by the prospect of running a desktop environment that was lacking both a working window manager and a desktop shell, I set out to try and get it into some usable state. After having read various posts on bugtrackers, forums and mailing lists, I installed a newer version of the fglrx driver (the one bundled with AMD's Catalyst 9.10 release), which solved the DRI issue and allowed kwin to run properly. After that, I fetched a working configuration for plasma-desktop (plasma-desktoprc, plasma-desktop-appletsrc) from a different user and customized it to my needs (plasma-desktop's default configuration that appears to be used when the RC files are not found in ~/.kde/share/config, crashed as well). Finally, I tried to tackle the issue with the modem using the workarounds described in the corresponding bug report - with limited success. Upgrading to a release candidate for kernel 2.6.32 would solve it, but it would also break fglrx, which does not yet support that kernel version :/ Right now the only way of making the modem work is to load the usbserial module with vendor and product id passed in explicitly, which works sometimes :/

All in all, I think it's safe to say that this was one of the most horrible distribution upgrades I've experienced thus far. I'm almost relieved that the next iteration will be a long term support release, so there is reason to hope for a more elaborate testing cycle …

While reading blog posts about the “Nigeran Conference on Free an Open Software”, which was held back in March in the city of Kano, I stumbled over the following quote by Jonathan Riddell:

I also gave a talk on Open Street Map which I expected to be a fun aside from the main free software topic but was picked up by everyone there as being a must-do project for Kano which currently has no maps at all (Google maps shows this city of 9 million people as a crossroads in the desert).

Now, while according to the Wikipedia article on Kano, the city has “just” about 3.8 million inhabitants, it is still a bit of a shame that there appears to be so little commercial interest in creating or publishing freely accessible maps. I mean, come on, that’s a metropolis! It’s got almost half as many people in it as my entire home country!

From a slightly more optimistic perspective, situations like this could really be a way for the OpenStreetMap project to prove its worth even to people who don’t care about the idea of free-as-in-freedom knowledge. Because as nice as it is to have liberally licensed maps covering just about any corner of every major city in Europe, the prospect of having projects like OSM create maps for regions that have no easily available maps at all is an entirely different cup of tea.

After reading jriddell’s post, I wanted to have a look at the current situation regarding Kano myself (and I also wanted to have a peek at whether the OSMing of the city has already begun). Here’s what I found (starting with a satellite image for reference):

Kano as seen on Google Maps’ satellite view

Kano on Google Maps

Kano on OpenStreetMap

Unfortunately, even the OSM version is still pretty sparse. I checked other mapping services like Yahoo! Maps and Microsoft’s Live Search Maps, but they all show a similarly sad picture – probably due to the likely case that they all get their data from the same sources –, so I didn’t even bother to upload screenshots.

I’m still really excited about the idea that people all around the world might be able to create the best street map ever made, especially with regards to areas where there appears to be little commercial incentive to do so. With a lot of motivated people and the necessary access to technology OSM might one day be void of empty spots.

With Ubuntu 9.04 (aka Jaunty Jackalope) nearing completion, I'm getting more and more concerned about the fact that it will probably not feature out-of-the-box OpenGL support for my notebook (or, more precisely, its ATI Mobility Radeon 9700 graphics board). For those of you not in the know, AMD will drop support for quite a few of their not-so-recent products in the Catalyst 9.4 version of their proprietary fglrx graphics driver, so future releases will not work with R500 series chipsets and below. The news of moving the responsibility for supporting legacy cards to the open source drivers was not well received (there was quite an outrage at the Phoronix discussion board [1]), but the decision stands. Unlike the Windows version of Catalyst, there won’t even be bugfix releases for legacy cards.

For me personally, this issue wouldn’t be so acute were it not for Ubuntu’s decision to ship a rather recent X version (X Server 1.6) which is in turn not supported by any driver prior to Catalyst 9.4. And since the free-as-in-freedom xf86-video-ati driver’s OpenGL support is still rather limited on my Mobility Radeon’s R350, I’m feeling a bit out of options for a proper migration path. This is a bit ironic considering how I was previously hit by a bug in the fglrx driver shipped with Ubuntu Intrepid that essentially forced me to run a rather complicated mixed-release setup with a number of outdated Ubuntu Hardy packages. Well, at least I’m getting used to this kind of crap ;)

If this wasn’t a notebook, I’d just plug in a newer graphics card (not sure if it would be one by AMD, though) and be done with it.

Footnotes

[1]

Even though I’m a bit annoyed about this issue, too, I must say that I feel sorry for AMD’s John Bridgman who is constantly confronted with a lot of bitterness in discussions about his company’s products, yet manages to do a great job commenting and explaining while retaining a friendly and open attitude

I guess that’s not what they intended when they coined the term „viral marketing“. Just one day after I have reactivated my Twitter account, their website was hit by an attack exploiting a cross-site scripting (XSS) vulnerability in the „Bio“ section of user profiles.

From what I could get out of the coverage by mashable and Damon Cortesi, the attacker successfully injected a piece of JavaScript code that would hijack the session of any user viewing an infected profile. It then used the hijacked session to publish a promotional message for a website called „StalkDaily.com“ before inserting itself into the newly infected user’s profile. Now anyone who would take a peek at the infected user’s Bio with a JavaScript-enabled browser would in turn also get infected.

What strikes me as surprising is that such a serious vulnerability (forgetting to escape user-generated field contents upon display is really, really nasty) has gone unnoticed for so long, especially since the nature of an exploit for this type of vulnerability is fairly trivial.

Since there no way for a web browser to distinguish injected code from code that actually belongs to the trusted site, I’ll take this as a warning shot and as a stong incentive to enable JavaScript on a site-by-site basis only.

Having been using Textpattern for quite a while now, I became a bit annoyed by some of it’s quirks and limitations. That is not to say that Textpattern isn’t a good piece of software, I just never really got comfortable with the way things work there. I could go into detail about why I think that storing templates in the database is a bad idea or how having a section hierarchy with a maximum depth of one is a bit limiting, but I guess I’ll just leave it at that.

Luckily, searching for a new CMS to get used to wasn’t much of a challenge considering the massive amounts of praise I read about Drupal. My only real worry was whether it would overly big and complex for a site as small as this one, which – as I know of now – is not the case at all due to it’s high degree of modularity. After migrating all the content (which involved quite a bit of manual tampering with the database) I can say that I’m really happy with the system. Drupal’s taxonomy system is plain awesome and it’s theming engine is flexible enough to generate almost a 1:1 replica of my old Textpattern site. There are some limitations with regards to theming of comment display and the comment form and a higher granularity when dealing with the main page contents would be nice to have, but it appears that the benefits easily outweigh these minor inconveniences.