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.

Debian version 0.9.91.4-1 of nspluginwrapper went into unstable today. Notable changes are:

• Install plugins into /usr/lib/nspluginwrapper/plugins, then symlink them into browser-specific paths. Namely:
  • /usr/lib/firefox/plugins
  • /usr/lib/iceweasel/plugins
  • /usr/lib/mozilla/plugins
  This closes bug #417288.
• Remove the symlinks when symbolic links in the above paths point to the plugin being removed.
• Remove ia64 from the architecture list - there's just no compiler available to build i386 binaries on ia64.
• Set --with-lib32 to /usr/lib32, because otherwise it's assumed to be /usr/lib (which is whatever the "native" architecture is).
• Set --with-lib64 to /usr/lib. Which makes sense if you read the previous bullet point.
• Remove config.sub and config.guess, because the package doesn't use autoconf/automake, and it's just not needed.

I consider the work on the symlinks to be "stable", although I question it's usefulness enough to send it upstream. Ideally, I hope that future Debian browser versions try to keep a single common plugin path. Until then I consider this a temporary measure.

In the meantime, I'm wracking my brains trying to think of some way I can package this for non-amd64 architectures. It would be really useful to see this on PowerPC systems, but the lack of gcc capable of building i386 binaries on anything other than i386 and amd64 means building a cross compiler, libc and Gtk+ libraries prior to the runtime build.

Anyway. Until I work that obstacle out, you amd64 users can enjoy the latest StrongBad E-Mail in Adobe Flash on your Debian boxes.

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.

I have been getting components for a PowerPC-based machine over the past week or so. This morning, the DVD drive turned up (it's convenient to have DVD writers in everything, and since they're about £30 these days it's not breaking the bank getting one). This morning, an LG GSA-H10N turned up. First thing that grabbed my attention was the list of requirements (here are the ridiculous ones):

• Requires a Pentium III 700MHz or greater, recommends a Pentium IV 2.4GHz and 512MB of memory.
• Video card with 128MB of memory.
• Hard disk with at least 20GB of free space.
• OS requirements: Windows 2000/XP and DirectX 9.0 or greater.

Most of them made me think "yeah, I guess if the drive is knocked into PIO mode it'll eat CPU like a bastard" and "Sure, I bet a load of people whinge that they can't make discs when they don't have enough space to write a UDF image before writing", but really - do you need an über graphics card with that much video/texture memory and DirectX 9 just to whack 4.5GB/9GB of data onto a disc?

A few places have reported that Apple's latest fruit-flavoured OS should hit the shelves this month. "Leopard" will be the latest in the MacOS X line.

Behind the scenes, the OS has a bitter flavour. You may remember the news that Apple have withdrawn the xnu source for x86 systems. Within the last fortnight, the OpenDarwin project has announced that it is shutting down.

Macworld attributed the closure of the x86 xnu source to pirates, but I get the feeling that this is merely idle speculation. Yes, MacOS has seen a fair bit of attention from crackers eager to see the OS run on vanilla x86/x86_64 hardware, but Apple has proven to be difficult with releasing the sources in the past. Prior to even the developer releases of MacOS X/x86, there were difficulties in getting Apple to release sources for the x86 counterpart, and even more troubles in getting it working. Apple's lack of effort in getting the sources out of the door are well documented on the various Darwin mailing lists.

Apple's withdrawl of xnu-x86 is more a show of apathy than anything else. Don't blame the pirates (and don't give them a halo) - MacOS X will never run cleanly on a vanilla system. Apple have made sure of that.

OpenDarwin closing down is a shame. The Apple release of Darwin is barely useful - OpenDarwin gave the distribution a 'ports' system for 3rd party Unix software and package management. That at least gave something useful to the project. I seriously doubt any upstream contributions would have made it into Apple's kernel distribution. Now there's much less chance of that happening.

So, Apple have taken all the source they need (from mach, FreeBSD, the countless number of base system packages, the gcc which Xcode and the whole OS is so hopelessly dependant on). They've thrown back a token of community participation. And now they're retreating quietly to count the dollars.

Expect to see more of their source withdrawn over the forthcoming months. At least, all of it that isn't GPL'd.