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

[Alan Coopersmith]

Richard Brown wrote:
> I would be interested in the rationale to disable extensions. "This
> isn't needed anymore" is not good enough. Assume that there is someone
> still using the extension, somewhere, an older program that needs it.
> Perhaps, if the extension required rewriting of thousands of lines of
> code to keep it working, that might be a good reason to disable it. But
> dropping support for these things "because we can" or because "we didnt
> like how it looked there", didnt seem like a good idea.

We don't have people running around checking all the extensions for "Best
if used by" dates and chucking the old ones, and it's more than just flipping
a switch to enable or disable these.   Many were deleted because they didn't
keep up with changes in the rest of the X server or would require too much
work to be made to work with them.

Every extension we keep alive has multiple costs:

 - it's another vector for security issues, since by definition, an X11
   extension is more protocol to parse/handle - if you look at the recent X
   security issues, many were in individual extensions:
	http://www.x.org/wiki/Development/Security

 - it's another set of operations to analyze, classify, and add permission
   checks to for the frameworks adding higher security levels, such as
   SELinux & Solaris Trusted Extensions.

 - it's more code to change & test whenever we make improvements to the core
   server or related areas of functionality, and if there are no known users,
   how do we test we haven't broken them?

 - it's more code loaded into the system when it's running, and with some
   extensions either into common code paths or requiring the common code
   paths to be more complex to allow for it, with the associated performance
   penalties.

> Xprint: This allows printing to a postscript file. Seems immensely
> useful to me as it allows X itself to be used as a printer API. Why was
> this removed? Is there any major code problem that would have to be fixed?

Xprint was never part of the core Xorg server, but a separate Xprt server.
Changes to the shared code kept breaking Xprint in different ways, and the
requirements Xprint placed on the core server got in the way of other changes.

Unlike the others, Xprint wasn't just deleted - it was simply moved into
a separate code tree, where it would no longer get broken by shared changes
and those who wanted to use it could continue to support it.   No vendors
that I'm aware of have chosen to ship it, but the code is still made available
from X.Org to those who want it.  You should even be able to build it yourself,
though I haven't tried in quite a while myself.

> Xtrap, TOG-CUP, Xfree86-misc, XeVIE, EVI, MIT-Sundry-Nonstandard. Again,
> some  programs may need it. Any code problems that would have to be
> fixed, again, wht are the technical problems, are these broken, do they
> require major work?

Do you even know what most of those do?   What program did you have that
required MIT-Sundry-Nonstandard to enable compatibility with one specific
X11R3 bug, and why didn't you fix it to work with the standard specification
in the 20 years since X11R4 came out and warned that behavior was a bug and
that it was deprecated and would not be supported forever?

Do you still run many systems in 8-bit-only graphics to need the colormap
management provided by TOG-CUP?   Did you ever have a graphics card report
additional useful information from EVI that it doesn't get now via GLX calls?

> XeVIE seemed very recent. Why was this removed? Is there really huge
> amounts of broken code there? Xtrap allows capturing of user events? Why
> remove such functionality? Again, does it contain broken code?

The input devices subsystems underwent major overhauls recently with the
work for input device hotplugging, XInput extension 2.0, and MPX, and at
least XEvIE was left non-working and would need large amounts of work to
make working again.   That work wasn't done because no one came forward
and said they needed it badly enough to make the work happen.  (I have
actually been surprised by that for XEvIE - we went through all the work
to add it because it was supposed to be crucial for accessibility software
needed for all of the OS vendors to meet the US government Sec. 508
& ADA requirements, and similar requirements of EU and other governments,
yet I've not heard that the open source desktop accessibility has been
damaged by XEvIE's sudden demise.)

Xtrap was an obsolete solution that was replaced in X11R6.0 by the XTest
and Record extensions - you've had over 15 years to move your software
forward before the deletion, that's hardly a quick turnover.   (The
obsoletion notice is so old, it tells you to contact engineers at DEC
with questions:
http://www.x.org/releases/X11R7.5/doc/man/man1/xtrap.1.html#toc6 )

Like other major open source efforts that form core pieces of the OS
(very much like the Linux kernel), a majority of the development work
is done by people paid by corporations with customers, and those
corporations & customers can influence what work gets done.   In X's
case, these corporations right now are mainly the distro/OS vendors
(Red Hat, Novell, Canonical, & Sun), the hardware vendors (Intel,
AMD/ATi, Nvidia, and Nokia), and vendors of related software/services
(VMWare, Collabora).   We're open to getting more contributions from
direct end users as well, they've just been more from individual end
users there in recent years.

If your business relies on functionality, you can pay for it - just as
you proposed to pay Microsoft to provide you functionality - either via
your support contracts with your distro provider, paying consultants to
work on needed features, or paying your own employees to do the work.
Like many things, you get what you pay for, and when you assume open
source is free, you only get what others are willing to spend either
their time or money on.

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Oracle Solaris Platform Engineering: X Window System