Attention Linux users: Enough is enough. It's gotten to the point where I can't keep fielding bug reports from people that need this LD_ASSUME_KERNEL nonsense to make their games work, and it's WAY past the point where I can ask middleware vendors to please rebuild their libraries on a Red Hat 6.0 box so they'll work everywhere. Try asking serious middleware companies that are just now experimenting with Linux with a straight face: "can you install a Linux distribution that's seven years out of date? Oh, and build this specific GCC from source, with this patch." The GCC problems have largely ironed themselves out with new versions, but glibc--which has to make some hard choices to solve some unique problems--has not. So please be aware that future titles, and future patches to existing titles will be linked against a newer glibc. What this means for you: if you're on a relatively modern distribution, you probably won't notice any difference, or perhaps your ArmyOps server won't freeze up on startup anymore. If you're on an older distribution, your games (including ones that previously worked) will probably stop working, and won't even start up. Chances are if you've installed your copy of GNU/Linux in the last few years, you'll be okay. If your distro is too old, consider upgrading it, doing a clean install of a newer version, or switching to something else entirely. My current target system is Ubuntu 5.10 (glibc 2.3.5, NPTL). I will, of course, strive to work on any reasonable distribution of GNU/Linux, as always, but that will give you a good idea of what you should be targetting for a compatible system. Most popular distros have the goods, and also allow you to cleanly upgrade your glibc install. I don't have a real test at this time, and unfortunately the only real metric will be "do games X, Y, and Z all run?" ...naturally, this is a fairly large collection of unknowns, versioned symbols, subtle dependencies, etc. It's entirely possible that the details will shift a little and a patch or two will be completely bogus as I try to get this right. I will not be doing seperate binaries for different glibc versions. If you don't like this, be sure to ask the glibc maintainers why most .EXEs released for Windows 95 still work on Windows Vista, more than a decade later, but that Loki game you paid for wouldn't even load next year. Frankly, I think this is a crappy situation, and in a perfect world, this would never happen. In this imperfect world, I'm praying I can squeeze another five years out of a modern glibc and not have to force these sort of upgrades on people. I recognize that the glibc people made consessions to aid backwards compatibility with ancient apps (the LD_ASSUME_KERNEL hack, for example), but we're still trying to make binaries that run everywhere, and thus far, that's meant shipping new code that's built like an ancient app. Hopefully someday, there will be some middle ground between these two mentalities. News on individual projects will be back here soon. --ryan.