This weekend, Terah and I drove up to Nebraska to visit Cliff and Marilyn. We have never met them before, or even talked to them on the phone. We just know them from blogs -- Marty (Cliff's nephew) introduced us to them. We really had a blast -- quite a fun weekend, and we met lots of interesting Morrows. I supose there's always something unexpected that happens when you visit people you've never met. With this visit, it was singing in a Baptist choir. Terah said, "Well, we've never even been to a Baptist service in English, but sure, sounds like fun!" I think it took Cliff about 2 seconds to decide we should both sing in the choir once he realized we're in our church choir back in Kansas. I suppose that's risk you run when you go and visit a choir director. Off course it's all fun with Cliff. We really enjoyed it, and Cliff & Marilyn's daughter did a fantastic job on the piano. When we first arrived at Cliff & Marilyn's place, the first thing Terah noticed was that Marilyn had set out a giant Hershey's kiss and a Dr. Pepper for her! This was great. Terah's still talking about it, and is very impressed with a solid piece of chocolate that large. At dinner on Saturday, I think Cliff and Terah were having a bit of a competition to see who could have the driest sense of humor and the most sarcasm. Maybe it was just a little Kansas bias, but I think Terah gave him quite the run for his money, and even edged him out by a bit. Terah was also something of a celebrity around the Morrows, in one way anyway. It seems that, one way or another, almost everyone had heard about her carefully-planned underwear rotation scheme. And had gotten quite a good chuckle about it -- as well they should. Cliff asked us to bring some photos of our home and family with us. I think he might be regretting that now. I downloaded as many as I could fit onto a laptop -- about 3000 -- to give us plenty to look at. Of course, we didn't look at 3000 photos, but you just never know what might come up. Cliff and Marilyn did a wonderful job of not falling asleep anyway. We also got to see their photos, and they have some spectacular ones. Marilyn enjoys stereo photography and has some incredible stereo photos. I especially enjoyed the pictures of Germany. Marty's parents were also around this weekend and were full of interesting stories. His mom makes a wonderful cheese spread. I think I need to have a putty knife to spread it on nice and thick. It's the sort of cheese spread that's good enough to layer on about twice as thick as the cracker. The cracker is just sort of a cheese delivery device. I kept hearing that Marty had told the Morrows all about me. They all claimed that Marty said only good things about me. But we all know how the Morrows like to tell stories. So I made sure to get a few about Marty before we left, just in case. Don't worry, they're all good, Marty. After church Sunday, there was a carry-in meal. We knew about this in advance, and Terah brought some of her famous chocolate-cherry cookies along from Kansas. Cliff later admitted to stealing "no more than one" during the sermon. But he couldn't quite say it with a straight face. Terah's cookies were a hit, though -- it seemed that lots of people were trying to figure out who brought them. A few enterprising people pulled out the lid from the pan, but of course seeing Terah's name there didn't really help all that much. I think she promised recipes to about half a dozen people. We went geocaching Sunday afternoon. Cliff, Marilyn, and their grandson came along. We found the Summit Lake #1 cache with their grandson -- it was his first time geocaching, and I think he enjoyed it. Well, that was a long post. I'll probably remember more to write about later in the week, and stay tuned for photos!

Sorry. Couldn't resist. Following on from my previous look at XTech proposals, I wanted to comment on one of the hot topics contributed to the Applications track. While this track will push all the buttons (we've got Rails, RSS, web services, content management and more) one of the really striking things was the number of proposals on the topic of DITA. If you're not a regular in the tech docs world, then DITA is probably at best just another acronym you've seen whizzing by. DITA stands for the Darwin Information Typing Architecture, and it's a new document format making waves in the world of technical documentation. From a casual documenter's point of view, the obvious question is probably "what does this mean for DocBook?" Does the mass of enthusiasm mean DocBook's on its way out? In short, no. DocBook and DITA compared  DITA and DocBook are actually rather different beasts. DocBook is a sound DTD for writing technical books and articles, with the structure that such forms imply. DITA is focused on creating modular technical documents, with the intent for easy reuse across varied delivery methods. It's intended for topic-oriented documentation, which may be chopped about and rearranged within a variety of contexts and for a variety of display devices. DITA is a DTD and a set of rules for writing online contextual documentation such as software help files. There's a lot more to it than I'll write here, but here a few more differences between DocBook and DITA:

• DocBook is hierarchical, DITA separates content from context allowing multiple architectures of information
• DocBook is a fixed element and attribute set, DITA is extensible, allowing the definition of custom information types
• DocBook is much more mature than DITA, with a variety of solid tool support options. DITA's the new kid on the block.
• DocBook is well documented, DITA's documentation is still in the early stages.

There's a real need for something like DITA, which addresses concerns that didn't really exist in the same way when DocBook first emerged at O'Reilly in the early 1990s. DITA and open source projects I'm looking forward to learning more about DITA, but one thing that immediately strikes me about it is its relevance to some of the documentation problems faced by open source projects. DocBook has never quite clicked as a documentation format for some collaboratively maintained projects, probably because the inevitable book-like nature of the result necessitates sole or restricted authorship, and heavy editing. Instead one of the increasingly popular ways for providing documentation has been the wiki. You guessed it, a topic-based architecture. What wikis seem to lack, however, is any way of providing a thought-out progression through the content. In essence, the information architecture side of things. Had I been able to attend every session from XTech last year, I'd have heard Paul Prescod talk about what DITA and wikis have in common.
There may be a downside, however. DITA looks impressively engineered, but it may be too industrial-strength for many. My initial investigations suggests that while there's emergent commercial tool support, there's not much going on in the open source field (although there is the DITA Open Toolkit, which looks to have been produced in close association with OASIS technical committee now in charge of DITA.)
As DocBook guru Norm Walsh observes, DocBook can play in this space too. With additions such as those Norm proposes, DocBook could play host to DITA's major features. (Norm writes "With a couple of hours of hacking, I've implemented on top of DocBook the four key features of DITA that I could identify.") Though these possibilities are intriguing, I think that, for open source projects, things need to get simpler rather than harder. More reading:

• DITA--Getting Started (XTech 2005 proceedings)
• To DITA or not to DITA? (Palimpsest blog)
• Cover Pages: Darwin Information Typing Architecture (Robin Cover)
• DITA FAQ (OASIS)
• Going DITA (O'Reilly weblogs)

More and more cars are including audio systems that interface with the iPod (home audio systems too). Meanwhile, people like me using open platforms are stuck with crappy FM transmitters with terrible sound quality and non-integrated control systems (e.g., I have to turn on the transmitter, turn on the music player, turn on the radio, and remember to turn off the transmitter and pause the music player when I turn off my car or run down the battery and lose my place if I’m listening to a podcast). The non-Apple digital music player contingent should come up with some sort of USB-based docking standard before it’s too late (if it isn’t already).

We all know a long time that CVS sucks; the author of that article (in 2002) listed his main gripes with CVS: missing file renaming and not being able to remove directories. So far so I agree completly, these two things make CVS annoying to use, and everyone, even casual CVS users, will stumble upon these mis(sing) features. At that point, both subversion and what later became GNU Arch (to my knowledge, the first Free Software, distributed RCS) were in pre-1.0 versions, but becoming ready for use by the braver souls. While subversion has certainly fixed the renaming and directory problems, subversion has a fundamental shortcoming, making it an obstacle for FOSS to reach its full potential: it restrains the developer that may come along and want to experiment with the code. And no, it is not enough that the developer can checkout the latest code and submit a patch to the mailing list. This might work on projects where such patches are both trivial and quickly fed into the repository. But for more serious work, you will want to keep track of your work for yourself, either so you can review and alter the steps (changesets) done later on, or since you have to submit it piecemeal anyway. It could also happen that another, non-privileged developer wants to work on a thing that needs your modifications, before your patch has been approved and committed, or even before you are fully done with polishing it up fully for inclusion into the mainline. This other developer may also be just interested in your work and like to test it, and while doing so, he finds a little bug and wants to fix it. All this does happen in the real world, even on a large scale, e.g. with Linux distributions, and it’s called branching. The problem with non-distributed RCSs is: you need write access to the repository to create a branch. This is both true in CVS and subversion (although in CVS, branching makes little sense, as merging is a real PITA). To get write access, you have to go through whatever hurdles there may be in that particuliar project until you are deemed worthy of commit access. It is of course clear why it has to be that way: would the developers of that project grant everyone and their dog commit access, they would soon be busy with undoing the damage done by commits that don’t meet quality (or other) criteria, and not having any time left for hacking. This is not a problem with a distributed RCS, however - you simply have (typically) one person maintaining the “official” version of the source code, typically that’s the same person that rolls release tarballs. For example with Linux, it is Linus (for the development branch). That person can have their own repository, where everyone else only has read access, and selectively pulls changesets (patches) from repositories of peer developers. I hope I was able to made clear why using non-distributed RCS for a FOSS project can restrain the possibilities, limiting indivual freedom. So, if you believe in freedom (and software freedom in particuliar), consider giving a distributed RCS of your choice a try. I can heartily recommend darcs, (altough I’m not sure how it scales to bigger projects) but there are several alternatives out there. And in case you want to migrate an existing project, or give your users and developers a choice of RCS, you can use tailor to migrate your old repository, or even establish a two-way gateway between two RCS.

Well, probably not, but it's a nice catchy headline. <grin> What I do think is that there is a pile of unexplored functionality hiding in mapping more things to regular filesystems. FUSE has lowered the barrier to providing access to non-traditional filesystem places -- there's versioned filesystems, SFTP (of the SSH variety) filesystems, filesystems into tarballs and zip files, and so on. Implementing a FUSE filesystem is as simple as whipping up a few callback methods in your favourite programming language (the native bindings are, of course, in C, but there's FUSE libraries for Python, definitely, and I'm fairly sure I've seen Perl and Ruby ones as well) to implement things like stat, open, read, and so on. Then you run the program as per normal and suddenly you can read and write things you've *never* read or written before... Beyond the mundane extensions of reality listed above, there's whole new vistas of relatively unexplored territory for filesystem-like operations, which are (a) waiting to be explored, and (b) much easier to implement due to the fun of FUSE. For example, SQL databases are very hierarchical in nature. Databases contain tables which contain rows which contain fields which contain values. If you can track your foreign keys, some of those values can be symlinks/directories to other records, or a directory of records for join tables. Sure, it's horribly inefficient to update whole tables by for i in *; do echo 12 > $i/fieldname; done, but at the very least it could be an interesting way of viewing data, and with some judicious caching (depending on use-case) the performance could probably be made half-sensible. A more refined version of this is the idea of reporting into pseudo-flatfiles. Imagine if you could open a file and have a spreadsheet of all of your data. With FUSE, it's possible. A killer one that my boss Dave Kempe came up with is a search filesystem -- you create a directory in this FUSE filesystem that is named after a search query -- perhaps "2005 financial". A Google Desktop-style search then results every time you enter that directory, and all matching files are available for your viewing pleasure. I understand that gmail works something like this "virtual folders with search" model, and I know that applications like Evolution and Liferea already have some sort of virtual folders type of thing, but we don't think that anyone's written something like this for filesystems. Considering that you can run a FUSE filesystem over Samba, you can easily have a company-wide document search-and-retrieval with persistent (and shared) queries, which is probably a pretty valuable thing. Even all of these, though, are relatively tame ideas when weighed against the myriad of things that my tiny mind can't even dream up. I don't think people have put much thought into how far a filesystem really can go, because before FUSE, if you wanted to write a filesystem, you were pretty much restricted to kernel-mode programming -- a very limited (and dangerous) world for your average application programmer.

Thanks to David Pashley I have discovered workrave, a tool with the aim to help you prevent RSI. I find it really useful, though in the beginning it sometimes feels annoying, for example when you're in the middle of doing something. After two days of using it, I'm slowly changing my habbit of clicking on the "postpone" button in those cases, as this a.) leads to another interrupt soon and b.) means even more finger movements (to click on the button and getting back to work).

Taking the breaks as adviced (I've only changed the defaults slightly) is really relaxing in my experience and even if I'm in the middle of doing something, I don't loose my concentration if I pause for 25 seconds and relax. I do loose more of my concentration if I do use the postpone or skip button :-)

And it's also not only helping preventing RSI but also back pains (which are related in my opinion / experience as one of the core causes for RSI is bad posture which also leads to back pains) and those breaks also help not to forget to eat and drink, which sometimes happens during hacking sessions.

So I'm a happy workrave user now, even though I'm still annoyed by bug 348845 - which I would happily fix myself if the sources for the images were available...

Which brings me to the topic of content being unsuitable for "the" workplace, because it offends people. I am offended, but not really surprised, how many people (and workplaces) seem to be offended by mentioning lesbians, but not for sensible reasons but because of the sexual reference. Heck, even Microsofts CEO seems to happily get along with gays, lesbians, bisexuals and transgenders even though Microsoft as an american company has to fear those (christian) talibans, which is not the case for Debian.

And you really shouldn't blame anybody else except yourself if you visit non-work related URLs during your working hours.

Fred Wilson: “I will not buy music that I cannot remove the DRM from.” I agree wholeheartedly, though the strategy I use is the one Fred dismisses in the first paragraph, namely burning the music to CD and ripping it back, sans DRM, to MP3 format. Yes, it’s a pain, but it beats having to jump through all the digital hoops at some indeterminate point in the future when all I want to do is queue up a song I’ve legitimately purchased and have probably forgotten where I bought the thing, let alone what magic pixie dust I need to decode it. Sure, the MP3 format has issues too, but at least I know my music will play anywhere. (Since I’m on the subject, I’m looking for some sort of a virtual CD burner, which the operating system thinks is a CD burner but which is actually a piece of software that converts the tracks it “burns” to MP3 format. Anyone know if such a beast exists? That would certainly do wonders to curtail my contribution to the world’s coaster supply.) In practice, DRM isn’t as much as a problem for me as it seems to be for other people. Personally speaking, I don’t want to be in the music storage business—I’d much rather stream music on demand from some digital jukebox in the sky, which is why I’ve been a Rhapsody customer since 2003. (Greg Papadopoulos sums up my thinking pretty well exactly here: “I’ll bet that we will look back of this era of quasi-networking and wince, ‘How did we ever live that way?’ And the idea of wanting to carry all of your content with you will seem both old-fashioned and rather ridiculous.”) In my case, DRM is normally a non-issue—I simply route around it. Rhapsody has come a long way since I first started using it in 2003: They added a Rhapsody To Go service, which more or less solves the “disconnected operation” problem (though I still tangle with DRM issues from time to time if I go for too many days untethered), and they finally embraced the web, though the current web offering leaves much to be desired—the Linux plugin still doesn’t support Firefox 1.5 nearly two months after its release, the web interface has huge gaps compared to the jukebox software (you can’t access your music library on the web, among other things?!), and they don’t seem to be taking advantage of the new web platform at all (where, oh where, are the RSS feeds of my favorites, recommendations, etc, so I can mash them up with other stuff?). At the end of the day, I suspect the “economic boycott” James Governor calls for is the right way to fix the DRM problem. For my part, I’m voting with my wallet by supporting the model I want to win out in the end (that your music library will live on the web, not on your PC or in your pocket) and by buying music, in those rare cases when I do want to manage my own music library rather than letting someone else do it for me, from legitimate music services but opting out of the silos the platform providers are trying to build around me as a byproduct. Above all, I resist the temptation to climb into the big, beautiful lockbox Apple is building for us. As Clayton Christensen recently told BusinessWeek, I’m firmly convinced open standards will win out in the end:

Look at any industry — not just computers and MP3 players. You also see it in aircrafts and software, and medical devices, and over and over. During the early stages of an industry, when the functionality and reliability of a product isn’t yet adequate to meet customer’s needs, a proprietary solution is almost always the right solution — because it allows you to knit all the pieces together in an optimized way. But once the technology matures and becomes good enough, industry standards emerge. That leads to the standardization of interfaces, which lets companies specialize on pieces of the overall system, and the product becomes modular. At that point, the competitive advantage of the early leader dissipates, and the ability to make money migrates to whoever controls the performance-defining subsystem.

I don’t know about the rest of you, but that day can’t arrive soon enough for me.

The controversy over Apple's "photocast" extensions, and the strangeness of their iTunes RSS enhancements, is illustrative of the transition that software companies need to make as they become web-enabled. It's no longer enough to make your applications and hardware pretty and functional, but the guts that other people get to see must look good too. This is one reason that people prefer RELAX NG over XML Schema, for instance. Where markup is concerned, it turns out that the excuse "only computers will read it, and we'll provide tools to generate it" doesn't cut it. The web's had a view-source mentality since it started, and the aesthetics of markup matter a great deal. They matter not only because they're nice for geeks to look at, but also because well-structured and standards-compliant markup is simply more interoperable. The end user experience is ultimately improved. Microsoft now gets this, I think. It's not hard--you just need to have your engineers exposed to the web, not hidden in some blinkered bunker. It's a shame that Apple doesn't yet understand that the aesthetics of markup count. Even their new web tool, iWeb, lacks somewhat in this department. Apple do so well in the rest of the computing experience, these poor web efforts really stand out. It was rather sad to read the disappointment OS X-hugging web developers felt with the iPhoto RSS use. Will Apple "get" the web better someday? I hope so, because we'll all benefit.

My vet has written two books on cats, is nominated for Intervet's Vet of the year and is also a very interesting person to talk with: Santiago G. Caraballo.

Ugly pics of scars and post-surgery cats to be uploaded later.

I just came back from the vet. I left Vi and Emacs there and will pick them up after work, as today they will be spayed and neutered (450 EUR total). I am all shaky inside.
My little cats! (Well, not so little, as Emacs started acting like if she was in heat only a few hours before I had to take a plane for my Holidays, so I guess she is not so little anymore, nor is Vi, who seemed completely fascinated by her new behavior. Anyway, my vet knew this would happen one month in advance, when we were arranging an appointment for the surgery that will be performed today).

Good luck, my babies!

Note to sheba_finesse and self: Clean fish tanks weekly! They somehow manage to get really dirty if you don't.

I should also actually add pH neutraliser and water conditioner to the tank after doing a water change. I have managed to lose 3 guppies, 2 platties and a Clown Loach in the last 3 days. Expensive lesson. However, now I get to pick new fish, so I bought 5 Black Skirt Tetras.

Now that's over with, I can move onto other stuff.

Jean and I have bought a new bed, a new washing machine, a new dryer and a new fridge. Now we just need to wait for Radio Rentals to pick up the old stuff, and I'll be happier.

Techy stuff:
I finally gave in to Jordi and agreed to move Debian ALSA stuff into SVN. I'm seeing if subversion can act like less of a bitch than the last time I used it, in which case, I may actually re-evaluate my opion of it.

My Sparc has been deciding to run out of of memory. Then I discovered that spamassassin 3.0 is a dirty memory whore, and was chewing up 90Mb of RAM. I have moved spamd to a machine to more memory (the Sparc has an extremly small swap partition due to stupidity on my part), and not installed 3.0, and purged my Bayes database, so spamd should be quick and not suck ~ 100Mb of memory. As an aside, does anyone know how to stop spamassassin doing Bayes?

Roland Fails at homework, and Wouter gets detention for copying Rolands homework. Any given spam detection method is workaroundable, but uribl happens to be one the hardest ones so far.

What Roland is missing, is that spamassassin 3.0:s uribl module checks against the domain names too. So if cheap-placebo-meds.biz points to zombie servers at unblacklisted ip addressess, It will still get a score if cheap-placebo-meds.biz is already blacklisted as a domain.

They could still drop the domain from the url entirely, and just add an zombie IP, but that would be terribly unreliable. The zombie-hosted sites I have seen usually had 10-15 round-robin addressess, of which 2-3 actually responded.

Another escalation spammers could do is to buy (more) throwaway domains. But there is already work to detect fresh/throway domains and list them, since typically spammer domains are less than one month old.

But if zombie hosted spammer sites come a big problem, the uribl module can check against dial-up blacklists as well, of course at the great annoyance of everyone who has web site on their dial-up and advertisize it to their friends via email...

What spammers will probably start doing, is setting up (more) gateway/redirection sites on various free webspace sites like geocities, or start obfuscating their addressess (isn't that poetic justice: "please go to cheap dash meds 123 dot biz". In any case, their links will look more suspicous than before, which hopefully will damage their sales.

In other news, excuse me, it's nice that GNU has locales and standard ways of doing things, but does /bin/true really need all this??

After talking with some LinuxTag guys about which kind of talks are still missing for the upcoming LinuxTag, I submitted another proposal for a still only roughly sketched talk: KISS – Keep it simple and stupid, also on the web.

KISS – “Keep it simple and stupid” is an old and successful principle in the Unix world: Small and simple programs, doing only one thing, but they’re doing perfect, fast and reliable. This principle can also work on the web and make webservers or surf terminals out of already discharged computers.

I planned to show “simple” (or at least “simple to use”) tools like Blosxom or the Website Meta Language, a more slim webserver than Apache (e.g. fefe’s fnord or one of the ACME webservers thttpd, mini_httpd or micro_httpd), slim web-browsers (e.g. like Dillo, Opera, glinks, ViewML or Minimo) and one or more Linux distributions optimized for low end PCs. While thinking about low end PCs, usually the following distributions come to my mind: DeLi Linux, fli4l and Debian Woody. But none of them seems to fit for my talk as perfectly as I would like:

• DeLi Linux is no bad distribution, since it’s designed especially for 386 to Pentium I, but I have some strong disagreements with the maintainer of DeLi Linux, since he sees a very small package list as necessary requirement for a distribution for old PCs. He states that distributions for old PCs “don’t have that many harddisk space” (beyond other, more realistic arguments — but it seemed to be his main argument) while I see a rich package diversity as an quality criteria. (One of the reasons, why I like Debian and dislike Ubuntu.) So I’m not sure if I should present a very raped DeLi Linux to the audience, just to make it fit my needs, although I’m quite curious about his upcoming 0.7 release with the low end, KHTML based ViewML webbrowser. (Apart from me seeing PHP5 and KDE as a big nono on old PCs…)
• Although I still like Debian Woody very much (you know that old story… ;-), it is just too old for making a talk about how to turn old PCs into being usable again. Sarge would be fine, but it was suggested to showcase an easy and fast way to get something ready to run, and I can’t give the auditors a list of all the Debian packages with low resource consumption and therefore usable on low end PCs.
• I haven’t used it yet, but fli4l seems to be very good distribution to turn an old PC into a ISDN or DSL router, even without harddisk. The last time I had a look at fli4l, it used an Apache as (optional) webserver, which wouldn’t fit into my scheme, since I would like to show an alternative to Apache. But as I found out today the recently released version 3.0 of fli4l uses the already mentioned ACME mini_httpd. Cool! They’re on the right way! ;-) Unfortunately it only seems to be used for serving information pages about the fli4l status and not as common webserver. (Please correct me, if this is wrong! I would appreciate it, if I’m wrong at this point. :-)

Since I first read about viewml on the DeLi Linux page, I looked for Debian packages of viewml today. apt-cache search hasn’t found anything on Woody or Sarge and packages.debian.org is still down, so I used Google. I found out, that there at least was a viewml package in Debian since at least 2001, so I expect, it just didn’t make it to stable. But I also found this interesting page on a webserver called www.ubuntulite.org. Ubuntu Lite? That sounds very interesting, since I see Ubuntu not as the baddest idea (expect for it’s horribly resource hunger and only offering one package per application by default ;-), but having an Ubuntu derivative prepackaged for low end PCs and with several webbrowsers instead of only Epiphany (and probably Firefox, don’t they?) would be perfect for my purpose. So I’m currently downloading an Ubuntu Lite ISO and will give it a try on one of my Pentium MMX boxes. Unfortunately it doesn’t seem to support Pentium I or AMD K5 since Ubuntu itself only supports i686 and upwards. :-/ But this also means, that it’s no occasion for my Pentium I Compaq LTE 5100 (which I probably will name pony), but currently, after Bartosz’ recent post on Planet Debian, it looks like Debian GNU/kFreeBSD could also be an interesting OS, since it fits all requirements perfectly: Free, Modern, Exotic and all conveniences of Debian. ;-)

Now Playing: Jefferson Starship — We Built This City

As mentioned earlier, I wanted to package the KDE videoblog client kitty for Debian. I finally found the time to really do it, and the package has entered Debian unstable a few days ago. The first bug has already been reported (sigh), but I'm working on it. kitty got even mentioned in Debian Weekly News (w00t!)

After finally setting up my old PC (Does PC still mean personal computer or has it completely mutated into politically correct yet?) I noticed that its mainboard was broken. (Well, actually I didn't. I thought that stuff on the capacitors was just some kind of dust or so. Alex kindly informed me that it was infact their content ... which somewhat impairs their functional capability.) The machine still booted up alright and worked without problems, but every now and then it suddenly went out without any sign of warning. Very annoying. This resulted in the machine serving as an occasional table for another few weeks. Until last weekend, when I finally went and got some new hardware for it. It now has a new mainboard (my first one with DDR RAM, welcome in the new millennium!) and a silent CPU cooler. The good: The computer is now finally usable and I cannot hear the CPU fan anymore. The bad: I now know that the fan of my PSU is just as loud, as are the hard discs ...
Thus another hardware shopping expedition is in order!
... as soon as my finances recovered from that last one ...