Slashdot Mirror
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."
From the article:
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Probably the complexity of the issues involved, and the ever-expanding environmental requirements X is being written for.
If you haven't been down-modded lately, you aren't trying.
Sacred cows make the best hamburger.
Live today, because you never know what tomorrow brings
It's not that they missed their date because they were busily fixing bugs and adding new features; they missed it because they're just not doing that much right now. There's no management, there's very little direction, and there's really not that much going on at all. That's not a good thing.
Internally, X11 running in local mode works the same way as Apple's window server - using shared memory and local sockets. Hell, even Windows Vista works this way (except using Windows IPC mechanisms instead of Unix ones).
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).
Internally, X11 running in local mode works the same way as Apple's window server - using shared memory and local sockets.
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.
No windowing system has anything resembling widgets on the server-side. It's all done in client-side libraries, where that kind of stuff belongs. The server-exposed interface just provides the mechanisms needed for implementing widgets. That part is fine and doesn't need to change.
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.
I disagree that there's not that much going on - using the standard pci interfaces to access the devices, the recent input hotplug work, the new acceleration architectures in the DRM side...
Geez, people bash on the network transaprency all the time, while it's actually the least of the problems. And it's completely irrelevant when an application connects locally because it happens over a shared-memory IPC (which unix sockets actually is, despite having "sockets" in the name).
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.
This is Slashdot. Common sense is futile. You will be modded down.
Three main trends got X to where it is.
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.
oh, sure... blame it on the license... 'cause, you know, all engineers and programmers are more worried about politics than products.
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.
http://www.mhall119.com
local sockets *are* implemented as shared memory by most (all?) operating systems. The X-SHM extension you're referring to, has nothing to do with how the operating system implements local sockets; instead it allows applications to make use of shared-memory even when client and server are not on the same machine.
[...]
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. X uses multiple communications channels. There's TCP and DECnet, used for apps running on a different machine than the display server, and there's Unix pipes, which provide much higher throughput for local apps. But Unix pipes are nearly legacy now, because most servers also support MIT-SHM (the MIT Shared Memory extension), which lets an app have direct access to the X server's graphics buffers, and GLX (the OpenGL extension), used for running 3D graphics over a network. Finally, there's VirtualGL, which is a layer that can be used on top of either X11 or VNC. (See http://en.wikipedia.org/wiki/VirtualGL for more info.)
X11 already provides desktop Linux with you need to run high performance graphics.
Nothing for 6-digit uids?
Yes and no. Most of the core technology is GPL, but the front-end stuff, and therefore the actual client and server packages, are freeware or commercial. FreeNX is a fully-GPL fork.
that was the point of the fork though. Xfree86 developers moved slowly before X.org was formed, and wouldn't introduce changes like 3D accelerated desktop, period.
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.
i thought once I was found, but it was only a dream.
Erm, no. X-SHM came from MIT, not Sun, and is a mechanism for bitmaps on the same machine to be stored in shared memory segments.
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.
I would like to contribute to the X, but mostly what stops me is that the code is written for the 80s. Lots of internals are using macros and bit values and optimization hacks, and directly 'speaking' X11 protocol. The code is disorganized, with files in weird locations and with two-letter names. I'm not blaming the developers, because in the 80s this is what had to be done. And they are making huge progress making it modular and organizing the code. But it's still not an attractive codebase to dig into.
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.
I have done and do this quite often. The killer is latency, not bandwidth. Running apps from within my company's network is nearly as fast as running them on my desktop. If I want to run from my university a few miles away, it feels a bit sluggish. If you try to run from across the country, you will feel the latency. If you are using satellite, you will probably feel the latency. So, it does have its uses, but a user needs to understand the limitations as well.
Really? With xrandr, it's trivial to get multiple monitors working. I have my laptop set so that I can connect to an external monitor and switch to the spanned desktop on the fly. And get this... I can get it to remember how it was configured! Every time I had to connect under Windows, it forgot something, whether it was the resolution or the layout of the two screens, or whatever. I can just set up a simple script (or use the dialogs if that's your bag) that always does the right thing when I hit the screen switch button.
My blog. Good stuff (when I remember to update it). Read it.
Which is why a) no one ever writes directly against Xlib, and b) Xlib is being replaced by Xcb.
If you mean "take out the tcp/ip part", that wouldn't really change anything. If you mean "take out everything that enables networking" that would be a lot of work, and it still wouldn't get you very much. The hard part of maintaining and working on X internals doesn't really come from the network transparency stuff itself.
Now, if you have to deal with xlib for the X protocol, that can be a pain. But that is why XCB (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).
Climate Progress - Hell and High Water
2003 called they want their Xfree86x.org fork and release strategy back.
Paying taxes to buy civilization is like paying a hooker to buy love.
There's a lot of software out there that doesn't work with the Qt library directly--but I don't know enough about programming to know if that will matter. However, Qt is owned by Trolltech, and Trolltech is in the process of being acquired by Nokia. With Qt's currently using the GPL, Nokia may (or may not) continue to use that license for future versions.
If you haven't been down-modded lately, you aren't trying.
Sacred cows make the best hamburger.
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 based on user account deletion
Yeah, I have. Of course, I use the magic -C to ssh, that helps quite a lot. Certainly fast enough to be usable, though I could be better.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
X isn't sinking.
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.
Two problems with this.
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.