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

Richard Brown rbrown1445 at gmail.com
Sun Feb 28 20:13:14 PST 2010


Alan Coopersmith wrote:
> Corbin Simpson wrote:
>   
>> Admittedly, I'm kind of young, but I had to go Google all the other
>> extensions to even get a hint of what they do. That's probably not a
>> good sign. :3
>>     
>
> You will undoubtedly not be the only X developer who is younger than some
> of this code.   Even with everything that's been dumped, X.Org still has
> a lot of 20-25 year old code left in it, and a lot of that is unlikely to
> ever go away.
>
> You can complain about the server extensions going away, but any portable,
> well written client always had to check if they were present and do something
> sane if they weren't - only in recent history has the world coalesced to just
> a few X server implementations, now that most of the proprietary variants of
> the days of the Unix wars have died out.    (Really, it's mainly just the
> X.Org implementation (as Xorg, Xwin, Xquartz or kdrive) on almost all Unix-like
> systems with a desktop these days, and a few others on other systems, like the
> commercial options for native X servers on Microsoft Windows.)
>
> On the client side we've pretty much preserved API & ABI compatibility, even
> when that required major gyrations for the XCB effort - while we encouarage
> migration to the new XCB libraries, it will be a couple decades before libX11
> fades away.
>
>   
I do not expect xlib to ever go away. There is so much written for it, 
its sort of pointless to refactor apps "because we can". If one makes a 
new app, XCB may be a good choice, when it is mature. I am not sure what 
benefits XCB has however. It could be as well, the way things often go, 
someone will forget some needed feature in XCB and Xlib may end up being 
a better choice in some situations. Ive often seen things like that 
happen. Case in point ., i upgraded t KDE 4.0. The new Konsole does not 
take the escape codes for setting the title bar with program name/path 
name i have sent by tcsh precmd and postcmd. I deleted KDE 4 and went 
back to KDE 3. Someone didnt understand the importance of this and didnt 
include this. KDE 4 for me was a downgrade, it actually regressed.

An age of code is no indicator of its quality. Old code can be better in 
cases. Consider most modern applications such as Firefox which are 
bloated memory hogs compared to older software. Code quality seems to  
have decline rather than improve.

As far as the extensions. I understand if the code in them was a 
security hazard, i can see why they would not be wanted to be included 
in the default compiles. And as well, some with broken code, with 
features duplicated elsewhere and with not many apps which use them, it 
may not be a good investment of time to try to fix them, considering 
there is more valuable uses of time resources.






More information about the xorg mailing list