X.Org Security Advisory For X11 Going Back To 1993

[johnc]

That's not quite true. It's kind of like the saying "if it ain't broke, don't fix it", where that's a very naiive and impractical motive (or lack thereof) in the technology world - if there is substantial room for improvement, you might as well consider it broke. While I respect the idea that X11 intends to remain backwards compatibility, anybody who actually demands such old obsoleted technologies to be continued are a burden to both users and developers. It's getting so bad that wayland's development became a necessity. It's kind of like how a year ago when the linux kernel decided to ditch the old i386 architecture - sure there MIGHT be some people out there who still use that architecture, but what kind of i386 system can effectively handle the linux 3.x kernel, and what does the linux 3.x kernel have to offer that i386 users would want/need (assuming whatever is necessary is even physically possible)? While X11 isn't anywhere near as complicated as the linux kernel, the latter point still stands - what hardware from 15+ years ago will have any use of the modern abilities of X11? Anybody who still wants these old features could just simply use an old version of X11. I'm a huge fan of backwards compatibility, but there IS a point where convenience becomes an ever increasing burden.

I'm not going to pretend I know how everything works in X11 and I'm not saying that X11 unquestionably should just ditch these old features. But another point to make is if X11 intends to keep backwards compatibility, every obsoleted feature that stays with X11 becomes one more thing for developers to maintain.

I don't disagree with you from the perspective of maintenance burden. I would just say that there is no practical impact on the side of user function. I just get the impression that sometimes people think that if all the "legacy cruft" was removed from [project X] that things would automatically perform better, use less RAM, provide a better user experience, etc. That isn't necessarily so... and typically not so at all in a mature project like Xorg.

[schmidtbag]

I don't disagree with you from the perspective of maintenance burden. I would just say that there is no practical impact on the side of user function. I just get the impression that sometimes people think that if all the "legacy cruft" was removed from [project X] that things would automatically perform better, use less RAM, provide a better user experience, etc. That isn't necessarily so... and typically not so at all in a mature project like Xorg.

That is true - on the user end, I'm sure there's very little to be affected by. I'm sure if ALL "legacy cruft" were removed then xorg might have a performance improvement in some way (even if just loading speeds), but I wouldn't find that significant enough. But the way legacy backward compatibility affects users is when certain technologies can't be used because it would break the legacy support, or, when workarounds must be made, which in turn negatively affects performance. So at a glance, support for 15+ year old extensions or libraries might not have any effect, but preserving their existence is a problem.

Think of it like AMD keeping their AM3 series alive through AM3+. If they just went with a brand new socket, a new chipset (without any intention of being backwards compatible), with triple channel memory support, the FX series of CPUs could have EASILY gained enough performance to go from "disappointing" to "adequate". FYI, I actually own an AM3+ CPU (I own an AM3 board that I've had since 2009 and wanted to get one last breath out of it).

[uid313]

Thats a marketing problem, uid. It came up in Daniel's or Kristin's talk a year or two ago. The reason for XLFD's and 'legacy' crap like that is because when you say "I am an X11 compliant server" their attitude is you can't lie about that. So if you say "I follow X11" you HAVE TO FOLLOW X11's spec. And X11's spec says "XLFD's must be sorted. Core Rendering must be available. Fonts must be available to be handled server side." And a crap ton of other things.

This is one of the points I tried to hit on, but that people didn't understand at the time, when I wrote The Wayland Situation last year or whenever it was I wrote that:

Sure, we could make an X12 (the docs are already there) and rip out all of that stuff, but that creates a problem. There are people out there, beyond Xorg, who care about "X" and would want to get a say in "X12." It means we might not GET the clean slate we want / need for one or a dozen different reasons (backwards compatibility being one of them, maybe.) By going creating "Wayland" there's no emotional / mental / etc baggage of "X." Its not "X12" its not even "X" its something COMPLETELY different, its not -claiming- to be X12, its not claiming to be X, it is its own thing.

If someone ELSE, some other company, or some other group THEN wants to come and along and create X12 as the "True" successor to "X11" and they want to go around to all the Unix vendors (for example) and say "We're making THE TRUE Successor to X11-- X12! Give us your input" And are convinced that the "X" style protocol IS the right way to do things and that the Wayland protocol is the WRONG way to do things, they can. And they can market it as "The Next Generation Of X", "X12" And whatever else they want, assuming they got the copyright from Xorg. Because WE (The Linux community) isn't in the X world anymore. We're in the Wayland world. We're doing our own thing that suits OUR needs in OUR way.

But X12 would mean a whole new protocol written from the bottom up. It would be a huge undertaking.
I think we should just throw out all old stuff, and be like "Ok, this is not X11" and make it a reduced subset of X11 and call it X11-Lite or something.

If it's not used anymore then it's not bothering anybody.

It makes it slower to compile, harder to refactor, more prone to crashes and bugs and security vulnerabilities, and makes it more difficult for new developers to pickup X.Org and join in.

[BradN]

I think there's very little performance improvement to be had from cruft removal - CPUs are so fast now and memory so large compared to even a few years ago, that X just isn't a performance bottleneck. Cleaning it all up might save a megabyte on a livecd. Who cares.

That said, if X is to be continued as a display technology, there may be developer benefits to cleaning up the codebase. If X is not going to be continued a long time, it's probably best to do the minimal changes until it becomes irrelevant. There are better places to spend the effort.

I just worry that network transparency will be lost or made difficult to use in newer display server systems - especially with regard to LTSP as it's used here daily to make old hardware into dumb terminals into the same system. Makes things a lot simpler to administer when everything is really running on one machine.

[mrugiero]

use less RAM

That's true if the feature is in the core binary. Probably not a lot less, though.

[alanc]

Yeah, someone need to run AdressSanitizer, Valgrind or some static code analysis tool over the code base.

We have - Valgrind, Coverity, Parfait, clang, and others - and have fixed bugs they've found. No static analyzer finds all possible bugs, and all produce false positives to weed out, but we keep on trying. Sometimes, a fresh set of eyeballs, like this case and the advisory a few months ago, is the best hope for finding bugs that all the other tools have missed.

[LinuxGamer]

This is way we have Wayland....

[Daktyl198]

That is true - on the user end, I'm sure there's very little to be affected by. I'm sure if ALL "legacy cruft" were removed then xorg might have a performance improvement in some way (even if just loading speeds), but I wouldn't find that significant enough. But the way legacy backward compatibility affects users is when certain technologies can't be used because it would break the legacy support, or, when workarounds must be made, which in turn negatively affects performance. So at a glance, support for 15+ year old extensions or libraries might not have any effect, but preserving their existence is a problem.

On this video: http://mirror.linux.org.au/linux.con...land_and_X.ogv
The guy mentions that opening Gedit, a tiny program, spends over 500ms just waiting on the X.org server because it's Core functions/old extensions are trying to do things that the window manager will end up doing anyway...
There were some tests where the X server caused over 1.2 seconds of blocking...

Bring in Wayland/Mir/etc, that number gets cut down to 0ms and Gedit loads an entire half a second faster on average, which is awesome. X11 is making Linux seem slower than it really is, and that's always a bad thing...

Not to mention that 500ms of round trips to X.Org server to open a single Gedit window, let alone all the other applications a normal user runs, is probably not doing a lot of good for battery life

[smitty3268]

But X12 would mean a whole new protocol written from the bottom up. It would be a huge undertaking.
I think we should just throw out all old stuff, and be like "Ok, this is not X11" and make it a reduced subset of X11 and call it X11-Lite or something.

Says who? The whole point of incrementing the version number is to point out that backwards compatibility no longer applies. Throwing out the old parts of X11 (and presumably standardizing some of the current extensions) is exactly what would cause them to issue a new X12. I'm not sure why you'd want to call it anything else, but even if you did that's just marketing fluff. Whatever you call it, what it is would be X12.

The reason no one is interested in that is because it would be a huge undertaking to get everyone using X11 together and agree on exactly what should be thrown out versus what should remain. And no one cares enough about the modern parts of X to do that - the only real point to keeping X around is the backwards compatibility it provides to everyone.

[curaga]

Not to mention that 500ms of round trips to X.Org server to open a single Gedit window, let alone all the other applications a normal user runs, is probably not doing a lot of good for battery life

WTF is gedit doing? None of the apps I use take that long to launch _total_, not just X server portions.