People constantly say "Python is fast enough! If it's too slow, just throw hardware at the problem! GUI applications spend all their time waiting for user input anyway! And you can rewrite performance-critical sections in C!"

So why is it that, running Fedora on my netbook, I can tell -- with 99% accuracy -- which programs are written in C/C++ and which are written in Python?

There's a simple test. If, when I launch the program, nothing happens for up to a minute, then it's probably written in Python. If, when I click on a button in the program, it becomes completely unresponsive for up to five minutes before anything happens, then it's definitely written in Python.

Today's culprit is the SELinux Administration program. Unbelievably, mind-blowingly slow and unresponsive. This is not a good user experience. I don't care how much programmer time was saved by writing it in Python, or how beautiful the code is, or even how well it performed on the developer's high-end desktop monster -- what I care about is how much of my time is being wasted by twiddling my thumbs while this under-performing, over-rated slug of a language chugs away doing simple things inefficiently.

It's 2010. The future of computing is small, low-powered devices, optimised for portability and endurance rather than raw execution speed. I can't throw hardware at this problem. If Fedora wants to be widespread, it simply can't afford to go on like this, getting slower and slower as more and more core functionality is replaced with fundamentally slow code. It's time to start thinking about execution efficiency again, and -- in the absence of a high-performance Python interpreter -- that means Python is simply not an appropriate language for implementing core OS functionality like system configuration tools. If rewriting bottlenecks in C is good enough, then someone needs to start doing that, because right now they clearly aren't.

All I want to do is synchronise my Google calendar with my computer, so I can read and add entries even when I don't have an internet connection. That shouldn't be so hard, should it?

Apparently it is.

Google's own Google Gears is read-only. Useless.

The only Linux calendar client that Google supports is Mozilla Sunbird. Yeah, the discontinued one. It does do CalDAV, but it's online-only; if I'm offline, the only way to get my calendar is to use the scary "EXPERIMENTAL!!!111" cache option, and that's read-only and buggy to boot. Useless.

Evolution supports CalDAV. Unfortunately, Evolution wants to take over my entire computer. I had to put in a fake email account before it would even let me look at the calendar options. The UI is frankly horrible. There is apparently no way to get rid of the irrelevant "task" pane; I can shrink it to take up no space, but then when I resize the window, all the extra space is given back to the task pane instead of to the calendar itself. It also insists on trying to add all new entries to the non-deletable "Personal" calendar, even though I have hidden this and set my Google calendar to be the default calendar. I'm not surprised it's useless, of course; all the development effort will be going into supporting Microsoft Exchange, in line with Novell's usual policy of preferring Microsoft lock-in over open standards.

KDE's calendar program looks quite nice. It supports all kinds of synchronisation options. Er... that is, apart from the single useful standard, CalDAV. The absence of which, people have been complaining about literally for years. Apparently they're waiting for opensync (aka Godot; see below). Or possibly something called Akonadi (Godot's little brother). It looks like someone else has recently got sick of waiting and started actually writing some code to fix this gaping hole, which is a pleasant surprise, but their project doesn't actually work yet. Good luck to them anyway.

So, what's left? There's a promising project called opensync that claims to be able to synchronise any sort of calendar I like. This sounds like exactly what I'm looking for! Oh, wait: the last stable release is ancient; the last couple of years have been spent completely breaking the whole API; the Google Calendar plugin is unmaintained and is broken even in the stable version; there is no CalDAV support at all. The current status report labels everything as either alpha-quality or totally broken. Good stuff. Enjoy gazing at your navels, opensync developers! I'm so glad you decided to rearchitect your project instead of making it useful.

Which leaves only one option: GCalDaemon. I refuse to touch this with a bargepole. Not because it's unmaintained, not even because it's written in Java, but because its developers seem to have been totally clueless, and I will not trust their code on my computer. They expect me to put user-specific configuration files under /usr/local/sbin? Um... no.

Never mind, I'll write my own. Sigh.

So, GIMP. I have this image with lots of layers. I want to create a new image that contains three of them, another that contains a different three, and so on. Are you going to be helpful?

In every other graphics package under the sun, this is a trivial thing to do. You select the layers you want, and copy them into a new image. In GIMP? You select the layers you want, and... no, wait, you can't, because GIMP only lets you select one layer at a time. Let me repeat that, because I couldn't believe it at first either, but it's true. GIMP can only have one active layer at a time. You can only operate on one layer at a time. You cannot select two layers and apply a filter to both at once.[1]

There is one limited capability it does have: you can "link" layers. This isn't the same as the grouping capability that every other graphics package provides - "linking" in GIMP simply means that you have set a flag on a layer. When you move a layer that has the linking flag set, all the other layers with the linking flag move as well. (If you then want to move a different set of layers, you have to unlink every layer in the first set, then link the second set.) It's the clunkiest interface I've ever seen to this kind of feature. And it only seems to work for moving - not for scaling, not for filters, not for copy-and-paste.

It seems the only provided way to do what I want -- to create a new image containing several layers from the old image -- is to copy one layer, paste it into the new image, select the second layer, copy, paste, select the third layer, copy, paste...

(I take a deep breath and count to 10 at this point. I am determined not to conclude that GIMP sucks until I have finished giving it a proper chance.)

Okay. I'm a programmer. GIMP is programmable. So I give myself a crash course in script-fu, which is comfortingly similar to Emacs LISP,[2] and an hour or so later[3] I have 50 lines of Scheme that, when invoked, create a new image containing the layers from the old image that had the linking flag set. I am now able to do what I wanted in a relatively quick and easy way.[4]

But I'm a programmer. Most people who work with graphics are not programmers. Tell the average designer that you're suggesting she should use a package that will only do what she needs after she's spent a good hour hacking away at Scheme code, and she'll laugh in your face.

Why on earth is basic functionality like this not built in? How is an average artist supposed to be productive when they can't even operate on multiple layers at once without writing a program to do it?

Maybe I should ask these questions on a GIMP mailing list. It's been a while since anyone's told me I'm a dumbass.

[1] Apparently there are plugins that do provide a limited capability to apply filters to more than one layer at a time, but I'm blowed if I can find one.
[2] But only vaguely, it turns out. This is Free Software; I guess consistency is too much to hope for.
[3] The actual programming only took about five minutes. The remainder of the time was mostly spent trying to find some script-fu documentation, which basically doesn't exist. No, GIMP fans, tutorials are not documentation.
[4] Script-fu is an example of a thing I like about GIMP. Now I've figured out its quirks and how to make the most of the very limited documentation, I have to admit it's already saved me as much time as I lost learning it. Shame the REPL sucks, but there are some promising-looking emacs packages that might fix that.

I've hated GIMP for a long time, after some dreadful user experiences in the 1.x days. Recently I got tired of using VMware for all my graphics editing work, however, and as for once I have some stuff to do that doesn't require CMYK support, I decided it really was time to give free software another chance. Krita turned out to suck even worse than GIMP 1.x, so I gritted my teeth and installed the hated program once more.

I fired it up and decided to open a PNG file. I was presented with an informative dialog box: "The image has an embedded color profile: sRGB built-in. Convert the image to the RGB working profile (sRGB built-in)?"

Okay, so at least it finally has colour management support. That's good. But why is it prompting me to convert when the image profile and the working profile are apparently identical? What exactly does this decision imply? Being somewhat confused, I decided to click on the nice friendly-looking "Help" button.

Oops, looks like I forgot to install the help package. (Why does Ubuntu do this? If I'm installing an application, installing the help files too should be the default action.) So I fixed that and tried again. This time my web browser opened with the GIMP manual. So, what does it say on this subject?

"Eeek! There is missing help", screamed GIMP. "Sorry, but a help item is missing for the function you're looking for. Feel free to join us and fill the gap by writing documentation for the GIMP." It also suggests that I try looking in the online version of the help instead, and provides a handy link. Oops, no, it's a broken link.

This is not the stuff of which positive user impressions are made.

(Thanks to Google I did eventually find some documentation for the dialog box in question, which didn't actually tell me why I was being prompted to convert sRGB to sRGB, but did at least convince me it was safe to click "Convert".)

Next time: either "Mom, why can't I select multiple layers?", or "Manage your own damn windows!", depending on what annoys me most in the meantime.