Slashdot Log In
The State of X.Org
Posted by
kdawson
on Wed Jun 11, 2008 07:47 AM
from the marks-the-spot dept.
from the marks-the-spot dept.
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."
Related Stories
Submission: The Sorry State Of X.Org? by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Anything else out there? (Score:5, Interesting)
Re:Anything else out there? (Score:5, Informative)
Parent
Re:Anything else out there? (Score:5, Interesting)
On the one hand we have things like GNOME and KDE, Firefox, Blender, etc. etc. - software that the user knows by name and interacts with directly. People happily join such projects and contribute code to them.
On the other hand you have software that the typical user might not not even know exists, like the Linux kernel. However, for geeks the kernel is perhaps the pinnacle of programming, and furthermore by lucky coincidence (or unhappy, if you are GNU) the name of the kernel has become synonymous with the entire OS, making it high-profile just like the more obvious software projects mentioned in the previous paragraph.
Whereas the X server is somewhere in the middle. It isn't well known, even geeks might not know exactly what it does (i.e., where the separation is between X, the window manager, and so forth), and for some reason it lacks the 'coolness' factor of the Linux kernel.
All of this is unjustified, and a shame. Perhaps more stories on Slashdot like this one will raise awareness? Maybe we should also motivate people, by e.g. telling them that hacking X is even harder than hacking the kernel
Parent
Re:Anything else out there? (Score:5, Informative)
Then, once you have decided to work on it and have fully absorbed X11 protocol into your being, you basically need a vmware license in order to develop. It's almost as hard to try out the changes you made as it is for kernel developers... slightly easier, especially for debugging, but you still need to either shut down everything you are doing to run a new build or have multiple development systems.
So basically it is a really step hill to overcome just to start developing X. Perhaps steeper since the kernel at least has excellent, 'simple', modular code to work with.
Parent
Re:Anything else out there? (Score:5, Interesting)
Parent
Re:Anything else out there? (Score:5, Insightful)
My personal bet is that X is overly complicated.
E.g. it takes 20-30 minutes to start doing something with Linux kernel. Entry bar is set low - many people like to participate. Needless to mention that to compile (properly configured) Linux kernel (with subset of drivers and features you really need) only few minutes. There are piles and piles of documentation and forums where you can find anything.
E.g. KDE + Qt. To compile KDE - you might need days. Or just grab precompiled binary packages. But after that you can in 5 minutes create something useful and interesting. Documentation is near perfect and complete. Also reading source code is quite easy, since most of the code is human readable.
But X is different beast. Even compiling it is challenge on itself. There is literally no documentation on its innards. There is no "Hello World" for X. There are bunch of example modules which you need to spend hours after hours to only understand where they plug into the all X mess.
I'd say main X problem is its strive to be cool and sit on all chairs. I'd say they need to scale down the project and split it into smaller independent pieces. Forget large releases (installing apt-get would help! kidding). The smaller sub-projects would have more chances attracting people, since (at least theoretically) then entry barrier would be lower.
Parent
Re:Anything else out there? (Score:5, Funny)
Parent
Re:Anything else out there? (Score:5, Informative)
Parent
Re:Anything else out there? (Score:5, Insightful)
Parent
Re:Anything else out there? (Score:5, Insightful)
Parent
Re:Anything else out there? (Score:5, Insightful)
Parent
Re:Anything else out there? (Score:5, Funny)
Parent
Re:Anything else out there? (Score:5, Funny)
Parent
Re:Anything else out there? (Score:5, Funny)
Parent
Re:Anything else out there? (Score:5, Funny)
We should revive XFree86. To start, we should generate a list of features for the next release. We'll spread some rumors about what we're doing, let the world see how hard we're working on it.
This should get some attention from
Now for phase II. About this time next year we announce a release date, delay it a few times, then release it about two years from now. Make it a big deal. Major release. Get everybody talking about it.
For the release we'll drop all of the major new features on the list. We'll fix a bug or two, something major like a spelling error in a log report. Of course, we'll add a few new bugs. We could drop support for some hardware. For new features we could change a few things in the conf file. Instead of "Section" you now have to use "Block". We could totally change the format of the ModeLine to something totally crazy (crazier?)
If this follows the corporate model we have today it should drive major innovation and more frequent releases from X.Org, though our XFree86 project would unfortunately take away most of X.Org's market share.
Open source projects would probably earn the respect of more businesses and government agencies if it would just follow these common sense models from the corporate world.
Parent
Re:Anything else out there? (Score:5, Informative)
Developers where complaining about xfree86 for years before the fork, When the license changed it was just enough to push the fork. X.org began a long boring process of breaking X into smaller modules which will accelerate overall development. The problem is that process is still on going, and will take a few more years before any major upgrades can take place.
Think about the Mozilla project. They spent years cleaning out the core codebase and upgrading the core gecko engine from Netscape before they even had a decent beta. X.org is doing the same to something far larger, and uglier.
Parent
Re:Anything else out there? (Score:5, Interesting)
Parent
Re:Anything else out there? (Score:5, Informative)
[...]
For "desktop linux," I don't see why the system isn't reworked to run off of a frame-buffer and scrap all the X crap -- still keep X for running networked apps.
X11 already provides desktop Linux with you need to run high performance graphics.
Parent
Re:Anything else out there? (Score:5, Insightful)
The GUI framework on the Mac is Cocoa. The equivalent of Cocoa is Gnome (or KDE). The underlying display server, the equivalent of X11, is Quartz.
it appears to be managed in frame buffer
But it isn't. OS X has the same client/server display architecture as a Gnome desktop.
with custom rom that makes sure you never see bios info -- just pretty pictures.
What you see on OS X is that the boot loader quickly throws up a gray screen to keep you from seeing the boot loader text; the text itself is still there. If you like, you can boot OS X completely in text mode, just like a Linux system.
the removal of large swaths of abstraction make it load and "talk" faster.
The OS X display server has at least as many layers of abstraction as X11. It is not intrinsically faster than X11 (if anything, it's slower). Mostly what you perceive as speed on OS X is massive amounts of backing store.
the use of pdf rendering
OS X doesn't really use PDF rendering.
and enforcing policy rather than just providing tools means that things like cut and paste work from app to app, every app.
I own several Macs. The notion that "cut and paste work from app to app, every app" is laughable, and Apple couldn't enforce that if they tried.
Furthermore, if anything, policy is determined by the GUI framework, not the display server.
That is the sort of thing that X fails on for the casual or home user.
Whatever problems you think the Linux desktop may have, they have nothing to do with X11; consistency and policy is determined by the desktop environment, not the display server.
Parent
Re:Anything else out there? (Score:5, Interesting)
Parent
Re:Anything else out there? (Score:5, Funny)
The X server should be mostly scrapped and rewritten in Java. Java is a language that is suited for managing information like that, while still being high-performance (enough). The server could be rewritten in C++, but C++ is messy and is a complicated and archaic language at this point anyway.
Take a look at for instance weirdx [jcraft.com] which basically one person did. It handles most of the core functions of X and plenty fast (of course it is incomplete since it is one person's hobby). Or see Sun's Project Looking Glass, an opengl X server written in Java -- that was also written in one guy's spare time. With more development on these they could be real competitors to X.org while being more approachable, and I'll bet faster than the C code.
Parent
Re:Anything else out there? (Score:5, Insightful)
Yes, it was - hence rapid development things like mpx, xrandr, xrender, composite xinput 2.0 and so forth. Have people really forgotten so fast that a couple of years ago linux
Really, the
Emacs' release schedule recently slipped too - but it was because they're merging ECB and window groups into Emacs 23, not because emacs devel has stopped!
Parent
Re:Anything else out there? (Score:5, Informative)
Parent
Re:Anything else out there? (Score:5, Insightful)
Parent
Re:Anything else out there? (Score:5, Interesting)
We're using X as our windowing system because it's what we have, and we need it. But I don't think anybody (or not many people) really *believe* in it.
That is to say, I doubt anybody takes a look at it and says "this is it! This is the way we should do Windowing!" And so the followup, "...and if it this thing worked, then it'd be more awesome."
What people actually say when they start looking at it looks more like this.
"Okay! X.org is a good project! I think maybe I'll contribute my time to it! Hold on...what is this? Why does it have all these features that nobody cares about? Why the nonstandard build system? What's with all the crazy legacy code? This thing is way too complex for me to spend my time on, and what I learn won't transfer to any other work. I'll pick something else."
Parent
Re:Anything else out there? (Score:5, Interesting)
I've tried to help the project two years ago, I did dome work on input hotplugging and while not much of the code I wrote finally made it to the upstream (Daniel Stone, the man behind the input subsystem, finally decided for a different solution than what I was thinking about - maybe that was a good decision, I'm not the one to judge), I could experience myself how difficult developing X is. Besides skills and experience, you need to be able to keep track of such a big structure mentally, all the time. Not every programmer can do that, even skilled and experienced.
And, no, you can't always abstract everything out and make a nice, clean structure for the code to adhere to. Maybe the X code could be a bit easier to modify, but just a bit. Trying to force that, you would end up with an Xserver counterpart of GNU Hurd, if you know what I mean...
Parent
Re:Anything else out there? (Score:5, Informative)
I'd say all the old, device-dependent xfree86 code is to blame for most of the needless complexity and while it is being rewritten, it's a slow process that requires more developers than are involved with the project. Working with the new X.org code, while still demanding, wasn't really bad, just required thinking and getting "the bigger picture" well.
Actually, the new code is perfectly capable of dropping network transparency, integration of needless extensions and so on *when it's appropriate*, just take a look at Kdrive. But still too many important things remain in the xfree86 part.
Parent
Re:Anything else out there? (Score:5, Insightful)
They aren't.
Well, the drivers are. But obviously at this stage they DO have to be coupled to the server for a variety of reasons, not least that no one else wants to take over.
But let's face it, twm hasn't had any major work in a long time, and the window managers we all use on a daily basis are nowhere near the X.Org codebase.
Yes, we do need network transparency. I use it all the time. It's a major feature. Keep your hands off my network transparency!
Parent
Re:Anything else out there? (Score:5, Insightful)
Now, let me just open an application on another machine, and show it on this one's X server... hmmm... what's that - I need to be running Windows 2008 Server, and have a terminal server license?
How about running multiple display managers, so that I can have more then one person using the machine with seperate monitors and input... no. Thought not.
I could go on, but I think you'll get the point.
Parent
Re:You Are (Score:5, Interesting)
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.
Parent
What's the problem? (Score:5, Insightful)
Phoronix will pay to fix X (Score:5, Informative)
From the article:
Re:Phoronix will pay to fix X (Score:5, Insightful)
BattleCat needs to have a bug fixed. He approaches coders who, for free and in their spare time, code.
"Hey there, coderman. I see that you do this sort of thing for free and for fun, but what would you say to doing that coding thing that you love to do, hitting this one bug that I really need fixed, and ending up with all the satisfaction that you normally get from your work and a shiny nickel on top of it?"
"ZOMGBRIBERYYOUCALLOUSBASTARD!"
Really? Is that what you call bribery? Where I come from, bribery entails a breach of ethics. All BattleCat wanted was to add a little icing to the job that people were already doing for free in an effort to have something fixed that was a priority for him. That's about as straight-up, ethical, and non-bribery a way to get things done as I can imagine.
Parent
Typical of Microsoft (Score:5, Funny)
Gots to pay people... (Score:5, Insightful)
ID games? (Score:5, Funny)
Paid developers? (Score:5, Interesting)
Re:Paid developers? (Score:5, Informative)
Parent
Maybe it's time to dump X (Score:5, Interesting)
Perhaps X should be replaced, not improved.
How X got to where it is (Score:5, Informative)
1) Proprietary hardware. NVidia and ATI didn't release specs. That resulted in what little dev talent there was being used to do reverse engineering. ATI has gone a long ways towards fixing this.
2) Insistence on cross platform support. Cross platform support means no device drivers - everything in user space. There are all kinds of security issues with everything in user space. This also mean no integration with the underlying kernel. OOPS isn't visible, VT interaction, mode setting, no intergration with framebuffer, etc. Insistence on cross platform means that one OS can prevent progress from occurring on the others. There seems to be some movement on this issue.
3) Failure to endorse OpenGL-ES as the core driver system. The embedded world went OpenGL-ES and ignores X (N810 is an exception). There is money in the embedded world and not in the desktop. The money went to OpenGL-ES.
From a developer's point of view the architecture of X has not evolved in a way where a developer can work on one chunk of the code without having comprehensive knowledge of the entire system. Requiring that level of knowledge really reduces the number of potential developers. Finally there is a giant amount of NIH that goes on.
Re:I don't like this (Score:5, Insightful)
The salient question would be: What's stopping us from fixing the bugs in it.
Parent
Duh (Score:5, Funny)
Parent
Re:Finally, developers' ignorance and childish (Score:5, Insightful)
There's a LOT wrong with X.org right now, even mentioned in TFS. I personally wish they would put a lot more work into the transition to evdev and HAL, so we can get rid of xorg.conf and finally make strides to being as user friendly as "the other" OSes.
But network transparency? You're fighting the wrong battles here.
Parent
Re:Finally, developers' ignorance and childish (Score:5, Insightful)
export DISPLAY=skarabrae:0.0
and get actual work done fast!
Network transparency is *the* feature of X.
Parent
Re:Finally, developers' ignorance and childish (Score:5, Informative)
Everyone who suggests changing the architecture of X by removing network transparency is arguing from a position of ignorance. There isn't a faster mechanism for doing a GUI server without either building the windows server into each app (allowing only one app at a time), or building the window server into the kernel (bad idea).
Parent
Re:Finally, developers' ignorance and childish (Score:5, Informative)
As for the protocol, only a few parts are actually poorly designed. Grabs need to be reworked as they can result in subtle race conditions and lock-ups. There's a lot of old cruft that nobody uses that could go away, but isn't really causing a problem by remaining in the protocol. The main historical problem was Xlib, which did a lot of stupid things with the protocol, resulting in reduced performance, especially over the network. XCB fixes that, although no toolkits have been ported to pure XCB yet (and it may be a while).
Ultimately what's going to be happening is the move towards Composite/EXA, OpenGL and DRI(2) for everything, which should negate a lot of the existing problems with X's rendering infrastructure. Again, the lack of manpower is going to prevent these projects from making much forward progress.
Parent
Re:Haven't really noticed any reduced quality .. (Score:5, Insightful)
I agree wholeheartedly. The current release of X is suitable and works well for me.
The "upgrade every year" mentality is the wrong one to have. They missed their date? Okay, that's fine. As long as they don't buckle under the "release schedule" mentality compromise quality. I may be naive, but I don't know any reason they would want to push/rush their next release.
Parent
Re:Haven't really noticed any reduced quality .. (Score:5, Informative)
Parent
Well, excuuuse me! (Score:5, Funny)
Parent
Re:Lazy Developers (Score:5, Insightful)
Parent