Finger info for

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.