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!
Just out of curiosity, Hemos:
You download it... and what exactly do you intent to do with it? I mean, this is the sample implementation, and even if some stuff there is not present even on the XFree86 4.0 tree, unless you intent to merge the changes between R6.4 and R6.5 with XFree86 overnight... well you get the idea...
... is why version increments keep getting smaller on venerable standards. For instance, if you look at the early days of UNIX, SVR3 was soon followed by SVR4, and BSD went from 4.2 to 4.3 to 4.4 in a reasonable amount of time. Likewise, we went from X11R5 to X11R6. But now, we're stuck in X11R6.5.1.blah.
Is this TeX syndrome, where the version number asymptotically approaches some ideal number? X is already past 2*pi, but I'm sure there's a constant they're working toward...
-grendel drago
Laws do not persuade just because they threaten. --Seneca
From UNIX Unleashed...
"X WindowsThe first commercial release of X Windows was X10.4 in 1986, and was the basis for some commercial applications. The next release was X11R1 in 1987, followed by X11R2 in 1988. Version 11 was a complete windowing package that outperformed X10 in its speed, flexibility of features, and styles for multiple screens. X11 and later versions have become the de facto standard GUI for UNIX systems and are, therefore, the focus of this chapter."
Thus, X1-9 were apparently inhouse releases (just like the first several UNIX releases.)
A deep unwavering belief is a sure sign you're missing something...
The reason it's so slow is because it really wasnt' designed with current desktop configurations in mind
/., you really have to do a lot of things in X that shouldn't be necessary. (What I really want to see, though is a windowing system that totally ditches the concept of a palatte. Screw the 256 color users, let them put up with automatic dithering.)
A) It really wasn't built to take good advantage of powerful client machines. XFree86 has really helped in this regard with the XFree4.0, but the architecture is set in stone and there is only so much they can do.
B) It wasn't designed to take good advantage of hardware acceleration. Again, XFree has really helped with the rewrite of XAA, but they can only do so much.
C) There are many protocol limitations. For example, the reason they are having so many problems with anti-aliased text is that X only sees a font as a monochrome bitmap. Also, TrueType fonts are a bit of a hack on X, and general font support is poor. These are things about the protocol that just have to be worked around.
D) It seems that the API is pretty inefficient. As somebody pointed out to me a while ago on
However, the client server model really doesn't seem to be THAT big a problem. It is probably largely due to poor design decesions. For example, the Windows GDI is notoriously slow. It is largely 16 bit code that needs to thunk in every call to it. However, MS managed to get it to a decent speed by rewriting parts of it in ASM and putting it into the kernel. The GDI is actually just a DLL that is loaded by the client application. There isn't a server there. Despite these hacks, the GDI is still slow. (Though not slower than X.) The BeOS API, however, uses messaging and a client server model. Ask anyone, they'll tell you that it's the fastest GUI around.
A deep unwavering belief is a sure sign you're missing something...
Seemed a little odd at the time that the work on Broadway was just finishing up (or was done) and the X Consortium went out of business.
Of course, looking at the splash Broadway has made, it's not surprising.
Gosh, is anyone using Broadway out there? It seems like a good idea. Extend your X apps to browsers and still have the native X application. From what I've heard, it's slow, hard to use and immature as a technology.
Anyway, back on topic here. Who is doing this work for The Open Group and why? Is this being driven by the Unix vendors needs for new features?
-Jordan Henderson
XFree86 4.0 was released earlier this year, not X11 4.0. XFree86 4.0 was based on the X.org X11R6.4 sample implementation. This is a new release of the core X code, to which XFree86 adds support for the various video cards, and other additional features.
Other than X hackers, most users are best waiting for their particular X vendor (XFree86 for most Linux/*BSDs, Xig for some, Sun/IBM/Compaq for users of their Unixes) to incorporate the X.org
changes into their release.
As for license differences, the licenses are basically the same, with just the copyright owners
changed.
The X Consortium defines the standards, makes the sample implementation, and then XFree86 rolls it into their implementation (at some point). Or, of course, maybe Xi Graphics, or one of the other commercial companies, will also create their commercial versions.
If you look in your directory hierarchy, under /usr, you'll see that, even though you have XFree86 V4.0.1 installed, the directory is called X11R6.
----------
Stupid sexy Flanders.
Arg! As I'm sure many many many people will confuse this, what's just been released is NOT a version of Xfree86! It's a sample implementation of X11R6.5.1, not a usable X server for your linux box.
It's unfortunate that so many people are unclear on the difference between X and Xf86, and even what X really does.
Why is it called X11? I understand what X is, but I find it hard to believe that there have been 10 complete versions before this, if each is ALSO numbered with a major/minor number (6.51). Has it always been called X11? Is there a reason?
In cases like this, it would be good for someone knowledgeable to illustrate the differences, rather than simply expressing displeasure at the ignorance and audacity of those who aren't in the know, but willing to try.
I can see where it's easy to confuse X Consortium releases with XFree86 releases, since most books, HOWTO's, FAQ's, etc., don't touch this topic at all.
I have only the vaguest ideas of what those entities do, but I'd love to know more.
A foolish consistency is the hobgoblin of little minds. To email me, remove the nospamming.please from the email addr
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.