Filesystems vs. brain damage in Linux applications -- why, oh why, can't it be better?

Look, I'm a fan of Linux. But nothing can excuse the stupid behavior of KDE applications under Kubuntu:

What you’re about to see is just a twenty-line snippet representing standard pathological behavior of a widely used KDE application that comes with Kubuntu. I'm at a loss of words, because what you're about to see repeats itself (I kid you not) at least a twenty thousand times:

access("/usr/share/icons/crystalproject/24x24/devices/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/24x24/filesystems/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/24x24/filesystems/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/24x24/mimetypes/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/24x24/mimetypes/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/actions/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/actions/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/apps/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/apps/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/devices/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/devices/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/filesystems/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/filesystems/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/icons/crystalproject/32x32/mimetypes/mail_todo.xpm", R_OK) = -1 ENOENT (No such file or directory)

Now, let me ask you: what kind of engineering is this? Oh, I'll just look for the icon named mail_todo of types XPM, SVG, SVGZ, PNG, JPG across thousands of directories and if I can't find it, I just won't draw it.

Modern desktop environments package all that shit up in a single icon cache and use mmap to quickly find it. Well, guess again, loser who invented that band-aid. I'm using a filesystem that doesn't support mmap. Now my filesystem has to consume inordinate amounts of CPU to find each one of those two hundred icons your application uses, because you couldn't find a better algorithm to find the motherfucking icon.

Oh, by the way, every time I delete an e-mail from KMail's listing, the entire process is repeated again. I guess I can safely omit the part where Kicker (the panel) and Kopete all do the same things for each icon that they display. Woops, I didn't omit it.

Just another tale of living in the bleeding edge of Linux computing.

In the interest of full disclosure: I'm using the CPU-heavy ZFS filesystem from Sun. I'm testing it because it offers unsurpassed reliability. Yes, it's CPU-heavy. Yes, it runs through FUSE. But that's not the point -- the point is that this wouldn't matter if KDE apps (and, I'm sure, many others as well) wouldn't suck so much to find a motherfucking icon. After the latest torvalds kernel recompile and another ZFS recompile for performance (which failed), I have gained quite a lot of performance: now KMail doesn't take 10 minutes to launch -- it only takes four. On a dual-core Xeon, with 1 GB RAM and 7200 RPM dual platters. Four motherfucking minutes. I now fully agree with Cox when he said userspace does stupid things.