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.
XFree86 is now easy to install. Does anyone remember, back in the early 1990s, going through the agony of trying to get XFree to run on a Linux box? Why it didn't have 'standard' 1024x800 screen mode, I'll never know.
So driver manuals were dug out, guesses made for my monitor maxmum horizontal something rate. Huge configuration files edited. Even though, as a complete newbie, I had no idea what the various things I was changing did.
But! When it worked... I never went back to Windows again...
--- My dad's political betting
Now the X has another meaning :)
Well, I hadn't started my experimenting with X 'til five years ago, but I distinctly remember buying a crappy PC at the time with low-end onboard video and having to wait six weeks for the X guys to write drivers for it. Man, that was painful! (What did I know, eh?)
Also lacking a proper connection at home, later on I stole literally hundreds of floppies from work to get X, Gnome and Enlightenment onto it. God, I loved that eyecandy. Anyway.
========================================
Death will come, and will have your eyes
-- Pavese
For the inevitable "X sucks, I hate X, let's replace X, screw X" crowd: Suck eggs.
X works, works now, and has worked for over a decade. I can still run some very old, but very useful software, and I can do it in a network-transparent fashion. X is fast, elegant (not the code necessarily, the functionality), does 2D, 3D and applications wonderfully, and is free and fully multiplatform, across all *nixes, Linux, MacOS and Windows.
Come back when you have something that works for real work that isn't just a theory, and if it's better than X without losing any of the benefits or extensibility, I'm suree the *nix community will thank you for it. Until then, X and XFree86 (the gold standard) are here to stay, and that's a good thing.
STOP . AMERICA . NOW
A standard widget and graphical component library. I don't care if you use GTK+, Qt, Motif or some other more or less perverted set of functions, they should all result in using the same components with the same look and feel. Let's say you create a menu in GTK+ with the ordinary commands. These instructions should be converted to draw the standard toolbar, using the user preference (menubar on top, in window, detachable...).
I don't see any disadvantage by doing this. You still get to program in the language you prefer with the library commands you prefer, but they all draw the same widgets. While you are at it, design a new clipboard system that works - base it on the existing code from the Gnome and KDE people if you want to.
Is there a reason not to do this? Is it technically impossible? If so, please explain why. I'm a programmer, but I'm not very experienced in X development.
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
The idea here is that X has efficiently managed to maintain full backwards compatibility efficiently.
... by not really adding anything new in the last 10 years.
;-)
Si
Coming soon - pyrogyra
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."
It is not really binary compatible, but protocol compatible. X11 is a (network) PROTOCOL that describes how to send drawing instructions from client to server and how the server should send events (mouse, key) back to the client.
And exactly that is the genius of X (in contrast with most other windowing systems that are based on API's). Therefore, it is easy to get network transparency, and backwards compatability does not confront you with the headaches that API binary compatability causes.
Maintaining compatability is just as simple (OK a bit less since it is a complex protocol, but the extention mechanism was very clever) as backwards compatability for ftp,nntp,dns etc.
The idea here is that X has efficiently managed to maintain full backwards compatibility efficiently.
... by not really adding anything new in the last 10 years.
;-)
I see your smiley =)
xinerama, render, shared memory, xv, truetype. To name just a few.
fucktard is a tenderhearted description
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.
I loved early X.
First of all, it allowed me to bombard my testicles with 1 gigawatt/sec of abnormal radiation whilst I frantically rummaged through old manuals looking for the hertz values of the Y-axis of my monitor.
Oh wait! No got it! No! Yes! No! No!
Not only has it rendered my sperm inert, it has rendered the rest of me inert, too.
I was the director of business dev at a failed dotcom, so I'm not entirely sure what portion of me was inert at any one time during the crucial "growth phase" of my company or when my monitor was transforming my DNA on a daily basis.
But! I lived to tell about it.
X is a network protocol. If you look at network protocol stacks you see layered design patterns everywhere. That's the beauty of X. It is confined to a layer, and performs that layer service extremely well. I know it has drawbacks and inefficiencies, but it is the best protocol so far.
Including widgets and component architectures is stepping on the upper layer. It violates layer independency, and introduces unneeded complexity. X is a large enough behemoth as it is.
Leave widgets separate, as they are now. It works, and it is elegant.
BTW, this is also why I disagree with the various alternatives to X that discard the network protocol, and go for direct hardware communication. It is a decision that mixes the graphical communication layer with the layer beneath it -- you gain some speed and loose lots of flexibility.
If at first you don't succeed, skydiving is not for you
"Mach is the biggest intellectual fraud of the last decade."
"Really, not X-Windows?"
"I said 'intellectual'."
-- overheard in Silicon Valley
Well done man, getting modded as insightful for admitting that you have been asleep for 6 years
Hey, I nodded off a lot. Can I have a point too?
-- MarkusQ
P.S. I'm shooting for Funny but I'll take Insightfull if that's all you've got.
You dont have to deal with several hundred students using Xterminals...
.xsession and window manager configs until I haven't a clue what does what and can't help them sort out problems.
- it's flexible, meaning each of our lecturers wants the students to use a different window manager, and the students edit their
- it's network portable, which means our students could be using machines on the other side of the world and running netscape on that and then complaining to me that it's running slowly and I cant tell they are running it on foo.bar.au
- it's cross platform, meaning whatever machine someone has on their desk, they want a copy of it installed! Grrr! There's nothing a BOFH hates more than having someone want some software!
- it allows you to run a screensaver as background, using up CPU cycles that the rest of our students would like to use for statistical analyses! killall -9 xscreensaver!
- it's free, which means I cant use our budget as an excuse to not get it so I dont have to install it, thus creating more work for me!
No, I love it really. X is fantastic. Here's to X more years!
Baz
OK. Now. It's your job to convince all the GTK+ and GNOME hackers that they should all start programming in C++ instead of the half-dozen languages they currently use, so that they can use the Qt toolkit. Obviously this requires a complete rewrite of all the GTK+ programs they currently have. To make this an easier pill for them to swallow, you should mention that they will also have the wonderful opportunity to rethink their component model, their a11y model, their i18n model, their UI generation method (for those who use Glade), and so forth.
Alternately, you can convince all those silly KDE hackers that their applications should all be rewritten to use GTK+ and the GNOME libraries. Similar to above, but reactions will probably be even more amusing.
Keep in mind, here, that these are the same people who are so flexible and open-minded that they hacked on KDE for literally years while Qt was available only with a non-GPL-compatible license (and KDE is GPL-licensed), which created the interesting situation where KDE was illegal to distribute at all. While some KDE hackers acknowledged this discrepancy, they didn't want to look bad so they refused even to add a license clause to KDE to allow it to be distributed with its Qt bindings. This would have been a simple exception clause - two lines at most. Instead, they (by implication) refused to allow anyone to distribute their software. (Many parties such as Caldera and Red Hat just "looked the other way" and distributed it anyway - strict license compliance took a back seat to customer demand.)
I mention the license difficulty not to reopen long-dead flame wars [oops, I probably did already] - because indeed the situation resolved itself admirably when Troll Tech relicensed Qt to the GPL - but to show the extreme loyalty these people have shown towards Qt, despite its former legal issues.
A third option is for you to do all the necessary porting work to move all your favorite applications to a single widget set / desktop framework. Pick whichever one you want, though you might keep in mind that if you decide on Qt, you will have to rewrite a lot of stuff in C++. Of course, you're rewriting a lot of stuff either way....
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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).
Yes it is.
For most of us the killer feature is network transparency. There are many windowing systems out there which do a great job of running applications on a local CPU, rendering them to a local graphics card, and taking input from local keyboards and mice. This is, however, very limiting to those of us who have been accessing our machines over networks for the past 10 years. Only recently has the Windows world achieved remote access with decent usability / performance (and I'm still not sure if there's a Windows-based remote access solution that supports input devices other than keyboard + mouse), and most other non-X graphics platforms never even made the attempt.
It's not like we are asking for a bunch of esoteric features that only found in X11. We're asking for one basic feature, network transparency. Those who marginalise this feature probably don't understand what all it can be useful for.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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
Men and women have lived in millions of years and we're still compatible.
What the fsck are you talking about? Yes, we may be compatible at the lowest Physical layer, but for those same millions of years you speak of, we (men) have also been trying to reverse engineer their (women's) higher-level protocols. We've barely broken the Data-Link layer and even our understanding there is only minimal. Compatible? We can barely keep our sockets connected. Hell, the last time I tried to ping my wife she gave me a protocol mismatch error! My Session layer with my her has been working reasonably well for many years now, but you ought to see the Presentation layer break down, especially on birthdays and anniversaries! I'm afraid, my friend, that we've got a long way to go to achieve full compatibility.
--Jim
Does XFree86 provide alternate color spaces as overlays? I have never tried, but I know sun hardware will allow an 8bpp program to run in a 32 bpp screen depth as an overlay. This would make things much easier than switching on the fly. I think overlays are better than changing screen depths ont he fly. There was a time when changing color depths would have been more important, for example my Voodoo3 needs to be in 16bpp mode for games, and 32bpp is nice for non-games. Also, people wanting to have really large screens most of the time, but added color depth at a smaller resolution is not so much an issue with cards with massively large amounts of memory, that can operate in massive color depths at any resolution.
I would say that a couple of years ago it would have been worth solving the problem, but now I say crank it all the way up and don't worry about it. I can certainly see the problem, old applications would never understand being told their colorspace has changed, though I would think you could slip something into the X libraries that could make it work for new and dynanicly links apps, but I'm far from an expert.
XML is like violence. If it doesn't solve the problem, use more.
Some of the contributors to the "fortune" program (a random quote generator) had some affectionately nasty things to say about X windows. Under Linux, try fortune -m "X windows". A random sample:
X windows: Accept any substitute; Making the world safe for competing window systems; It could be worse, but it'll take time; Simplicity made complex; One thousand monkeys. One thousand MicroVAXes. One thousand years. X windows; It's not how slow you make it. It's how you make it slow; Warn your friends about it; A mistake carried out to perfection; Complex nonsolutions to simple nonproblems; The defacto substandard.
I want 3 of those 10 years back for wasting so much time trying to get my XF86Config file to work right.
--
Does anyone remember
I will not speak of Qt, because I have limited knowledge of it. However, Gtk+ and later GNOME addressed many of these shortcomings in ways that made a great deal of sense. It also did so in ways that were portable to Windowing systems that were either variants of The X-Window System or different altogether, but still provided the basiscs of display manipulation and event model.
The core X Protocol is a wonderful way for applicaiton and display server to talk. XLib is painful, but you can abstract it and still live with it reasonably. Xt was simply unworkable.
Of course, these points are moot. Gtk+ today along with GNOME do much more than Xt or Xaw or Motif ever did, and there's simply no going back. Color management, font management, internationalization, window manager interaction, system- and user-level configuration: These are all things that todays toolkits do far better than was ever available in the bad old days.
Of course the way your modern audience here on Slashdot thinks of theming, this is terribly misleading. You could build wildly complex resource configurations that would hand-tweek the widget heirarchy of a specific application. You could also set background colors and such, but since there were no solid conventions (not at all in Xt, and not enough in Motif and Xaw), these were of limited usefulness.
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.
Like you said, Sun *hardware* did this. Apparently XFree86 supports this, at least with Matrox hardware. Here's what mga(4) says:
"[the driver] provides support for the following framebuffer depths: 8, 15, 16, 24, and an 8+24 overlay mode.
All visual types are supported for depth 8, and both TrueColor and DirectColor visuals are supported for the other depths except 8+24 mode which supports PseudoColor, GrayScale and TrueColor."
I never needed something like that but I knew this because a colleague requested a G450 for a PC workstation he was to use alongside his trusty Octane, just for that feature... not that the G450 isn't an otherwise excellent choice for a workstation of course. I have one at home and it is the best thing I bought for my PC after that SMP motherboard...