The State of X.Org
An anonymous reader writes "Phoronix has up an article looking at the release of X Server 1.4.1. This maintenance release for X.Org, which the open-source operating systems depend upon for living in a graphically rich world, comes more than 200 days late and it doesn't even clear the BugZilla release blocker bug. A further indication of problems is that the next major release of X.Org was scheduled to be released in February... then May... and now it's missing with no sign of when a release will occur. There are still more than three dozen outstanding bugs. Also, the forthcoming release (X.Org 7.4) will ship with a slimmer set of features than what was initially planned."
Is there anything else out there? Why is there such a lack of interest in X.org, when so many other projects depend on it. Most of the big projects have been moving quite quickly, making a lot of headway in the past couple of years. What's holding x.org back?
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
From the article:
I've been using Ubuntu for 4 years now and it's pretty much shielded me from any lack of quality in the releases. Probably if I spent more (unnecessary) time under the hood it would expose issues but I've been living in a very blind 'trust Ubuntu' atmosphere where things pretty much just work (ok, lets not mention the recent key generation problem :)
In short, I guess the only people that might find the quality lacking are the developers and maintainers, and anyone specifically in the graphics industry? Not your average desktop user..? Or am I being naive?
Free Playstation 3, Wii and XBox 360The problem with slashdot is that most of its users were bullied and stuffed into lockers as kids!
Xwindows is one of those nice things that just work. With such dependabilty it is all that important the we get our instant gratification with superficial features like transparent windows? The X.org group made great strides after the fork from XFree86. Can we really expect them to keep that pace?
UNIX/Linux Consulting
Aside from Keith Packard and Dave Airlie, and maybe one or two others, how many paid full-time X developers are there? Watching the mailing list, it seems like there's a couple of volunteers, some people who submit the occasional patch but otherwise work on Qt, or GNOME or whatever, and then the core listed above. I think there just isn't enough manpower right now and the distros, instead of fixing that problem, just maintain their own patchsets and do a "good enough" job to make X work smoothly for their releases, and leave it at that. Clearly, nobody wants to make X a priority and it shows. The Wiki is almost never up to date, it's nigh on impossible to build a working X system from git, even with the couple of half-arsed build scripts available from the mailing list (for my part, I have never been able to get it to build completely, and not for lack of trying or ability). The mailing list is full of academic arguments over color specs and other pointless things, or people asking for help. There used to be a lot of discussion on how to improve X and also, how to get things done. That no longer happens. What the distros and Linux companies need to do is get more people working directly on X and get serious about making X a serious project. It's not just some option piece of software that nobody has to care about. It's only one of the most important aspects of desktop Linux. And it just makes no sense to me that no distros are really spearheading X development. If they don't take the time to make this an issue, X will continue to atrophy, further limiting Linux's potential in the market.
Heh. "At Phoronix", my ass.
Once I badly needed one particular bug (proper video init on laptop resume) fixed . Asked about probable fix timeframe/schedule of this bug on lkml , most responses were in form "it's free, we're doing it in our spare time, so don't ask when" . Then I tried to determine if any amount of money can help, asked developers if they can pricetag bugfix/patch and how to pay them - there was no definite answer at all. Children , playing in their sandpit and bearing no responsibility for their code at all, unmotivated and unmotivateable by anything but most basic urges .
The code's low quality is the fault of the community, too. Who do you think wrote that complex code?
If you're that savvy, why not spend a little of your time patching that existing code to factor out some of the unnecessary complexity? Instead, you're spending your time yelling at me on Slashdot, which does precisely nothing.
--
make install -not war
Maybe not at the mercy of a company, but a team of core developers that don't want to do it any more. Now tell me which is worse?
And don't try and throw the "oh we can do it ourselves crap". The issue here is maybe the casual developer has contributed are you saying that this casual developer now has to work on it full time so the project can move forward?
Not likely to happen.
One of the problems facing OSS is the people who move it forward are the ones who live, breath and feel passionately about the project (99% of the time the core developers), take away those people away and the project usually dies no matter how popular it is.
Have you ever tried to contribute to X.org? Bugs with fully working patches where users and other developers say "this needs to be committed" sit opened and untouched by Daniel Stone. Then when some subproject (i.e. drivers) want to get a new person on board, it takes an average of 4 months for that person to be given commit access. (my project had opened 3 bugs, how Daniel Stone wanted to handle new accounts, and we included all the info and it took 4 months for each person to be given access). It's tough to keep developers involved with delays like that. The problem is there's only very few people in charge who are doing 0 delegation and have a lot on their plate.
Perhaps X should be replaced, not improved.
and get actual work done fast!
Network transparency is *the* feature of X. And what stops you - Macs come with an X Server as well.
But then: only X applications can grind my MacPro to a halt. Maybe you can't get network transparency and performance at the same time.
Martin
"Hannibal's plans never work right. They just work." Amy/A-Team
You are correct that X wire protocol is ugly. However this is NOT a reason to abandon network transparency. If you removed network transparency you would still have an ugly protocol, just communicated in shared memory instead. But if instead you fixed the protocol while keeping network transparency, you would have the good protocol PLUS network transparency.
The fact that you even remotely consider communicating larger objects than drawing commands to the server, such as widgets, is proof that you have never even thought seriously about how these things are programmed. It will not work, it would be unbelievably complex. In X this is where the horror of the ICCCM window manager hints and protocol come from (basically it is an attempt to put a complex "window+frame" object over the api). Windows and OSX do not do this at all, all communication that leaves the app's local address space is pretty low-level drawing commands.
Client-side fonts are done by sending the bitmaps of the fonts over. It is a huge win, because no longer is there a "font object" that is attempted to be communicated. It is exactly the OPPOSITE of your proposal.
How many people on here have the capacity to actually make a useful contribution to X.org? Leave aside the organizational complaints about delays in getting patches accepted or commit bits set.
Your "provocative" posts are probably counterproductive if your intent is to get X.org some more community contribution. Legitimate complaints met with 'fix it yourself' are what push people to OSX.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
I'm constantly amazed by people trumpeting the same old line about how network transparency support makes X slow. It stopped being true before some of them were old enough to read and write.
Even if all traffic is forced though loopback TCP/IP by setting DISPLAY to '127.0.0.1:0' (or similar) it still performs quite fine. The network transparency isn't the slowdown.
The slowdown is the toolkits and apps, which miserably fail to consider the influence of network latencies. They issue requests and wait for them to finish before going on to something else. They issue lots of unnecessary requests, do things in inefficient ways, and love lobbing pixels around when higher level drawing instructions would do. Let's not even talk about the themes and styles used by current toolkits and apps (I just got a ~30x speedup out of thunderbird on LTSP by changing the theme!).
*argh*
>>Perhaps if someone were being paid to develop it this wouldn't have happened.
Yes, you are right, if someone had been paying, X.org would not exist.
Because X.org DOES exist and it's far more encompassing of varied hardware than any commercial project, we can conclude that it is NOT the work of one commercial entity. It's a cinch no one company could have pulled it off, it is something that could only (and did only) come into existence the way it did.
Thanks for making that point.
I don't know the meaning of the word 'don't' - J
I don't know about Mac, but, I wouldn't be surprised if the display management code for Windows was at least as quirky that of X.Org.
Basically, developing window managers is hard. Any sort of clean display manager implementation will be severely hampered by the fact that it'll completely break backwards compatibility for almost every application. Even Windows has this problem; look at the incompatibilities and window drawing quirks present in XP and Vista.
Apple got around the issue by saying, "We don't care about backwards compatibility," and providing a virtual machine for those who really needed the older OS to make their apps run.
We all know what to do, but we don't know how to get re-elected once we have done it