Problems with X.org and incompatibilities with in-house software

[Alan Cox]

> disabled, removed extensions. How many of these are disabled as a result 
> of actual broken code, vs, how many are disabled because, "we don't like 
> how it looks"?

Most are disabled because they don't work (and often havent worked for
ages, or have been disabled by distributions by default for years and
nobody noticed), others are just not shipped by default and probably work
(eg Xprint still gets some love now and again).

There are other things to think about - eg X extensions that are old and
unmaintained often pre-date the world of the 'leet hacker dude' and the
coding isn't neccessarily as robust as it should be. Enabling such things
by default is exposing people to a risk with no economic justification.

Really the only way to maintain an X extension is to have someone who
uses it and has a true self interest in keeping it working, whether
because they work for a vendor whose customer pays good money for a
system that delivers the feature, or because they need it in-house.

The extensions are still there in the history of the codebase. It just
needs someone who needs that extension to check it out, rebuild test and
debug it. If it's cheaper to maintain it than port the code using it then
it makes sense for those who can save money to maintain it or pay someone
to do so, if not then it's probably time to go. Rational economic
behaviour ought to resolve such questions (ok given perfect information I
admit)

Some of the ancient video drivers would certainly be more expensive to
port than to simply replace the few remaining cards for example.

Alan