Slashdot Mirror
X Consortium Announces X11R6.5.1
cthulhubob writes "X11R6.5.1 is available for download from X.Org. This update has over 200 enhancements, including a large revision to XPrint, the unified X printing service. Press release is avaliable online." It was announced back on the 15th, but it's now availible for download - time to clog some bandwidth pipes!
You know, the best thing for X would really be to dicate a bit more policy. The whole concept of X is to provide the low level services that higher level window managers need. Thus, X can provide a common foundation, while window manager provide the actual user-interface. However, this concept has faded in recent times. Now, you have things like GNOME and KDE implementing things that really should be in X. Things like printing services, imaging systems, and object models, that aren't really part of the user-interface, but part of the lower-level "services" layer that X provides. The benifits of integrating more of this into X are obvious. Instead of having the two competing desktop environments that you have now, you would have a common base of X windows applications that would work in any window manager. In the process, there really isn't any freedom lost. Are the two desktop environments really that different? Aside from the look (which belongs in the window manager anyway) the two environements pretty much provide the same services in more or less the same way. Sure you know have one object model, one imaging system, etc. Of course, you only have one graphics system for X, you only have one X input API. You can't choose the input subsystem for X, so why should you be able to choose the object model? For that matter, why should you care? At some layer of the system, you have to standardize something or all hell breaks loose. SOMEBODY has to dictate policy or else you end up with a sysem THAT HAS NO POLICY. In return for a little freedom for the developer, think of what you gain. The user gains the choice to use what desktop environment they want. Developer gain the freedom to not have to worry if they are cutting of people by using the wrong DE. Commercial vendors gain the freedom to write applications to a desktop environment instead of just statically linking Motif.
A deep unwavering belief is a sure sign you're missing something...
WWJD -- What Would Jimi Do?
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
The networking code between the X client and the X server in XFree86 is a UNIX domain socket. This is possibly the fastest IPC method in Linux. The UNIX domain socket requires only one redundant copy and Linus Torvalds himself has optimised the all mighty crap out of it.
Experts in XFree86 have already tried using other transports to see if things improve. This has in the past included a shared memory segment between the clients and the server. The surprise result was a reduction in speed. It seems that Linux has such a good implementation of UNIX domain sockets that doing it all by hand is an overall loss.
Removing the transport altogether is impossible. This is not an X consideration. No matter what windowing system you have, at one stage you need to pass messages between the clients and the X server, because they are not the same binary and they do not run in the same address space.
So ignore the pipe. The pipe isn't the problem. A real problem is context switching. Because the X server and the X client both run as user space processes the kernel must alternate the execution between client and server. This increases the latency of operations and time is wasted doing the context switching.
One solution that can result in a speedup is to put the X server into kernel space. This saves you one redundant copy and two redundant context switches. It also means your system is now as stable as Microsoft Windows.
The compromise solution is to put some highly timing critical code into the kernel but keep most of it in user space where it belongs. This is the technique that the DRI has used. It means the client can render directly to the hardware while still maintaining a balance between security and stability and clean design.
SUMMARY: The real performance killer of X is not the pipe. Changing the transport has already been tried and has already failed.
A lot of the things Linux users have been beefing about are starting to come together. Check out the new veriosn of FreeType, which includes 8-bit anti-aliasing and many nifty rendering features for many different types of fonts. See also the new experimental rendering engine for XFree86 here. Check out those translucent TWM windows. MMMM.
Free86 takes the code that the X Consortium has developed and changes it in such a way as to make it x86 native
Thats what they did originally. Lately, they've started applying useful patches to the clients and libraries from outside sources that may or may not every get into TOG's X(tm). For example, XFree includes the xterm patches from here, added the essential XPM library, and beefed up Xaw to make it almost usable. Check out the release notes for more details.
Even more recently, they've started to tackle the key features that hold X back, like font handling and transparency. Check the mailing list archive for the most recent developments.
I'm not going to be one of those people who gripes that Slashdot is not Freshmeat, and therefore shouldn't announce software releases. (Hey, if it's News for Nerds, it's fair game.) However, could we try to have some explanations of exactly what this software is, what it does, and why this release is significant? Posters and editors should realize that this isn't the same audience as Freshmeat (i.e. not everyone compulsively keeps track of and updates every item of software in their system). And, I'm embarassed to say, "X11R6.5.1" doesn't mean much to me. C'mon guys: if we wanted plain vanilla software announcements, we'd read Freshmeat (and many of us do). So please, don't just announce the news -- report it.
Thanks,
IT
Power corrupts. PowerPoint corrupts absolutely.
Plain and simple, this does not go on top of Xfree86. In fact, this release has nothing to do with Xfree86 at this point, until the Xfree86 people merge the changes into the xf86 4.0 tree and declare a new release.
What we have here is a sample implementation, and not something that you want to use on your workstation. This will become useful once various releases of the X window system incorporate it, and then moreso when applications and toolkits are written to work with it.
There weren't really ten full releases prior to X11R1, however there were 10 incompatible revs of the protocol. Most of the early versions were primarily used within MIT (Athena and LCS) and friendly commercial R&D labs. Here's some of the pre-history based on cryptic notes and blurry memory: X1 - summer 1984 - the first version, based on a substantial rearchitecting of the UNIX port of the W Window System (originally developed for the V Kernel). X3 - fall 1984 - used internally at MIT as the initial basis of various plotting packages for coursework. X6 - spring 1985 - first version licensed by MIT to various companies (including Cognition, MASSCOMP, and Digital) for use in commercial products. It cost $100 and if you wanted you could stop off at the (very small) licensing office to pick up your own magtape. X8/X9 - fall 1985 - added color (X8 lasted all of about a week; X9 was quickly released to fix a protocol alignment problem that impacted ports on the IBM PC/RT). Many organizations began developing ports (including a version to the Lexidata 9000 display card for VAXen that was used at the Autofact tradeshow in late 1985 to show a prototype of the first 3rd party application: a mechanical engineering design system). X.V10R1 - spring 1986 - first version released by MIT that did not require signing a license agreement. Also the first version to have a DOS Xserver developed. X.V10R[234] - fall 1986 & spring 1987 - an explosion of ports done on a variety of platforms. X.V11R1 - Sep 15, 1987 - major overall done in collaboration with folks from Digital, Sun, IBM, and other companies. Formed the basis of core protocol used today. Companies and organizations releasing X-based products used this release as a starting port for incorporating into their own distributions. X.V11R2 - March 1, 1988 - first version released under the auspices of the newly-formed MIT X Consortium. The MIT X Consortium continued to put out releases of X11 for a number of years. Then in the mid-90s, it was spun off into a separate not-for-profit organization (simple the X Consortium). As has been noted, that eventually folded into various organizations that became X.ORG. The rest is history. :)
Jim Fulton