The State of X.Org 618
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."
Phoronix will pay to fix X (Score:5, Informative)
From the article:
Re:Anything else out there? (Score:5, Informative)
Re:Anything else out there? (Score:5, Informative)
Re:Haven't really noticed any reduced quality .. (Score:5, Informative)
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).
Re:Anything else out there? (Score:2, Informative)
There used to be the KGI project trying to seperate them and stabilizing the interface for the drivers, now Fedora is trying it again with kernel level mode setting, and I think this is something we need to clean up the mess.
Furthermore the windowing system is so generic and bloated that it is a nightmare to maintain. Even basic features are extensions already
Oh and of course: X is not sexy... hacking window managers is on the other hand...
Leaves the question: what does X need ? What should X focus on in the near future ?
Good enough (Score:1, Informative)
There's really been plenty happening, too. Look at EXA, the composite extensions, etc. For something as fundamental as the core graphics engine it's not doing too badly.
I'll admit I'm personally hoping to see more enthusiasm for moving mode setting back into the kernel, but that's not really all that big an issue how it is.
Re:Finally, developers' ignorance and childish (Score:2, Informative)
1. X wire proto is ugly. fscking ugly and so fscking low level I don't even know what to compare it with. Pushing ugliness faster via unix domain sockets (which are, presumedly, zero-copy on Linux ) (does anyone know about FreeBSD/Solaris implementation of UDS ? ) does not help in improving overall picture.
2. Changing protocol to work with higher level blocks (client-based widgets with server-backed structures) will probably break network transparency (since instead of low-level user IO and graphics resources, they'll need to work with complicated scenarios and behaviours)
(Keith Packard integrated client-side fonts relatively smoothly, but it was relatively easy task (relative to introduction of client-side widgets, of course)).
Re:Finally, developers' ignorance and childish (Score:4, Informative)
It doesn't uses shared memory, I think. There's a "shared memory" extension, but there's not a "shared memory transport" for the X11 protocol. Sun's propietary server has a shared memory transport, and it was said that they'd opensource and port it for X.org, but so far nothing has happened. It'd be an interesting thing to have, i think - today, when an application wants to display a image in the server it must send the whole image to the server (the protocol is network-oriented so it can't send a "reference" like a file, it has to send the whole data of the image). If the client app keeps the image in its memory after sending it to the server, the image is using 2x its memory size (one in the server, one in the client). With a shared memory transport, client and server could shared the memory that the image is using. Or so I've heard.
Re:Paid developers? (Score:5, Informative)
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.
Re:Haven't really noticed any reduced quality .. (Score:4, Informative)
Re:Finally, developers' ignorance and childish (Score:3, Informative)
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.
Re:Anything else out there? (Score:2, Informative)
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:Anything else out there? (Score:3, Informative)
Sheesh.
Admittedly, I know next to nil about the internals of X, however I think that it does its job well for what it was intended. The problem is that home-use of "desktop" linux is NOT what X was intended for.
When it comes to running applications on other, more powerful servers while being able to display the graphics on your workstation, it's tops. I've done it numerous times at school and internships.
In my freshman comp sci class, I'd use PuTTY and a local X server on the windows machine in the lab to access my FreeBSD machines in my dorm room and do my work on them, FROM the lab, in class. (i managed to get the school's admin to pony up static IPs and host names for my machines).
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.
oh, wait -- that's more or less how OS X is organized, isn't it? Or Windows... you know, the successful "desktop" operating systems -- not the systems that were designed for collaborative efforts in scientific and research environments.
Yes, I am simultaneously defending the UNIX way, and saying that it doesn't really address the problems that "normal" home users have.
It's worked for me, since I was 12 or 13 when FreeBSD 2.2.8 hit my machine, but I never expected anything other than what I was getting and so I got just what I wanted.
Re:Anything else out there? (Score:5, Informative)
Re:Finally, developers' ignorance and childish (Score:3, Informative)
Re:Anything else out there? (Score:3, Informative)
Re:Anything else out there? (Score:3, Informative)
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.
Re:Anything else out there? (Score:3, Informative)
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.
Re:Finally, developers' ignorance and childish (Score:4, Informative)
There have been several proprietary shared memory transports added by vendors over the years, including Sun, so the poster is correct. And once upon a time Precision Insight wrote an implementation for XFree86 as well.
However the conclusion after benchmarking various operations was that there was little to no benefit over the unix domain socket transport since it doesn't speed up render-bound operations at all the most significant transport-bound operations are already optimized using the SHM extension. Though performance was improved slightly on some hardware the recommendation after initial implementation and optimization was to abandon the effort.
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.
Re:Anything else out there? (Score:4, Informative)
Re:Anything else out there? (Score:4, Informative)
Re:Anything else out there? (Score:4, Informative)
Re:Anything else out there? (Score:4, Informative)
Now, if you have to deal with xlib for the X protocol, that can be a pain. But that is why XCB [freedesktop.org] (X C Bindings) was invented.
XCB is apparently very nice to work with, and it has "a small footprint, latency hiding, direct access to the protocol, improved threading support, and extensibility". The most recent distros are using XCB/xlib which uses XCB internal, while allowing xlib apps to function without changing anything. When XCB is standard in enough installed systems, apps and toolkits can begin migrating to native XCB. When the Awesome window manager 3.0 comes out, it will be the first WM to use XCB directly.
As for NX, it is really just compresses the X protocol and encrypts it. If you remove X network transparency, NX is useless. I, and I suspect many *nix admins, vastly prefer NX or X over SSH to VNC, RDP, etc (of course plain ssh probably gets used more than all of those put together on *nix).
Re:Anything else out there? (Score:3, Informative)
And I told you that I can do it via config dialogs, just like in Windows. I simply noted that IN ADDITION, I can script it, which I CANNOT do in Windows, at least not without a lot of serious work as far as I know.
Re:Finally, developers' ignorance and childish (Score:3, Informative)
And to be pedantic from a mac to a linux box, it is actually "ssh -Y linuxserver" for whatever reason the X auth doesn't work but the Y option for the auth works fine.
I run X apps from the server to the macbook all the time. The other way doesn't work as well because Quartz doesn't have network transparency.
Re:Anything else out there? (Score:4, Informative)
Re:Anything else out there? (Score:3, Informative)
Many people don't know it, but when they discover they can use a computer remotely, they go "wow". With X, that has been possible for over 20 years now.
Unfortunately, many X clients don't work very well over medium to high latency links. When I want to use the Eclipse at work from home, I'm better off using VNC than X over the remote link.
For years, I've been sitting on an idea to improve remote applications by, basically, pushing more code to the display side of the connection. That would reduce the amount of information to be sent over the link, in particular latency-sensitive things like pointer positions and key strokes.
Of course, this could probably be implemented (among other ways) as an X extension.
Re:Anything else out there? (Score:3, Informative)
That's kind of like betting that water is wet. :D However, "overly complicated" is unavoidable when the users want X to have the features it does, and to work (however well or poorly) on as wide a range of hardware/OS platforms as it does.
I started looking at some of the code for the X server back when I started with C. To a C-language newbie, it looked like the line printer had puked at random all over the paper. Now I have some experience with C, and it still looks almost as bad, but I can also see that the programmers did some pretty amazing work--considering the miracles they were trying to pull off, it's a wonder that any of it works, but they did a pretty damn good job.
Re:How close are we to being able to leave out X? (Score:4, Informative)
Re:Anything else out there? (Score:4, Informative)
You can safely run more instances of the Xorg server on linux - just start on another screen (ex. Xorg :1). It's just that easy - the server will run in another
virtual console. If you know you made changes that could lock up your screen/keyboard,
you could conveniently schedule an at(1) process to kill it after 2 minutes (or
ssh into the box from another machine).
And if your messing with video card driver code, then again vmware won't be of any use. Unless you're working on the special driver for the vmware virtual video card itself.
And finally, at least for debugging and testing purposes, qemu (which is free) works just as well as vmware.
Comment removed (Score:3, Informative)
Re:Anything else out there? (Score:3, Informative)
historical footnote (Score:2, Informative)
This was not true in, say, 1995 when I started using Linux, and when quite a lot of coders were enthused about joining the project. At that time the instructions for compiling the kernel suggested you go get a cup of coffee after you typed "make" and come back in an hour. I recall being very pleased when my spanking new Pentium 133 was able to compile the kernel in 20-30 minutes, if I recall correctly.
Re:Anything else out there? (Score:4, Informative)
Re:multiple cursors (Score:3, Informative)
Re:Anything else out there? (Score:4, Informative)
A better comparison is: do you keep sailing a ship that floats just fine, but is butt-ugly, slightly slow, has some odd quirks, and is missing some nice features found in the most modern ships, or do you build a new one? If you have plenty of resources at your disposal, you might as well build a new one. If you're resource-constrained, however, you better stick with what you have and just continue to patch it up.
Re:How close are we to being able to leave out X? (Score:4, Informative)
1) As another poster said, remote displays are still in common use. I use ssh with X forwarding every day at work so I can have my desktop on one machine while running apps on other machines. It's a lot easier to do this than messing around with multiple VNC windows. You simply can't do this without X.
2) Qt still needs some type of display device drivers to interface to hardware. Presumably, those smart devices had streamlined display drivers linking Qt directly to the display hardware, but that's a lot easier to do on a small device with only one possible hardware configuration. In addition to all the display abstraction stuff, X is also a framework for display drivers. Even if you dump X, you'll still have to fork off all the display drivers it comes with, and come up with a new framework to deal with these and interface them to the kernel and apps.
Personally, I think there's definitely some stuff in X which just isn't needed any more, such as the print server. But those things aren't central parts of X anyway, and are already easily omitted.
Re:Anything else out there? (Score:1, Informative)
Your arguments are so lame they almost make me want to write an X in Java just to spite. Btw nice link, Leaf.
Re:Anything else out there? (Score:3, Informative)
And the X protocol itself? Well, it sucks.
You are exaggerating hugely.
I have an 802.11g network here at home, and X sessions are completely unusable over it.
You have a problem and it doesn't appear to be X. I use X11 over a similar network via WPA2 and ssh -X all the time with no problems. GUI editors, utilities, whatever. I don't bother with NX or ssh -C. A few programs are badly coded and do unnecessary screen updates causing slowness. Working with images can be slow also. Fortunately I'm not interested in running those programs remotely.
I'd suggest you check your wireless network throughput. I get 1.2-1.7ms ping times with 100KB/s throughput on mine. Possibly there's interference from another WiFi network running on the same channel or other interference like metal, an electric motor or faulty network hardware.
The X11 code base is crufty and needs cleaning up but it works, and for many use cases it works well.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
Re:How close are we to being able to leave out X? (Score:2, Informative)
Re:Anything else out there? (Score:3, Informative)