Slashdot Mirror
XFree86 10 Years Old
ChazeFroy writes "XFree86 is now 10 years old. To quote from the page, 'What makes this particularly eventful is that it is fully backwards compatible; this is a true testament to the spirit of the original X protocol of which XFree86 is its finest implementation.'" Ten years and
still binary compatible. Very cool.
X rules:
- it's flexible, allowing a multitude of different window managers to front-end for it
- it's network portable, allowing me to run X-sessions off another box completely over a ssh-connection
- it's cross-platform, running on almost any architecture and operating system (with the obvious exceptions of course)
- it allows me to run a screensaver in root-window as background, dazzeling all those MSWindows folks =)
- it's free!
In my opinion, there are very little GUI's able to beat that, not OSX for all it's beauty but lack of flexibility and not MSWindows for it's compatibility but ugliness.
---
"The chances of a demonic possession spreading are remote -- relax."
X standardised Xt, a standard for toolkit interoperability at the component level (it is possible to embedd an Xaw component in a Motif application, for example).
Unfortunately, neither Gtk nor Qt honour Xt, nor X's excellent "resource database" generalised configuration and theming (yes, theming!) system.
Gtk because it was written by a bunch of people initially without the faintest clue how X actually works, and Qt because Qt is like "Swing for C++" - it's intended to be cross-platform, and thus handles most drawing "itself", merely requiring prettu much a dumb framebuffer underneath.
Thus, the two most popular toolkits on Linux are abysmal from an X standpoint.
All drawing would be done by the library in the displaying machine.
The tradeoff is that X was originally designed 10 years ago to work with thin clients. A thin client is supposed to have nothing but a video card and the X client. If you add a widget library, on what storage space do you put it? Not to mention storing the user preferences for the window mananger and widgets. Also not to mention the extra processing necessary to render the widgets.
To a thin client, especially one designed when X was first designed, storage space and processing power are much more limited than bandwidth.
And if you can live without KDE's pretty eye candy or 3D screensavers, even a broadband wire to the server will be more than enough (hint, Motif may be ugly, but it works for its purpose).
By what definition of "monolith"? The five or six client libraries you may or may not need to link to? The separation between client and server for display? The (optional) separation between graphics server and font server? The separation between graphics server and window manager? The separate client libraries for low-level network protocol and widget set? The loadable modules which implement everything from hardware backends to input device drivers to font rasterizers? The separation between user-space and kernel-space components (particularly for 3D graphics rendering)?
Which of the components I have mentioned so far is the "monolith" of which you speak?
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Yes, I'm Blacking Out right now, or whatever...but this just had to be said.
The one comment that gets put out there by opponents of X *time after time* is that it's old and cobbled together. This is seen as a bad thing.
Then there's some MS article, where everyone attacks their old compatibility layers and old implementations.
Now, a story on XFree's birthday rolls around. "It's still compatible with stuff 10 years old!" Well good for you. Why is that a good thing? Sometimes the old has to go if you want to properly implement the new.
If there's one protocol that has been overridden adn axtended in more unnatural ways than X, it has to be HTTP. (At least X was intended for applications from the outset.)
± 29 dB
The core X Protocol is a wonderful way for application and display server to talk. XLib is painful, but you can abstract it and still live with it reasonably.
For an Xlib alternative in its early stages, check out XCB, a lightweight, transparent X protocol C Binding. One of the beauties of the X protocol is that sticking a new (and hopefully "better") API on top of it is relatively straightforward.