X.Org 6.8.2 is Out 450
ertz writes "The X.Org Foundation today announced the fourth release of the X Window System since the formation of the Foundation in January of 2004. The new X.Org release, called X Window System Version 11, Release 6.8.2 (X11R6.8.2) builds on the work of X.org X11R6.8.0 and X11R6.8.1 released in 2004. X11R6.8.2 combines the latest developments from many people and companies working with the X Window System and an open X.Org Foundation Release Team. All Official X.Org Releases are available for download from the ftp site and at mirror-sites world-wide."
So is Xfree86 dead? (Score:4, Interesting)
Debian? (Score:3, Interesting)
version numbers (Score:2, Interesting)
NetBSD (Score:5, Interesting)
i know they have no problem with the new XFree86 license, but there are other reasons. Xorg is the new de facto standard. it has more features, cleaner code, and the best xfree86 developers have moved to xorg. xfree86 will soon be obsolete, it's time they switch.
what's holding them back? they can still keep xfree86 on as an alternative too.
Re:So is Xfree86 dead? (Score:3, Interesting)
Re:version numbers (Score:1, Interesting)
XFree (Score:3, Interesting)
Re:NetBSD (Score:3, Interesting)
If it ain't broke....
The attitude seems to be that, if you want the newer features of X.org, it's not a problem to upgrade, otherwise, the older X is 'good enough'
Xgl (Score:5, Interesting)
Re:Windows driven Linux (Score:2, Interesting)
Apple doesn't have this problem, because Quartz Extreme supports a finite set of graphics cards, and Apple computers all ship with compatible cards. Even without Quartz Extreme, however, most of Mac OS X's eye candy still works because it's implemented in software. The only flaw is that you can't disable the fluff and save those cycles. In the end, it's probably all for the best, because Mac OS X looks like ass without it, but it would still be nice to turn off the antialiased fonts and glowing buttons when I'm trying to run three Adobe applications at once.
Then again, I could just stop beiing a cheap bastard and buy more memory. What was my point again?
Re:version numbers (Score:3, Interesting)
Re:Mostly stability (Score:3, Interesting)
About the whole X Window server (Score:2, Interesting)
I thought this was a driver issue, for example, on the same machine, opening, moving and resizing windows is very snappy on any window system beside X, be it MSWindows (yeah I know crappy, insecure, bloaty etc, but snappy), BeOS or OSX. Even the X11 on Darwin isnt quite as snappy as it should be being a GUI system.
In the case of BeOS, the graphic system is highly simplified, compared to client-server X, with a window manager on top. In the case of MSWindows, all graphics card manufacturers have designed their cards and their drivers to be optimum for windows, each little function on any chip, of rage, TNT, Matrox is used in the best way to blit, display and alter windows. I dont know much about cocoa, which came from the NeXT design...
Apart from the latency, I think the process priority of X and its child processes should also be rethought, under heavy load X and its WM becomes very unresponsive.
Linux/BSD have far superior OS designs and c libraries compared to MSWindows, its sad to see something simple holding them back from the Desktop market. Sure the lack of opensource graphics drivers are also holding it back, and so is the lack of standardization (gnome vs QT, menu system and location in the filesystem, even package standards... rpm?), but this one hurts in that it affects the image of opensourced OSes to commandline-shy users. gl-enabled apps even within windows run beautifully, but superior hardware is required to let the window system run as smoothly as other OSes. Some people think part of the culprit is the GUI system sitting outside of the kernel space, and all GUI-related processes being in a tree, rather than being children of init.
I wonder if X can be compiled as X-lite, bypassing the client-server overhead, possibly compiling WITH a simple WM rather than running it on top, and being run at a higher priority, should make things smooth. Any thoughts?
Re:Xgl (Score:3, Interesting)
"Want live, running thumbnailed versions of iconified windows? Done. Want your six virtual desktops to be the six faces of a cube that spins, with lighting?"
That's a lot more than eyecandy, a lot more than dropshadows. That's the beginning of a newly interactive media desktop. The rest of the OpenGL features for X are left as an exercise for the imagination for the next several years.
Re:About the whole X Window server (Score:2, Interesting)
In many cases this is the right thing to do! At least, on servers it's the best thing. Interactive performance is important, but sometimes other things are more important.
But you are right that context switches do cause latency. When you have two processes interacting with each other, then each time one stops running and it's time for the other to run, that other is sitting in the run queue and it must come up to the front of the queue before it can run. If you have a heavy load, this will result in latency, because some other process (or processes) will run for an entire time slice.
To some extent, you could reduce the effects of this with a clever scheduler. You could have interactive processes that can jump to the head of the queue in front of non-interactive processes, and you can place limits on how long they run to prevent them from hogging the system. However, you'll never totally fix the problem this way.
Still, I think it's very important not to break the modularity of X11. It's one of the great features of Unix. I can remotely do stuff via command line, but if necessary I can do remote stuff graphically too. This is totally invaluable to the system administrator. In some cases, it's the difference between having to walk three buildings over (or having to fly to another city) to spend 15 seconds clicking two buttons and being able to do it from your desk. It's so important that even though Windows doesn't natively have this feature, MS has tried to add it to Windows, and third-party companies sell products that let you do this kind of stuff. But, they all basically suck because the system wasn't designed for that, and it was cobbled on afterwards.
So, if any work is done trying to solve this problem with X11, it would be really nice if it's done in a way that doesn't sacrifice abstraction and network-independence in the name of shaving microseconds off of things that are already acceptably fast.
There are some ways of possibly fixing X11 without breaking abstraction that ought to be explored. For example, Solaris (and some other operating systems) have an IPC mechanism called doors. Doors let one process make calls into another process, but in effect the caller's thread executes inside the memory space of the called process. Then the thread returns to the caller, and you've accomplished communication without having to put threads into the scheduler queue (and wait for them to come out at the other end) at all! If you could do the same thing with X11, you could get the interactive performance desired by making this one method of communicating with the X11 server and still allow the X11 clients and servers to communicate by traditional methods (like TCP sockets).
Another method of doing the same thing would be to have the X11 client thread use some system call to directly wake up an X11 server thread (bypassing the scheduler) and have the X11 server thread do the same thing to wake up the client thread when the request has been processed. You'd still have context switches, but at least you wouldn't have threads sitting in queues.
And then a wholly different approach (which involves completely re-writing everything) is to put everything in the same address space, but use something Java-like (or actual Java) so that you don't have pointers and you can mathematically verify that one process won't screw with another's data. Then you can put a security system in place to control access to resources, and everything can just co-exist and call everything else directly.
Anyway, the point is that the client-server architecture is useful, and there are ways of fixing the performance without sacrificing it. Just recompiling everything into one big monolithic piece as a performance hack is go
Calling All developers - Xorg Needs your help! (Score:2, Interesting)
Things to help with:
Documentation - Doxygenifying the Xlibs, Xserver sources.
And other things
I'd like to see two pointers, two focuses (Score:5, Interesting)
Three Users, user zero, one, and two, are sitting in a conference room using a giant screen projector as the monitor, attached to a laptop someone brought. There are three different keyboards and three different mice attached to the laptop as USB devices. Some might even be IR so they are being used from across the room.
User zero picks up keyboard 0 and mouse 0, uses mouse zero to click on a terminal window and focus it, then uses keyboard 0 to type into it.
Meanwhile User one sits at keyboard 1 and mouse 1 to demonstrate something on the web using a browser window.
Meanwhile User two, using keyboard 2 and mouse 2, is making a diagram in openoffice.
Essentailly, there are three different "input contexts" each one consisting of one mouse and one keyboard, and each has its own mouse pointer, and it's own keyboard focus, and the X server is interleaving thier input events together and dispatching them to the appropriate applications.
The place where I would have found such a thing useful was a roleplaying game where I had a lot of visual aids on computer, one of which was a map with little tokens players could move to represent themselves on the map (each token was a layer in Gimp) It would have been handy to have public mice for them and my private mouse for me to use on the private GM screen (the laptop's own screen).
But, it doesn't seem to be possible without writing it myself....
The window manager is the problem (Score:3, Interesting)
The problem with X is much simpler, but nobody wants to hear it. The problem is the design of having a seperate process that is the "window manager".
Anybody who has used X for many years will know that the problems with moving and resizing windows have remained pretty much constant despite the fact that the machines themselves have increased in speed 100 times. This obviously indicates that overhead or latency is not at fault. The constant is retrace speed. Monitors now update about the same speed as before. If something is drawn by two different unsynchronized processes, you can see the two parts one retrace interval apart, no matter how fast your machine is. And the window manager means the border and the contents of windows are being drawn by two different processes.
Proof: try one of those media players that draws everything out to the border. Try resizing them. Ideally, to remove all aspects of window management, put it over an empty part of the desktop, or do all your work overlapping the contents of some other program (ie don't overlap both the borders and contents of another window). Notice that these apps are probably not doing very efficient graphics because they are full of eye-candy, yet seem to resize quicker and better than any other X appliacation.
How to fix it? The answer is to make the window borders be drawn by the toolkits. Yes, this will result in different window borders by different programs. No, this does not "confuse" the user. Users are confused by bad interfaces, not by different ones.