Finger info for email@example.com...
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.
When this .plan was written: 2005-12-30 05:47:30
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.