TTimo's blog

There has been a bit of unrest among Linux gamers about id's commitment to releasing Linux versions of the games we make.

I don't want to be rehashing old subjects, but I'll offer a few thoughts:

Fundamentally nothing has changed with our policy regarding Linux games. Trying to shoehorn the ZeniMax acquisition into this is pointless, as they are true to their word of focusing on the business and letting the studio focus on the games.

Linux players represent about 5% of the QuakeLive population, which is in line with the company's previous releases. Nothing new there, releasing Linux versions has always been a matter of higher code quality, good software architecture, and technical interest for the platform.

We never commit to releasing Linux versions for any of our titles, at least not until we are reasonably sure that we have the resources to put into it. In the past few years I am pretty much the only one who has been involved in our Linux versions, and most of that work was done in my spare time. It worked out because I spent significant time working on each of those projects to get them shipped (Doom3, Quake4, ETQW), and making sure we had working Linux builds was a natural part of that process.

It is unlikely the new Wolfenstein title is going to get a native Linux release. None of it was done in house, and I had no involvement in the project. QuakeLive offers a lot of challenges and eats away everything else right now.

As far as idTech 5 (the Rage engine), it runs on PS3 and Mac already. Setting up idTech 5 to run on those platforms early on in our development cycle was a direct result of carrying Linux/Mac support in idTech 4 beforehand. It is likely i will be involved with idTech 5 in the near future, I'll be damned if we don't find the time to get Linux builds done.

It's like a blog post, except it went to the QuakeLive forums:

http://www.quakelive.com/forum/showthread.php?t=32243

How do we put out a new QuakeLive build in roughly one hour, spanning 3 platforms, 2 source control systems? With buildbot of course!

Full Monty is the name of our do-it-all builder, thanks to triggerable schedulers we now push one button to get pretty much everything done:

Quakelive-buildbot-waterfall

Also I heard it's QuakeCon next week. If you're attending, don't be a stranger. I will be either at the tournament area or at the BYOC noc.

Guido Van Rossum relayed this very insightful talk about the innards of Python's global interpreter lock by David Beazley (blip.tv link).

My position with regards to the GIL is pretty standard: like everyone else I'd rather do without and benefit from true threading concurrency on multicore hardware, but I understand it's a hard problem to solve, and therefore it's either here to stay, or getting rid of it would mean fairly drastic changes to the underlying interpreter. The only non-GIL python platform I'm aware of is Jython (in a nutshell, the Python language running on the Java Virtual Machine).

Beazley however showed that it's worse than everyone thinks.

How do Stackless python's Microthreads compare? Stackless is bound by the GIL also, but it's Microthreads are not done at OS level (see Green Threads). Understandably those should not be affected by GIL battles.

We have a lot of code using the Twisted framework that fall into the 'mix of CPU bound and I/O bound threads' that Beazley describes. We typically offload blocking I/O with a deferToThread call (to memcached, to a database, to another XMLRPC, whatever). All our hardware is multicore (typically 8 cores per system), and we run multiple twisted instances to achieve scalability. Now I'm wondering if we assign each twisted + child threads to their own CPU, are we going to see better performance because we'll be avoiding GIL battles?

I always have a few side projects, things I write and maintained on my spare time. Earlier this year I started using the duplicity backup system, which I augmented with my own dupinanny script.

I got around to cleaning it up and documenting it a bit after the duplicity website started linking to me in their user contributions section.

Just relaying this cool bit from Ryan "icculus" Gordon: http://icculus.org/news/news.php?id=4467

GG icculus for pushing that through. Prey is based on tech 4 / doom3 engine. I had a great time playing it.

One of my favorite pieces of python software has hit the symbolic 1.0 release last week. Congratulations to the scons developers for such a powerful and innovative build system. I use it on pretty much all my projects.

QuakeCon is next week. Between that and QuakeLive I have been way too busy to make posts on here (I'm doing that one while Oracle completes installation on a system we're bringing to the convention). Too bad, I would have had some good material about all the stuff we've been running into.

Wanted to relay a post on another blog that just saved my life: Installing Oracle Database 11g release 1 on Debian amd64