oh noes!

The Linux graphics card market is a sorry place. Split into two, the integrated market enjoys great driver support. Intel, SiS, S3/VIA Unichrome, Trident - wonderful 2D support and fairly great 3D support as well.

The card market is a sorry place, however. ATi and Matrox ceased opensource driver development a few years ago, and since then the availability of decent drivers for modern cards is appauling. nVidia haven't provided opensource drivers since the Utah GLX project.

But ATi and nVidia have tried to redeem the situation: Bring in fglrx and nVidia unified, respectively. Closed source drivers.

But this isn't why I am writing. The nVidia driver works - mostly. They still deviate from the Tungsten Graphics DRI design by avoiding the GLX extension and implementing their own extension, and using a proprietary OpenGL library, which may or may not be derived from the Mesa source. All in all, the driver is trouble free, but non-opensource nature means most distributions won't ship the driver. A shame, but all is not lost. Sucks if you don't have an i386 or amd64 machine, however. There's just no driver for any other architecture.

fglrx, on the other hand, is not worthy of the label "work of art". The quoted supported X version is Xorg 6.8.2 - I know very few Linux users still using this old version. The release notes are littered with suggestions that newer Xorg versions are unstable with the driver. And my own experience confirms this.

I still haven't managed to use fglrx on a Radeon card that hasn't caused the machine to crash when returning to a text console or leaving the X server. And that's been going on for about four years - covering 8500, 9200, 9600, 9800, X300 and X850XT cards. Self-built kernels and distribution kernels, Debian, Fedora and Gentoo.

But that's not all. The driver is saturated with obscure options that affect the operation and cannot be changed without leaving the X server. The driver refuses to allow the Xv extension and 3D acceleration to work at the same time. Which, when you have to edit the configuration file and restart the X server to do so, is a nuisance. Especially when - you guess it - the machine crashes when the X server exits.

The Xorg driver is written in C++, and built with an old compiler (gcc 3.3, by my understanding) - you can find this out by looking at the module linkage - it uses libstdc++ v5. More old libraries to have installed. The kernel module still uses a fork of Dave Jones' agpgart driver (why not clean up the patches and submit to the kernel team?).

About a two years ago, I nearly cried in surprise when the X server started with both GLX and Xv enabled at the same time. Sadly it was a driver error - Xv worked just fine, but any GL applications ran at 3-4 FPS.

Today's experiments were no different. Instability - and a new feature! Using the Xorg ATi driver, everything works quietly. But enabling fglrx suddenly ramps up the fan speed - almost doubling my machine noise! The Xorg ATi driver, on the other hand, only ramps up the fan speed when the card is under load - notably 3D applications at work.

And this gem - the Xorg log reported that the card had only detected half the amount of Video RAM that the card is fitted with. So adding "VideoRAM 262144" to set the memory to the correct amount gave this hilarious log message:

(II) fglrx(0): Video RAM override, using 262144 kB instead of 262144 kB
(**) fglrx(0): VideoRAM: 131072 kByte, Type: DDR3

Really, it's time this situation was fixed. If Intel put one of their integrated graphics processors on a PCI card, I'd go out tomorrow and buy one. Then I'd take the X850XT in my machine and incinerate it. I've gone to bizarre lengths before to get opensource friendly hardware - purchased a motherboard that didn't support dual-core Athlon 64 processors just so I have an opensource friendly chipset (VIA, for those interested). Bought a PCI to miniPCI adapter and put an Intel ipw2915 card in my machine to get opensource 802.11g support. My machine is a harmony of friendly hardware - except the graphics card. I've even spent more on scanners, multimedia devices, printers - just to make sure I support products that work with Linux and other opensource operating systems.

I've heard that the XGI cards are getting opensource drivers. If this comes through I'll buy one without question. I don't care about the split-second performance differences between cards - I'll buy whatever works, and works well.

Seriously, AMD - sort ATi out. I had high hopes when you bought the company out last year. But you'll lose a customer to Intel when I buy my next machine unless this is rectified.

Footnote: Yes, I know the Xorg ATi r300 driver is coming along nicely. But it's still flaky in some areas - and not through their fault, either. Lack of specifications means driver authoring is still guesswork.

I guess this one is mostly my fault, really.

A few days ago I decided that rigorous enforcement of SpamAssassin on all of my server users was a bit drastic, so retired the configuration and retreated to the hazy reality of receiving close to 40 junk emails per hour.

Typically this grew dull very quickly, at which point I reached for a former mainstay in my mail sanity, procmail.

Past experience with procmail has taught me that it's really easy to lose a lot of mail very quickly. Particularly if something in the configuration file is so hideous that procmail objects in such a foul fashion that the underlying MTA bounces the mail. So after fighting to transform my nice, easy to understand exim filter rules into hideous lists of symbols and regular expressions, I was ready to whip through a test run to see how it all went.

Common sense at this point caused me to put locking in, since retrieving 600-700 messages, eating two processes for procmail and one process for SpamAssassin per delivery and pausing for 5-10 seconds per message whilst various RBLs are consulted. Hence the head filter read:

# spam checking with pamsassassin - filter, so it adds headers
:0fw: spamassassin.lock
* < 262144
|/usr/bin/spamassassin

Sensible, no? Well, it depends on how you look at it. Running fetchmail with a batch limit of 50 messages just to test the water proved that delivering 50 messages takes a hell of a long time if each message eats up to 10 seconds just to check if it is spam or not. Never the less, it'll take a few hours to clear down 600-700 messages at up to 10 seconds per message - and the locking is in place, so I was confident it would pound away on it's own accord.

What I didn't think of is that exim just might think that, since procmail has been spawned and is just hanging around waiting for it's turn to run, it is taking just a wee while to get it's job done. And it's eating up around 2,100 processes in the, err, process.

So after a while it said "that's just taking too damned long. I'll bounce the message. *punt*".

91 punts later and I finally notice that the process table is shrinking too quickly for these to be properly delivered and kill exim, procmail and any SpamAssassin processes left running.

Assessing the damage, I now have 15 mailing lists to check I don't get booted off of in the next fortnight (or whenever the bounce processor/list admin gets around to checking bounces).

There's no moral to this story. Just pity. I will now instruct fetchmail to deliver using procmail from now on and ignore exim entirely for local fetching.