The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Valve’s Left4Dead: DirectX Curse

Valve has dropped DirectX 8 support for new games. My wallet is now closed. Go in peace.

Valve Software has released their latest game, Left4Dead.  This is a zombie thriller game and I’d like to give it a try.  I love Valve games and I love zombies, so this should be my favorite game of the year, right?

Well I won’t find out, possibly for years to come.  I play Valve’s games under  Linux (unsupported) via WINE.  WINE’s DirectX support is pretty solid through DirectX 8 and I can play Team Fortress 2, Portal, Counter-Strike: Source, HL2 + Episodes, etc.  They run just fine on my system and I have fun.

As of Left4Dead, Valve has dropped DirectX 8 support.  I look at the game on the WINE AppDB and the word is it runs fine, but slow as a dog.  So I don’t buy it.

This is an example of sales prevention.  Valve already chooses not to support Linux as a gaming platform; their choice.  But now they are cutting off the ability to play their new games via WINE.  Also their choice, but a choice which means that I won’t be giving them my money until I read on the WINE AppDB that things have improved.

And for the record I’ve bought pretty much every Valve game since Half-Life.  I would love to continue to do so.

Viva la Revolucion!

AMD/ATI and nVidia aren’t getting another cent until they recognize and reform their gross errors toward the linux community.

I’m building a new computer, but it won’t have a graphics card. It’s going to have integrated Intel graphics. Therefore it’s going to have an Intel processor. AMD is losing my business because they didn’t perform up to what I consider to be reasonable expectations. I don’t think nVidia performs all that admirably either.

It’s not merely the spirit of linux, but the development model as well, that requires openness. It makes no damn sense to be throttled by a piece of hardware that is essential to the system because its manufacturer refuses to work with the community.

Furnishing documentation is great, but that’s something that should have been done all along. The pace and scope with which many of the internals of a healthy, modern linux system changes demands flexibility that the two major graphics processor manufacturers are apparently unwilling to provide.

Off with their heads. I’ll be posting soon about how the intel integrated graphics perform, and I’m planning to have a rolling three month deadline for evaluating my discrete graphics card options. If at the end of March, June, etc. there is a victor amongst AMD/ATI and nVidia I’ll actually buy a card for the system. Otherwise I’ll continue to use the integrated graphics. So be it.


Some quirks of the nullidentd documentation and how to get random identd.

Just a quick note about the package nullidentd. This is an Ident Daemon that purports to be as light as possible. In the man page you see mention that (and I quote — under OPTIONS):

nullidentd takes only one optional argument, the username to answer with. If this is omitted, nullidentd will reply with the username "foobar". If the username is RANDOM, a random string is generated.

And under USAGE:

nullidentd is typically invoked from inetd. The following is a typical inetd.conf example:
auth stream tcp nowait nobody /usr/sbin/nullidentd nullidentd

What you don’t see is the actual, proper use of adding a specified string or the magic RANDOM string.

The way? Add -u. Fairly straightforward, but undocumented. Even running nullidentd --help lists the usage as “nullidentd [uid].”

auth stream tcp nowait nobody /usr/sbin/nullidentd -u RANDOM

But once you figure it out it runs quite fine, no harm no foul. Still, it ought to announce proper syntax.

(For a quick and easy test, this works like a charm.)