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).
I think the main thing that holds back X (either .org or free86) is the legacy mess. What we see as X is actually a combination of the graphics drivers and a windowing system.
...
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 ?
To a large extent it's good enough. Many remaining issues are with more obscure drivers (via, I'm looking at you) and with high-performance 3D.
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.
Ok. Let's get this straight:
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)).
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...
Exactly, what you want is a pluggable gui-object model in the server. I want to be able to say, through the X-protocol: scrollbar there, these dimensions and gimme these events on it. Apart from the time it would save on the wire (gobs and gobs of it), there would be no more bad-headed implementations of a scrollbar. Also, cut-n-paste and drag-n-drop must be taken out of icccm and be given a decent implementation - what a load of crap that is !
Religion is what happens when nature strikes and groupthink goes wrong.
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.
AFAIK NX needs the network stuff you want to remove and VNC is quite slow unless you use a VNC X server.
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.
I believe xorg-x11 version 7 was the first modular one. That was a good three years ago.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Use, NX instead of plain remote X11, it almost feels like sitting at the local computer even over slow DSL. It's free as in GPL and very simple to set up. I really don't understand why it hasn't become THE standard for remote windowing yet.
My other account has a 3-digit UID.
[...]
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
Yes, it does do primary and secondary screens. Or mirrored. Or whatever.
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.
My blog. Good stuff (when I remember to update it). Read it.
He could run X apps on the mac, but you can't export native OS X apps over X from the mac.
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.
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.
I think the network transparency in X (which I use quite a lot) is both underrated and overrated (by different people, to be sure).
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.
Please correct me if I got my facts wrong.
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.
If you haven't been down-modded lately, you aren't trying.
Sacred cows make the best hamburger.
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
The average collection time using openoffice to load and edit a document was 0.0018 seconds and max 0.004 on a pretty old pentium 4 system. Java 7 (ie openjdk) allocates objects on the stack using escape analysis. Malloc/free are often slower overall than gc unless you can allocate more than one object at a time, which for a lot of requests won't be the case.
Needless to mention that to compile (properly configured) Linux kernel (with subset of drivers and features you really need) only few minutes
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.
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.
MPX.
http://rocknerd.co.uk
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.
Your arguments are so lame they almost make me want to write an X in Java just to spite. Btw nice link, Leaf.
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.
If Nokia stops publishing Qt under the GPL, the last GPL'd version automatically gets a nice BSD license slapped on it: http://www.kde.org/whatiskde/kdefreeqtfoundation.php
Luke-Jr
Nothing for 6-digit uids?