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.

Comments

Much more importantly

[rcs1000]

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...

Re:Much more importantly

[Ankh]

These days I tend to use Mandrake Linux, which usually sets up X and the monitor and mouse automatically.

I first used X (not XFree86) in 1988 or so, on a 386 with a horribly expensive video card. But it worked.

I still have some binaries from 1990 or so (SPARC, SunOS 4) that still run and talk to the X server. For that matter I still have some NeWS programs (like display PostScript) that don't run because NeWS died.

So, it's cool that we're finally getting antialiasing, downloadable outline fonts, and maybe even user-defined server-side graphics paths. Welcome to 1990. Ten years old, but with a lot of catching up to do.

In other areas, like Keith Packard's new XML-based configuration format, XFree86 is setting trends for the rest of Unix/Linux to follow. And where it's behind, it's being worked on.

It'll be interesting to see if X has enough momentum (I think it does) that Berin will die too, a footnote because not mainstream enough. just like NeWS.

NeWS was trivial to install, no config file at all. Installation matters, but applications matter more.

Re:Much more importantly

[aussersterne]

Yes! Those were the days.

My first Linux box monitor (a 14" Emerson) blew its top after only a few weeks use (I had been running the monitor at 65Hz when it only supported 60Hz), so I got ahold of a 19" fixed-frequency Tektronix sync-on-green monitor and built a sync-converter circuit with a little resistor coming out the top pot to help align the signal. I still have the schematic filed away somewhere...

Then I spent the afternoon trying to see what I could get out of the monitor, finally settling on 1088x702 or something like that at about 58Hz (ugh, flicker!) with of course no hardware text mode or CTRL-ALT-PLUSMINUS magic, just that one mode. When I booted the machine, I saw nothing at all until the magic 'X' cursor in the middle of the stipple pattern would appear. Beautiful. I probably still have the XF86Config file on a DC6150 tape somewhere. ;)

Damn fun. These days it's all about water cooling and big CPU fans and neon lights in case holes, but it's somehow less entertaining...

Re:Much more importantly

[xtremex]

Yes...I remember..it was around 93-94 or so. It was FUN doing that stuff. It's still fun.

Re:Much more importantly

[Skuld-Chan]

I remember when you had to set up the xconfig by hand.

One thing I think is funny is setting up XFree86 on sparcstation - aside from the fact that it should have been called xfreesparc - none of the configuration scripts that came with it were suited to sparc - so I'm answering questions about vga, resolutions, colour depths and monitor info when I'm using an sbus, 8 bit, fixed frequency monitor :( - worked anyhow ;)

Re:Much more importantly

[Jeremiah Cornelius]

Linux SLS distribution, downloaded from CompuServe, 'cause the file quota on SUTRO, the NeXT cube at SF State was under 2 Mb. Target hardware? 486 33 with 32 Mb Ram and two 200Mb Conner IDE disks - Orchid ProDesigner II, with some ancient S3 chip, and TWO WHOLE Mb VIDEO RAM!

1024x768 interlaced was unbearable on a 13" display... 800x600 got you 65,000+ colours, and FVWM windows that extended beneath the viewable desktop. Ferocious learning curve xf86config and example output files...

God bless 'em! The XFree team had a display server that was able to handle more hardware than any commercial vendor. Sometime in '94-'95 we tweaked this thing onto an uncooperative SCO Interactive/86 installation, and had local display support for a client.

I still scoff madly at the Xinside advertisements that FUD against XFree in the pages of SysAdmin. Writing down to a technical audience... Go figure.

Re:Much more importantly

[HeUnique]

There are some still (rare) cases that you need to modify XF86Config by hand. I had such a case few months ago when a friend of mine wanted to make Linux work on his P133 Toshiba Libretto. It was fun to see X running with WindowMaker..

Re:Much more importantly

[HeUnique]

Today the situation seems to be in reverse when it comes to features. I remember a friend of mine wanted to by Xi driver for his card (don't remember which card), and was surprised that their X server doesn't support full screen modes for his VMWare and the Xv support simply sucks in their servers...

They do however have a much faster 3D X server for ATI then whats available freely today, although for a high price (when was the last time you payed $100 for a 3D driver?)

Re:Much more importantly

[psamuels]

There are some still (rare) cases that you need to modify XF86Config by hand. I had such a case few months ago when a friend of mine wanted to make Linux work on his P133 Toshiba Libretto.

I recently hand-tweaked mine to adjust video timings for a DLP projector. The projector doesn't need nearly as much horizontal blanking as the average CRT, but it has a fairly limited bandwidth, so I was trying to drive the v-refresh as high as possible by squeezing the blanking parameters. This is for active stereo (left and right eyes each see only half the frames) so every Hz counts. Got it from 85 Hz up to around 93 Hz that way - I know the projector can handle 96 Hz or more (I've seen it under HP-UX), but the X server and/or the graphics card seemed to think some of those numbers were just too small.

Thank goodness for ESR's video timings HOWTO. I don't know of any way in Windows to do the equivalent (OT: anyone?), so our Windows box is stuck at 85 Hz. XFree86 rules!

Re:Much more importantly

[Paul Komarek]

I remember. A friend had a blazing fast (and rare) 486 DX50, and I convinced him (which wasn't hard) to try linux with X on it. My 386 SX20 was too slow, and probably too incompatible since it was from Packard Bell. There was an application called Xroach which put lots of beetles on your screen that scurried for the shelter of your windows. When you closed a window, they'd scurry somewhere else. We were really impressed at the number of small but nifty apps available. As computers got faster, the beetles of Xroach turned into blurry streaks of black; I don't think anyone ever bothered slowing it down, and I haven't seen it since.

I have an Infomagic CD collection with a 1995 copyright which contains a very small leaflet outlining slackware installation. Section 9 is titled

X11 Configuration Cookbook -- How to Get X
Running Under Linux (without calling the fire
department)

Later they go on to say "Thus it is possible to overdrive the horizontal synch. of most monitors and cause *damage* or even *fire*. (Yes, they WILL burst into flames...it has happened!)".

I was truly and eternally impressed. =-)

-Paul Komarek

Re:Much more importantly

[jedidiah]

WinDOS wasn't exactly a cakewalk in the early 90's either. People seem to have short memories regarding that.

Re:Much more importantly

[Gulthek]

Or when, as my brother tells me, the instructions to connecting your monitor told you with no trace of irony to grab the nearest occilloscope to determine frequency timings.

Re:Much more importantly

[Junks Jerzey]

Does anyone remember, back in the early 1990s, going through the agony of trying to get XFree to run on a Linux box?

Last time I dipped into Linux, in 1999, this was still the case.

Re:Much more importantly

[ArsonSmith]

# apt-cache search xroach
xroach - infests X with disgusting cockroaches
You have new mail in /var/mail/wwarner
wwarner:/home/wwarner# apt-cache show xroach
Package: xroach
Priority: optional
Section: games
Installed-Size: 96
Maintainer: Joey Hess
Architecture: i386
Version: 4.0-8
Depends: libc6 (>= 2.2.4-4), xlibs (>> 4.1.0)
Filename: pool/main/x/xroach/xroach_4.0-8_i386.deb
Size: 13414
MD5sum: dfd42a1b3861765ad2af5eb9e8aced64
Description: infests X with disgusting cockroaches
Xroach displays disgusting cockroaches on your root window. These creepy
crawlies scamper around until they find a window to hide under. Whenever
you move or iconify a window, the exposed orthoptera again scamper for
cover.

Still there in debian. We use it here in the office to find out who leaves there DISPLAY wide open. It is fun to launch xroach onto someone elses display.

Re:Much more importantly

[CAIMLAS]

1024x800 is a 'standard' resolution? I've never seen it before. :|

Re:Much more importantly

[CAIMLAS]

Hey now, let's not be biased! :) Some of us still do. It helps edge a little better performance/optimization out of your hardware if you get specific.

Re:Much more importantly

[bugg]

What version of XFree86 have you been running? I'm using 4.1.0 and it was as painful as any to configure. Whenever they say they've made changes to the installation program, I try it out. Time and time again I resort to my old XF86Config file that was generated and then tweaked (and retweaked) both by hand and with xvidtune. I've never found XFree86 configuration to be that bad, but it's sure not great either.

I have found that AccelX, on the other hand, is truly easy to install. It's much like installing Windows 3.11.

Re:Much more importantly

[Paul Komarek]

Wow, thanks for the good news! Do they have a selectable speed, or otherwise move at some reasonable rate?

-Paul Komarek

Re:Much more importantly

[Arandir]

Who cares about speed? I'm going to launch these suckers on everyone with an open display :-)

Re:Much more importantly

[be-fan]

It depends on your setup. For me at least, the only way to get my monitor to do 1152x864 at 85Hz (instead of the headache inducing 75Hz XFree 4.1 thought it should run at) was to manually add a modline. This involved not only editing XF86Config (simple edits like this shouldn't be a problem for most people) but learning a whole lot more CRT theory than I cared to. In the end, even I ran out of patience and wrote a BeOS program that grabbed the appropriate numbers. Until the X developers engineer some more "smarts" into XFree86, it won't approach the ease of configuration of other systems. Of course, I am happy with the config situation of most Linux components. KDE and GNOME are easy to configure, and the kernel is taking a lot of steps in the right direction (trying to make everything automagical). The real problem is in the user-level (ie. things that aren't part of the kernel or GUI) software, all of which have different configuration systems and none of which are designed by people skilled at UI (and yes, config files are a form of a user interface) design.

Re:Much more importantly

[Jeremiah Cornelius]

Surely, it's not an AT-bus interface!

Sure, but...

[NetRanger]

...it still doesn't have Albert Einstein helping you search for files on your computer. You call this advancement!?!

Re:Sure, but...

[Jugalator]

Could Windows XP be considered to be way ahead with a puppy helping you search? ;)

suggested X changes

[Partisan01]

Congrats to X on it's birthday. I've noticed in the past on /. that everyone has opinions on what should be changed in X. I havn't had any problems with it and I'm quite pleased with it's performance. But i'm wondering what do you guys thing should be changed/added/taken out etc?

Re:suggested X changes

[Chainsaw]

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.

Re:suggested X changes

[finite_automaton]

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

The problem with this is that X is intended as a much lower level toolkit. X is what you you when you want to create a widget set such as Qt or GTK or Motif of Athena. As far as X is concended (and rightly so), widgets are "someone elses job"

Re:suggested X changes

[Anonymous Coward]

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.

Re:suggested X changes

[Chainsaw]

what you are suggesting (or meaning to suggest) is probably that all these toolkits should have different API's but draw the same thing onscreen. Now why exactly is that good?

All applications would look the same and act the same. Let's say that you start Emacs and Gnumeric under KDE. Now you see three different graphical widget styles, all acting slightly different. If I set KDE to use a single menubar on top of the screen, only applications utilizing the KDE (or Qt?) framework adhere to this rule. This is just so damn wrong.

By utilizing a single, underlying library for these things, problems like these would disappear. I don't see anything wrong in all applications behaving the same - a consistent user experience can't be bad.

Re:suggested X changes

[Chainsaw]

WHY is it this way? From a bandwidth point-of-view, this is a horrible solution for a network independent protocol. Instead of saying "draw a button at this position, caption 'OK'" you send several kilobytes of pixel information. Exactly the same thing goes for window managers as for toolkits: saying "new window here" would be much better. All drawing would be done by the library in the displaying machine.

Re:suggested X changes

[Khazunga]

You are half-right. A standard widget, and component library are needed, but I disagree with the need to integrate it with X.

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.

Re:suggested X changes

[tal197]

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...).

Well, you're probably right. The problem is X's extension mechanism. Doing this means sticking a whole load of code in the X server. And, since different people will want different styles, the user has to be able to choose which widget set to install (but, once installed, all applications will use it).

Unfortunately, X runs as root. This means that it's already a huge security/stability risk, and letting users customise it would be unthinkable.

Anyway, fix the must-run-as-root problem and the way opens up to add all kinds of new features to X since you don't have to audit every line...

Re:suggested X changes

[psamuels]

By utilizing a single, underlying library for these things, problems like these would disappear. I don't see anything wrong in all applications behaving the same - a consistent user experience can't be bad.

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....

Re:suggested X changes

[Chainsaw]

That was not what I wanted. The KDE guys kan still use Qt, and all Gnome people can still happily live on with GTK+ and C. However, they should both use tha same low-level routines for drawing buttons, menubars and other items. No adaptation should be neccessary for the programmers, the code hiding behind the Qt and GTK+ API:s should be modified to handle this.

Re:suggested X changes

[big_hairy_mama]

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).

Re:suggested X changes

[infiniti99]

X is just a display layer and does not concern itself with widgets. If we want it to be more than that, then it wouldn't really be X anymore.

The problem comes from the fact that there really is no such thing as a "real widget" on just about all platforms. When you consider a toolbar on Windows 2000 as a real widget, you are actually looking at MFC. Borland has their own toolbars, as does Qt. Even at the heart of win32 there is just a display buffer that these widget sets draw on, just like X. OS X is the same way.

The difference between Windows and X though, is that it maintains consistency. Or at least, it tries to (common exceptions would be Winamp, Quicktime, gtk-win32 apps, etc). If we want consistency in X, then what we need is a defined look and feel. Then the toolkit doesn't matter, as long as the result looks the same.

I agree that making a more high-level remote protocol would be more bandwidth efficient, but it might be too limiting as well. I have pondered the idea of funneling Qt QStyle calls over the network, but I'm not sure how that might turn out.

Re:suggested X changes

[psamuels]

That was not what I wanted.

<whew> - you just saved someone a lot of work. (:

However, they should both use tha same low-level routines for drawing buttons, menubars and other items. No adaptation should be neccessary for the programmers, the code hiding behind the Qt and GTK+ API:s should be modified to handle this.

Did you read the interview with Nat Friedman yesterday? Last question, third paragraph of his answer:

In fact, it would be possible to get Qt to use Gdk as well, which could make shared themes possible there too.

I hadn't thought of this, but it's a good point. You (or someone you know) could port Qt to use the Gdk graphics widget set, which is what Gtk+ uses. Since both Gtk+ and Qt support multiple display systems (both run natively on Windows, for example) the apps themselves shouldn't be much the wiser.

Re:suggested X changes

[Chainsaw]

Hmm... Qt already support different visual styles. It contains built-in support for Motif, Windows and Mac (Platinum) lookalike. If they are implemented through C++ classes and virtual functions, this could be easier than I first had imagined.

Re:suggested X changes

[psamuels]

WHY is it this way? From a bandwidth point-of-view, this is a horrible solution for a network independent protocol. Instead of saying "draw a button at this position, caption 'OK'" you send several kilobytes of pixel information.

What you describe is DPS, Display PostScript. The display server can run and even store code snippets sent by the client. Thus you get a completely generic environment that can still draw you exact style of buttons on demand. Think of PostScript as the pre-web-browser equivalent of Java. (:

DPS never did have a free implementation (though Display Ghostscript is around nowadays - but I have no idea how complete / usable it is) but it or similar technology appears/appeared in NeWS, NeXTStep and now MacOS X.

Re:suggested X changes

[OwnedByTwoCats]

X was designed _20_ years ago.

Re:suggested X changes

[ajs]

X standardised Xt,And UNIX standardized dd, but we don't use it for backups anymore do we?

a standard for toolkit interoperability at the component level (it is possible to embedd an Xaw component in a Motif application, for example).

And Xt is about 60% of the reason that Motif blows chunks. There are several serious, objective reasons for this:

• The resource database was difficult to manage because it required encoding large amounts of inherently non-string oriented data into strings
• It was an early attempt to develop an OO model in C. The inheritance model was cumbersome and required far more code to manage than the application itself in almost all cases
• Xt attempted to manipulate events in ways that were terribly inefficient. Especially high on this list of problems were the atificial events created by the widget heirarchy. This above all else made Xt (and thus Xaw and Motif) a painful user experience, and an endless optimization quest for the programmer.

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.

Unfortunately, neither Gtk nor Qt honour Xt, nor X's excellent "resource database" generalised configuration and theming (yes, theming!) system.

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.

Re: suggested X changes

[po8]

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.

Re:suggested X changes

[ajs]

And you still can do that. If you want to. If you chose to use a GNOME-compliant program you can create a defaults file for it like so:

usegeometry=80x63+85+174
class=Class-MAIL
termin al_id=0
command=ssh -C user@example.com
font=-schumacher-clean-medium-r- normal-*-*-80-*-*- c-*-iso646.1991-irv

This is an example from my gnome-terminal config that is used to start up the login shell to my home machine. Only that class of terminal is affected, of course....

GNOME is very easy to configure in a large number of ways. You should try it out!

Re:suggested X changes

[spitzak]

Cut/Paste is done by the X system, not by the window manager. It's just that the interface blows so all toolkits have to add some nicer interface above it. Thus cut/paste in Qt has a different programming interface than in Gtk. This leads people to believe that the underlying mechanisim is different between KDE and Gnome, in fact it isn't and they actually interoperate quite well (the incompatability would be the same as two Windows programs not agreeing on a filename to store some temporary data in, no amount of design will fix that, one of the two has to change their mind to agree with the other).

It would be nice if Xlib added some easier interface to this stuff so that all the toolkits did not have to do it.

Re:suggested X changes

[spitzak]

Not true, in many cases it takes much less code to describe how to draw a button than to describe the fact that you want a button drawn (ie there is a box and label, which is exactly the same amount of information as "a button named this"). Then people say "well I will send the object id only" but in fact in most cases you have made it worse because now the entire object must be sent initially so that the object id will work, and this tends to be an enormous amount of information, 95% of which will never be used, but must be sent in case you do the call that needs this information. This stuff tends to bloat excessively over time, too.

This was a serious problem with NeWS, which I worked on, and basically made it impossible to make a C program talk to the widgets efficiently.

In any case I think "standardized widget set" is seriously misguided. If X had been designed with such a set it would be still using Athena style widgets today and would be laughably primitive.

Re:suggested X changes

[spitzak]

Nonsense, alternative widget kits were very much in use. This was when to use X you got a commercial distribution and got Motif for "free".

Face it, Motif was absolutely horrible, and people were desperate to replace it.

Examples include xview, tk, Forms and XForms, Glut, early versions of fltk (which I wrote long before Linux was any big deal), and literally dozens of others. None of them used Xt or Motif, and for good reasons. Take a look at any commercial program that was graphic-intensive then (especially for SGI) and less than half of them used Motif.

Re:suggested X changes

[spitzak]

The idea is that Gdk provides a "draw a raised button-like rectangle here" call. At least I think it does. Thus if Qt used gdk (and it was written in such a way that loading a "theme" replaced the implementation of that low-level call without making assumptions about how Gtk used it or modifying gtk stuff to match, which I actually think is very unlikely) then they could match.

Personally I think the "consistent user interface" is way oversold. I have yet to see a user "confused" because the buttons are different colors. They are confused when the left mouse button does not push the button, but that stupidity was eliminated long ago in X programs and none of these "themes" even attempt to address that anyway.

Re:suggested X changes

[AJWM]

Well, no, you don't send "several kilobytes of pixel information" (at least, not unless you're running some really elaborate graphics-intensive theme), you send a "draw a big rectangle here, draw little rectangles here, here, and here (the button edge shadows) and the text 'OK' here".

The advantage of this (or even sending the pixmap) over the "draw button here" approach is that the X machine can be much stupider in terms of processing power.

Back when X was designed, networks were much faster relative to CPU and memory than they typically are today. (A comparison would be if everyone was running at least gigabit ethernet these days.)

Re:suggested X changes

[spitzak]

Yay! It is good to see at least one other person who understands what is going on.

In fact in all implementations I have seen, it requires less code to draw the button than to communicate the fact that a button exists. Compare the number of Xlib calls needed to the size of the interface to the button object in either Qt or Motif, the interface to a button is 10 or more times larger!

Sending pixmaps is stupid but fixing it does NOT mean that the server has to understand widgets. It means we need the ability to keep the pixmap on the server (X already does this). And it means we need better graphics "primitives" like Gourand shading, and perhaps the ability to send compressed images straight from files to the server (not as the final image but as pixmaps to build the final image from). This (powerful graphics) is the area that X seriously lacks! But is annoying to see every attempt to solve this getting confused with the completely backwards "put a toolkit in the server" idea.

Re:suggested X changes

[AJWM]

a consistent user experience can't be bad

That was considered a Good Thing back in the dark ages of computing when GUIs were new and the typical user was terrified of doing the slightest thing wrong lest they "break the [expensive] computer".

These days, any user who has spent more than a few minutes surfing the web has seen so many variations on the user interface that a minor difference in widget styles or even behaviour is no big thing.

Hell, at least under Gnome and KDE the buttons are more-or-less rectangular. That's more than I can say for a lot of web sites (and, for that matter, game software) I've seen.

(Heck, even Apple discarded the uniform style of their famed Human Interface Guidelines with their movie player panel a few years back, since cloned by countless variations of media player software since.)

Re:suggested X changes

[Guy Harris]

The idea is that Gdk provides a "draw a raised button-like rectangle here" call. At least I think it does.

No, that's not what GDK provides; it knows nothing about "button-like", for example.

See the GDK 2.x reference. It has calls to draw rectangles, but not "raised button-like rectangle[s]". It's GTK+ that knows all that fancy visual stuff.

Re:suggested X changes

[big_hairy_mama]

You're right, I realized that as soon as I hit post :) XFree86 was built 10 years ago, X was 20. So my argument is even stronger, because 20 years ago the processing power to render widgets/windows available in a thin terminal was nonexistant.

Re:suggested X changes

[spitzak]

If that is correct then the original poster is correct in that using GDK would do absolutely nothing to make the themes match. I personally don't think it would work even if GDK had a "draw a button" call, it would be as difficult for Qt to be rewritten to use that as to use all of GTK underneath it.

Re:suggested X changes

[spitzak]

Some of CDE/Motif was adopted. The ICCCM standards for window managers are from it and still exist and are used by the newest KDE and Qt. They are working on replacements (since the design lacks a lot of modern actions like maximize-vertical) but it is expected that programs using those standards will continue to be recognized and work.

Re:suggested X changes

[Guy Harris]

If that is correct

It is.

then the original poster is correct in that using GDK would do absolutely nothing to make the themes match

The original poster is, indeed, correct; it appears that Nat Friedman was confused when he asserted that making Qt use GDK would enable them to share non-pixmap themes - the theming code is in GTK+ (which knows what scrollbars, buttons, etc. are), not in GDK (which doesn't).

(I say "non-pixmap themes" because, if I remember correctly, either Qt can load GTK+ pixmap themes, or KDE includes something that can turn them into Qt themes.)

"X"Free86

[popeyethesailor]

Now the X has another meaning :)

Re:"X"Free86

[Dwonis]

But does NP = 7 ?

Seems a bit... odd

[AaronStJ]

Ten years and still binary compatible. Very cool.

I hate to be a boor, but isn't this the sort of thing Windows get's criticized for all the time, having "broken" backwards compatibility? It seems like if Microsoft is going to get flamed for retaining (somewhat kludgy, perhaps) backwards compatibility, the same standards should be applied to X windows...

Re:Seems a bit... odd

[JLTech]

The problem is the "somewhat kludgy" part. The idea here is that X has efficiently managed to maintain full backwards compatibility efficiently. Windows, however, has many issues with their backwards compatibility. I feel that complaining about actually letting you use your old software is foolish. Complaining about not being able to use it WELL...now that's something I would listen to.

Re:Seems a bit... odd

[spectecjr]

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

Re:Seems a bit... odd

[Baki]

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.

Re:Seems a bit... odd

[psavo]

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.

Re:Seems a bit... odd

[Junta]

Well, maintaining protocol compatibility would be nothing to brag about, every X implementation ever made should do that. But there is a binary compatibility involved. There is more than simply the X-Server talking to the applications, the mechanisms provided to the applications for commuincating with the server are provided through *libraries* (libX11.so, for example). If they are claiming binary compatibility, that means an app compiled with their very first version of the libraries should be able to painlessly run in an enviornment today with current libraries. Of course, the huge overhauls and impressive work is mostly done on the X server itself, so the libraries can be mostly left alone. I would think this claims is hard to prove, since 10 years ago most every library but XFree86 has changed dramatically, but I guess someone might have compiled really old versions of XFree86 on modern distros and checked, but I seriously wonder if they have *really* checked to see if this is true.

On the nostalgia tip

[twilight30]

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.

X kicks ass, XFree86 doubly so.

[aussersterne]

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.

Re:X kicks ass, XFree86 doubly so.

[aussersterne]

The trails you see have very little to do with your CPU and everything to do with your graphics accelerator. If you're seeing artifacts or slowness on a 266MHz (or even 66MHz) machine, your accelerator chip is either lacking proper accelerated drivers or is misconfigured.

Re:X kicks ass, XFree86 doubly so.

[Anonymous Coward]

Windoze optimises for "client" use, bumping the piority of the GUI at the expense of background processes (even on nominally "server" computers)

Linux installations typically don't (except for Mandrake 8.1+), since they're generally assumed to be "server" machines - you can significantly speed up your GUI by running X with a negative nice value, since that way the GUI pre-empts background stuff, just like on Windows.

So if you nice -n-10 X, it'll be apparently faster, and the slower your machine, the more noticeable the improvement will be. Since you machines are godawful slow by the sound of it, this should help you a lot.

This _is_ mentioned in the X manual, BTW. I don't understand why people don't read computer manuals. It takes months to learn how to drive. Computers are several orders of magnitude more complicated than cars, yet people seem to think one should be able to jsut muddle through wihtout any learning. Even windows only has a VERY thin veneer of "easiness", it's actually horrendously complicated (more so than unix).

Re:X kicks ass, XFree86 doubly so.

[mpe]

Windoze optimises for "client" use, bumping the piority of the GUI at the expense of background processes (even on nominally "server" computers)

IIRC the highest priority task in Windows is driving the mouse pointer.

Linux installations typically don't (except for Mandrake 8.1+), since they're generally assumed to be "server" machines - you can significantly speed up your GUI by running X with a negative nice value, since that way the GUI pre-empts background stuff, just like on Windows.
This _is_ mentioned in the X manual, BTW. I don't understand why people don't read computer manuals.

With many pieces of software it's a case of "good luck finding a user manual". (With even better luck if you need a service manual.)

It takes months to learn how to drive. Computers are several orders of magnitude more complicated than cars, yet people seem to think one should be able to jsut muddle through wihtout any learning.

An important point is that even once someone has learned to drive they do not suddenly become a motor mechanic. Yet a lot of fuss is made about how computers should enable something analagous to a barely competant driver being able to perform major maintanance.

Even windows only has a VERY thin veneer of "easiness", it's actually horrendously complicated (more so than unix).

It is also very "unfriendly" when things go wrong.

Re:X kicks ass, XFree86 doubly so.

[DrXym]

Yes it works and it works very slowly. Graphics applications are very clunky compared to their Win32/Mac counterparts.

Linux needs to consider running X on top of the desktop rather than underneath it. Implement versions of GTK/QT that talk to the framebuffer directly and run KDE/GNOME on top of that. I bet the performance increase would be astounding. It's getting to the stage now where more and more people exclusively or generally run their desktops locally so it's a makes little sense that everything must go via clunky old XFree86.

People who run remote could simply fire up XFree86 just as before running in rootless mode. I do this on the OS X and XP and it works fine.

Re:X kicks ass, XFree86 doubly so.

[CaptainPhong]

Ignore this guy's sig. He deserves to be burdened with positive karma as punishment for posting something so insightful.

Sure X has some good "ideas", but even the most devout techie knows that the lack of an easy to use and easy to configure GUI is the major obstacle holding Linux (and other unicies) back from widespread desktop adoption.

As just one example, see how long it takes for a new Linux user to install a true type font and get it working everywhere. Compare that to Windows or Mac (or even a pre-system 7 Mac with that goofy Font Mover program).

Re:X kicks ass, XFree86 doubly so.

[HeUnique]

Oh really?

Can u give me a URL for full accelerated driver for my Geforce 2 card? how about some fast 3D graphics please? good XvMC support? umm, perhaps XFT-2 support please?..

Apparently not...

Re:X kicks ass, XFree86 doubly so.

[aulendil]

But first, someone has to implement even rudimentary hardware acceleration into the framebuffer.

Then someone would start to complain about lackine network transparency.

Come on, X is here now, and it works beautifully! Nor is it slow, as seen by the mailer Sylpheed, or Dillo. Or Qt Designer. It's obvious that the perceived slowness of X lies neither in the toolkits or the windowing system, but somewhere else.

For KDE and GNOME that slowness rather stems from the kparts/bonobo component architectures

Re:X kicks ass, XFree86 doubly so.

[Zathrus]

For KDE and GNOME that slowness rather stems from the kparts/bonobo component architectures

So? The point remains that it's significantly slower than other windowing systems that aren't network transparant.

Then, of course, there's the utter lack of standardized widgets for doing just about anything. Which is where kparts, gtk, etc. come in. But it's a sad statement that a GUI that is WELL over 10 years old (X11 predates XFree86) is just starting to get some decent standardized widgets (sorry, no, CDE, OpenWindows, Motif, etc. didn't cut the mustard even when they were new).

And while developing for Windows is a PITA, developing for X has been even worse traditionally. It's changing, again thanks to the libraries mentioned above, but it's taken way way too long.

Realistically the only trick that X11 has over the competition is network transparancy. And that kicks ass, no question. But I don't think it's worth everything that has been missing (and will continue to be missing) for that. I mean come on, if you can run a Windows desktop over the network with decent response then network transparancy doesn't mean a hell of a lot anymore. Windows is about as network-hostile of a desktop as you can get.

Re:X kicks ass, XFree86 doubly so.

[psamuels]

Linux needs to consider running X on top of the desktop rather than underneath it. Implement versions of GTK/QT that talk to the framebuffer directly and run KDE/GNOME on top of that. I bet the performance increase would be astounding.

So, you run Gtk+ right on the bare metal. Well, that's fine as long as you don't mind running full-screen. If you want to have more than one application running at once, someone has to arbitrate. That means you need a window manager. Then someone has to keep track of the mouse pointer - individual applications would otherwise fight over it. That includes drawing it, moving it around, changing it to the right sizes, shapes and colors on demand. I guess that would go into the window manager as well. Same goes for keyboard focus - applications can't all think they have the keyboard at the same time, now, can they? What the hey, throw that into the window manager too.

Cut 'n' paste between applications? Need some sort of message passing server. Throw that into the window manager as well, why don't we. Drag 'n' drop? More messages - have to support that in the new window manager. Session management (i.e. login, logout, and which applications to start up when you re-log-in)? Need something for that too. 3D calls to the graphics card? Someone had better arbitrate - you only want one application doing that sort of thing at a time. I guess the kernel could probably handle that, since it is already arbitrating the frame buffer.

By now you have a new "window manager" which has subsumed a lot of the complexity of the X server. Sure, you are no longer passing messages between two processes just to display 2D graphics, but I'm not really sure how much of a speedup you get just from that. As Jim Gettys (you're posting technical comments about X11, so I hope you know that name!) is fond of pointing out, lots of people think X is old, clunky and bloated, but nobody seems to be able to produce an alternative windowing system with equivalent (or even adequate) feature set but without comparable complexity.

Re:X kicks ass, XFree86 doubly so.

[Centove]

Can u give me a URL for full accelerated driver for my Geforce 2 card? how about some fast 3D graphics please? good XvMC support? umm, perhaps XFT-2 support please?

http://www.nvidia.com/

Re:X kicks ass, XFree86 doubly so.

[aulendil]

So? The point remains that it's significantly slower than other windowing systems that aren't network transparant.

Well, no ;-). As I said the slowness seem to be in the component-libraries of the major desktop environment. This has nothing to do with X. X apps which do not use these services run fine and fast. Even though they use Qt or GTK+. As I said, the slowness isn't on part of X or the toolkit.

Actually KDE and GNOME would surely suffer from the same slowness in startup times even if implented (sp?) on Windows (the horror).

Then, of course, there's the utter lack of standardized widgets for doing just about anything. Which is where kparts, gtk, etc. come in.

GTK+ and Qt provides widgets, neither of these are slow if used as widgetlibrary, on the contrary, especially GTK is plenty fast. Qt suffer some from the gcc C++ linker.

But it's a sad statement that a GUI that is WELL over 10 years old (X11 predates XFree86) is just starting to get some decent standardized widgets (sorry, no, CDE, OpenWindows, Motif, etc. didn't cut the mustard even when they were new).

If only you weren't right...

Seriously what the various _UNIX_ desktop environments lack compared to Windows is a speedy component architecture. This is as stated above and in previous post not dependant on X. X handles the display and only the display. What the applications actually do behind the scenes are of no interest for X. Only what they display.

And with a well setup accelerated display, you shouldn't be suffering from artifacts or flickering.

On the problem of server for X, why do many seem to think the framebuffer would be better supported? I have no experience coding X-servers, nor any experience coding framebuffer support, so I ask: why should any one of those be easier? Enlighten me!

Re:X kicks ass, XFree86 doubly so.

[jedidiah]

There is NOTHING inherent in X that will "prevent your mother from running Linux". Infact, it is probably safe to say that any of the technical quibbles you might have with X (or any of it's children) are COMPLETELY irrelevant your mother.

All "mother" needs is a sufficient good frontend. Those infact exist for X.

Re:X kicks ass, XFree86 doubly so.

[jedidiah]

Most users that need GUI handholding are never going to install their own fonts. Self-appointed protectors of the meek and clueless have lost all touch with their "people". The only problems left in the Linux GUIs are problems strictly for the power-user crowd.

That is a shockingly low percentage of the overall computing population.

The same anti-intellectual memes that allow for Microsoft GUI mediocrity to be sufficient for the masses, do the same for Unix ironically enough.

Although, I am sure if any of my cluebie relatives got in their heads to install a font for themselves that I would be the first one that they would call to help them out of their WinDOS GUI quagmire. Most end users simply have a very low threshold of confusion. A shiny happy interface simply isn't going to help most of them much of the time anyways.

Re:X kicks ass, XFree86 doubly so.

[DrXym]

Why would anyone complain about lack of network transparency? If you want X, then run XFree86 on top of the desktop in rootless mode, just like people do on Win32 or Mac.

I'm not saying toss away X if you need it, but consider that an ever increasing number of desktop users do not need remote access yet they are burdened by the architecture.

Re:X kicks ass, XFree86 doubly so.

[Pope Slackman]

All "mother" needs is a sufficient good frontend. Those infact exist for X.

I've never seen one on linux[1] that I'd want to use everyday.
Sure KDE and GNOME et. al. are interesting toys, but their numerous kludges, bugs, inconsistencies, slowdowns, crashes, and poor GUI design annoy the hell out of me.

C-X C-S
[1] SGI's desktop wasn't bad, for a UNIX/X desktop.
Bit on the ugly, CDE-ish side, but at least everything seemed to work "right".

Re:X kicks ass, XFree86 doubly so.

[DrXym]

Sorry, but it shouldn't require 40Mb of binaries (not including fonts, man pages etc. or the WM on top of that) to make GNOME or KDE run. That's what XFree86 requires.

Microwindows demonstrates that it is quite feasible to produce something with the right kind of functionality required but considerably less overhead. That is what KDE & GNOME should be running on, a lightweight, local desktop. If someone wants remote they can run XFree86 in rootless mode, but a lot of people won't care about that.

And yes, it must be possible to produce an equivalent feature set simply because Win32 & Mac both manage to have fast desktops despite not using X at all.

Re:X kicks ass, XFree86 doubly so.

[AJWM]

You must be running some pretty arcane or crappy or ancient hardware, then. Or going the DIY route on software installation.

Every commercial distro I've installed in the past several years (including Caldera, SuSE and Mandrake) has autodetected the hardware and configured X automatically at install time. On everything from cheap old whitebox Pentiums to Compaq Proliants and even an old Sun Sparc IPC.

Re:X kicks ass, XFree86 doubly so.

[scrytch]

Implement versions of GTK/QT that talk to the framebuffer directly

Been done. The version of QT that runs atop a framebuffer has been used for boot menus and installers. It looks like ass because its settings are conservative (blame VESA for being 16-bit real-mode garbage)

and run KDE/GNOME on top of that.

Good lord, even windows doesn't do that, it's just that GDI (usually) draws direct to the graphics context, which can go straight to the framebuffer, whereas X's shared memory implementation only uses it as a transport for messages, and still requires a context switch to actually process each message (and they're numerous).

I used to think X needed to die off too, but I realized that it's enough of a meta-protocol that it can pretty well replace itself with some superior extension, while X becomes simply a transport. X12 just needs to standardize on those extensions, cut out unused cruft, fix some basic problems (fonts are such a joke) and for god's sake, make it less painful to program for. My main complaint is that we will almost certainly never see X12. I'm not even sure it's on the drawing board.

Re:X kicks ass, XFree86 doubly so.

[dvdeug]

it shouldn't require 40MB of binaries [...] to make GNOME or KDE run.

It doesn't. There are implementations of X that are much smaller. You're free to produce your own distribution of X without the fat, if you want.

The fact is, though, few really care. My /usr is 3 GB in size, about equal in size to 10 MST3K episodes I have laying around my hard drive. /usr/X11R6 is 14th on the list of big directories under /usr, after several kernel-source directories, documentation, locales and texmf(!!!). Tossing away some of the basic, if extraneous, X utilities that may be of use for less than 100MB is pointless; I have much more stuff that couldn't possibly be of use to delete first.

Re:X kicks ass, XFree86 doubly so.

[bonch]

"Windoze optimises for 'client' use, bumping the piority of the GUI at the expense of background processes (even on nominally 'server' computers)"

Actually, this makes sense to me. You should always be able to access the GUI. If I'm playing mp3s and suddenly all the buttons and menus on my other apps start lagging, it's not a very fun experience. Also, if something tries to bring down the system, you're more likely to be able to access the GUI to stop it. Since the GUI is what I'm using to interact with my computer, it stands to reason that it should have priority, so that it's fully responsive to user input. My opinion, anyway!

"Linux installations typically don't (except for Mandrake 8.1+), since they're generally assumed to be "server" machines - you can significantly speed up your GUI by running X with a negative nice value, since that way the GUI pre-empts background stuff, just like on Windows. This _is_ mentioned in the X manual, BTW. I don't understand why people don't read computer manuals."

I do read computer manuals. By the way, it's ridiculous that to get better performance, I have to fish through a manual for some arcane command. Your attitude--"RTFM"--is why Linux is not a very widespread desktop OS amongst us more "common folk."

"It takes months to learn how to drive. Computers are several orders of magnitude more complicated than cars, yet people seem to think one should be able to jsut muddle through wihtout any learning."

As someone here mentioned, just because you know how to drive a car doesn't make you a mechanic. That's like saying I should understand the internals of my VCR before I can watch a movie, or memorize all the positions of the Dorian scale before I can play a Led Zeppelin song on my guitar. People *should* be able to "muddle" through without learning the CLI commands to make their GUI preempt background processes. Otherwise, what's the point of a GUI?

Incidentally, I learned to drive in two weeks.

"Even windows only has a VERY thin veneer of 'easiness', it's actually horrendously complicated (more so than unix)."

I strongly disagree. In my opinion, I think it's ridiculous to say Windows is more complicated than Unix. Windows does most everything for you. As much as I hate to say it, "it just works." I remember jumping through hurdles the first time I used XFree86 some years ago just to get it to switch into something higher than 640x480. After spending an hour and a half and finally getting it working, I realized I could have just booted up Windows, where it *already worked.*

Your condescending attitude isn't causing sudden adoption of Linux by computer users (most of whom happen to use computers and drive cars but don't know their horizontal refresh rates nor their ignition timings).

Re:X kicks ass, XFree86 doubly so.

[Arandir]

Your attitude--"RTFM"--is why Linux is not a very widespread desktop OS amongst us more "common folk."

And the opposite attidute--"we don't need to stinkin' manuals"--is why the number solution to any Windows problem is to reinstall.

Incidentally, I learned to drive in two weeks.

Yeah, but I bet you didn't pass your driver's test without reading the manual.

You don't need to be an auto mechanic to know how to drive, but you should at least know how to change a tire. The common Windows perception is that you don't need to know how to maintain your car. If you get a blowout you'll just call up your neighbor Marge who knows even less about computers than you do. Unfortunately that doesn't work when your blowout occurs on I15 in the middle of the Mojave Desert.

Drivers need to know how to change tires, check their oil, fill up the fuel tank, somewhat understand what the gauges on the dash mean, how to signal for a left turn, what traffic signals mean, etc. A computer user is expected to know nothing at all.

Re:X kicks ass, XFree86 doubly so.

[Arandir]

You're obviously a Mac user, because the Windows GUI is so full of numerous kludges, bugs, inconsistencies, slowdowns, crashes and poor GUI design, it makes KDE and GNOME look like the poster boys of software engineering.

Re:X kicks ass, XFree86 doubly so.

[bonch]

PII266mhz with 96MB. XP runs faster than Win98 did on this same hardware. No smoking, seriously. The only slowdown I have is with the transparent selection box in Explorer, which I disabled anyway.

I'm also on a 33.6 modem. I guess I'm "old school."

Re:X kicks ass, XFree86 doubly so.

[bonch]

"I used a Voodoo3 3000 for several years under Linux with a middling K6 CPU and did not experience any slowdown -- opaque window moves were rapid and there were no slowness artifacts like window trails or visible redraws -- it was every bit as fast as Windows. I played 3D accelerated games (Myth II, Quake II) with no problems -- again, every bit as fast as the Windows versions."

Hmm, interesting.

"What distribution are you using? And are you sure it hasn't configured your card using the VESA framebuffer mode, instead of the tdfx driver module, which is what it should be using?"

I was using the tdfx driver on Slackware 8. I'm sure it could be any number of things causing the low performance. As I said, I really should just look into upgrading to more modern hardware. Still, XP runs nicely right now (granted, I'm using third-party drivers for improved OpenGL support), so perhaps there was something I missed in the config. Either way, it's problems like this that make me realize I don't have the time to be fishing for the problem when I have work to do! And so I boot up the XP partition... :) I'm sure things will improve with XFree86 as time goes on, and maybe then I'll make the total switch, but not now.

Re:X kicks ass, XFree86 doubly so.

[bonch]

"And the opposite attidute--'we don't need to stinkin' manuals'--is why the number solution to any Windows problem is to reinstall."

I'm not afraid to say it--the fact that to use Windows requires little to no reading of HOW-TOs and thick manuals is a point in its favor.

"Yeah, but I bet you didn't pass your driver's test without reading the manual."

Read no manual, I learned from my dad.

"You don't need to be an auto mechanic to know how to drive, but you should at least know how to change a tire."

What would be the Windows equivalent to that? Adding/removing a program? These are simple operations compared to what I was referring to, things like making the GUI preemptive by using some command at the bash prompt. And such knowledge may be trivial to you and me, but to someone inexperienced with Linux, they'll just say "Well, that's stupid," and move on to to something that works for them outright. Why shouldn't they?

"The common Windows perception is that you don't need to know how to maintain your car."

Ideally, a computer should be able to maintain itself. And people don't credit Windows enough for how well it works. I'm not talking about the 9x line, either--I know how bad it was.

We have the ability to make things easier on the user. You seem to be suggesting that it doesn't matter, and that the user *should* be forced to manually maintain their computers on principle. That seems a step backwards, like a halt on progress. Should we get rid of automatic transmissions, power steering, and more, because drivers *should* drive it raw just to know how and what it's like? Why should computers be complex? Most other industries consider it a good thing to simplify and make their products more efficient.

"If you get a blowout you'll just call up your neighbor Marge who knows even less about computers than you do. Unfortunately that doesn't work when your blowout occurs on I15 in the middle of the Mojave Desert."

So I guess users should be forced to memorize refresh rates and command-line parameters to launch their GUIs as preemptive in high resolutions, simply because elitists feel they should take time out of their lives to learn such things as the format of a xf86config file or the correct timings for their monitor or which version of XFree86 uses their video card without crashing. Never mind that there is an equivalent car that takes care of most of that automatically.

Most developers, including in other industries, take the time to make their products user-friendly. Only in the Linux community have I encountered people who tell me it is good to keep things complex and time-consuming because it's supposed to be better that way. This is why I personally consider Linux to still be just a server OS, although KDE is really starting to look good.

This is all my opinion, of course. :-) I used to be a complete Slackware devotee and despised Windows on principle. Then I got into the real world and saw how silly and hindering such polarized viewpoints can be. Linux has its place, but not on the desktop. Not just yet.

Re:X kicks ass, XFree86 doubly so.

[Mandelbrute]

Sorry, but it shouldn't require 40Mb of binaries

Isn't there a version of X that can fit on a floppy?

There used to be "tinyX" and I suspect there was a small X add on for the linux router project.

Also - X has been ported to PDAs.

You don't really need the drivers for every video card X supports on your hard drive, that's just the way the binary distributions come.

Re:X kicks ass, XFree86 doubly so.

[Arandir]

We have the ability to make things easier on the user. You seem to be suggesting that it doesn't matter, and that the user *should* be forced to manually maintain their computers on principle.

There is a world of difference between making things easy and making things simple. Windows has chosen to make things simple (aka simplistic, dumbed down).

Computers are complex by their very nature. You cannot eliminate this complexity. Your choices are to either make this complexity easier, through consistency, documentation and proper design, or by hiding the complexity away where no one can see it. The latter is what Microsoft has done (thought to be fair, it has done a little bit of work on the design department). But that hidden complexity is still there, waiting to jump out and bite the unwary user the first time they have a problem.

So I guess users should be forced to memorize refresh rates and command-line parameters to launch their GUIs as preemptive in high resolutions

I haven't set a refresh rate in years and I don't use any command line arguments to start my GUI. It sounds like you haven't use any sort of Unix for several years if you think that sort of stuff is still required. Get with the program.

Then I got into the real world and saw how silly and hindering such polarized viewpoints can be.

I am in the real world, and I am using FreeBSD on the desktop. I am every bit as productive as my coworkers on Windows2K.

Re:X kicks ass, XFree86 doubly so.

[jedidiah]

Adding a font will likely require a power user either way. This is my personal experience with actual WinDOS users and is shared by many others.

Perhaps you've not heard a peep out of your sister because she does nothing interesting with her machine.

Re:X kicks ass, XFree86 doubly so.

[jedidiah]

Also:

Except for when I was initially exposed to the concept of widely different fonts, I actually haven't felt much want or need to futz around with the font installation facilities of any system. When people like you point it out as such a grievous X fault, I really must wonder what their real motivation is and how often they play with fonts to that degree themselves.

Re:X kicks ass, XFree86 doubly so.

[bonch]

"If you're having problems with Linux (or *BSD) with 96 Megs, it sounds like you need to fix your configuration somewhere."

So I'm constantly told. ;-) But I don't have the time to search for the configuration problem--so I'll just use what already works.

Re:X kicks ass, XFree86 doubly so.

[bonch]

"There is a world of difference between making things easy and making things simple. Windows has chosen to make things simple (aka simplistic, dumbed down)."

What you're saying is simpler=dumbed down? Is the automatic transmission of a car "dumbed down"? If I use "apt-get" to grab something instead of downloading the source and running "make install," is that dumbed down as well? Personally, I think it's just making things more efficient and convenient.

"Computers are complex by their very nature. You cannot eliminate this complexity. Your choices are to either make this complexity easier, through consistency, documentation and proper design, or by hiding the complexity away where no one can see it. The latter is what Microsoft has done (thought to be fair, it has done a little bit of work on the design department). But that hidden complexity is still there, waiting to jump out and bite the unwary user the first time they have a problem."

Haven't had a problem yet, myself. If Windows is hiding complexity, I would say Linux is wearing it on its sleeve. And documentation is still difficult to find sometimes. Not necessarily a fault with Linux itself--Microsoft is the one who can afford technical writers--but it's still a problem.

"I haven't set a refresh rate in years and I don't use any command line arguments to start my GUI. It sounds like you haven't use any sort of Unix for several years if you think that sort of stuff is still required. Get with the program."

The most recent distro I have is Slackware 8. I dunno about you, but when I run the X config program, I enter the values manually because mine aren't listed in the menu. I was given a command in this very discussion that starts X preemptively. Usually I start X with "startx."

"I am in the real world, and I am using FreeBSD on the desktop. I am every bit as productive as my coworkers on Windows2K."

I wish I could say the same, I genuinely do. I would love to completely abandon Windows for Linux or *BSD, but it's just not feasible right now.

Re:X kicks ass, XFree86 doubly so.

[Arandir]

What you're saying is simpler=dumbed down? Is the automatic transmission of a car "dumbed down"? If I use "apt-get" to grab something instead of downloading the source and running "make install," is that dumbed down as well?

You've misunderstood me. Computers are complex not simple. There is no way to make them simple. Any attempt to make them simple will only result in the complexity being hidden, not removed. Ease of use is different, in that it "streamlines" the complexity to make it easier to deal with.

A good analogy is yours: automatic transmissions. Automatic transmissions are *more* complex than manual transmissions. But designed correctly, they are also easier to use than manual transmissions. The complexity is still there, but it's been shifted over to the auto mechanic instead of the user.

There are the equivalent of auto mechanics of computers. They're called sysadmins. Problem is, hardly anyone utilizes them. Compare Windows with the support of a good MCSE with any brand of Unix with a good sysadmin. Suddenly Windows doesn't necessarily win the usability race. KDE and Gnome start to look pretty damn good. In my opinion, if you take away the hassle of installing, configuring and maintaining the system, Linux/BSD/Unix with KDE or Gnome is superior to Windows in the usability department.

My problem isn't so much that people aren't willing to learn about their computer, it's that those who aren't willing to learn about it insist on doing their own installation, configuration and maintenance. My Mom thinks computers are easy, because I am always around to empty her trashcan when she gets a "filesystem full" error". I know other people who have sold their computer and stopped computing entirely for similar error messages that they never could figure out.

Unix may not be ready for the home user's desktop, because the home user isn't willing to pay for support. But it is ready for the corporate desktop, which already has its own support department.

Usually I start X with "startx."

At the risk of sounding sarcastic: is that really so difficult?

I would love to completely abandon Windows for Linux or *BSD, but it's just not feasible right now.

I remember when I got rid of my TV. For about six weeks I was in sheer panic mode. Only my impoverished status at the time prevented me from buying another. But after those six weeks I experienced this wonderful sense of freedom. Ditto for getting rid of Windows. Oh, I still have it around for a few games (and to figure out what my Mom is talking about when she calls me for her free support). But the freedom of actually being in control of your hardware and software is worth it.

I hear that people who switch to manual transmissions get the same feeling as well after their initial panic wears off.

Cheers.

Re:X kicks ass, XFree86 doubly so.

[bonch]

"You've misunderstood me. Computers are complex not simple. There is no way to make them simple. Any attempt to make them simple will only result in the complexity being hidden, not removed. Ease of use is different, in that it 'streamlines' the complexity to make it easier to deal with."

I guess I just disagree with you in that I don't see a problem with doing that.

"A good analogy is yours: automatic transmissions. Automatic transmissions are *more* complex than manual transmissions. But designed correctly, they are also easier to use than manual transmissions. The complexity is still there, but it's been shifted over to the auto mechanic instead of the user."

Again, I don't see the problem with that.

"There are the equivalent of auto mechanics of computers. They're called sysadmins. Problem is, hardly anyone utilizes them. Compare Windows with the support of a good MCSE with any brand of Unix with a good sysadmin. Suddenly Windows doesn't necessarily win the usability race. KDE and Gnome start to look pretty damn good. In my opinion, if you take away the hassle of installing, configuring and maintaining the system, Linux/BSD/Unix with KDE or Gnome is superior to Windows in the usability department."

I can't know what your experiences with Linux and Windows are, so I'll just have to trust that you're right. :-) But with my own experiences, Windows "just works." For instance, I've been using XP for close to half a year, and I have never seen a BSOD, ever.

"My problem isn't so much that people aren't willing to learn about their computer, it's that those who aren't willing to learn about it insist on doing their own installation, configuration and maintenance. My Mom thinks computers are easy, because I am always around to empty her trashcan when she gets a "filesystem full" error". I know other people who have sold their computer and stopped computing entirely for similar error messages that they never could figure out."

Agreed.

"Unix may not be ready for the home user's desktop, because the home user isn't willing to pay for support. But it is ready for the corporate desktop, which already has its own support department."

I agree. I don't consider Linux to be a home desktop environment at all.

"At the risk of sounding sarcastic: is that really so difficult?"

I didn't say typing "startx" was difficult, I was just responding to your "get with the program" statement.

"I remember when I got rid of my TV. For about six weeks I was in sheer panic mode. Only my impoverished status at the time prevented me from buying another. But after those six weeks I experienced this wonderful sense of freedom. Ditto for getting rid of Windows. Oh, I still have it around for a few games (and to figure out what my Mom is talking about when she calls me for her free support). But the freedom of actually being in control of your hardware and software is worth it."

Tell you what--I'll give Linux one more shot. :) Especially since KDE3 came out, I've been meaning to try it anyway.

We'll just have to agree to disagree--we both have obviously had different experiences with the two. I'll just paraphrase a friend of mine who said something I feel is so true: "Linux kicks ass, but it's written for programmers. Write it for users, and users will use it."

He wrote a post about Linux at Slackersguild: http://www.slackersguild.com/article.pl?sid=02/03/ 15/0758259&mode=nested

We'll see what happens--you got me interested. I'll give it another shot.

X rules the waves!

[YeeHaW_Jelte]

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.

Re:X rules the waves!

[sti]

Sorry but I just had to take the bait...

For 99% of computer users none of the features you list above have any meaning.

For most people the multitude of window managers is merely confusing.

I, too, can remember the good old times when the mainframes were faster than desktops and it made sense to run some applications in the mainframe with the display on the desktop. Those days are gone. For the rare occasion that one needs to control something remotely, one can use VNC over ssh.

Cross-platform is mostly meaningless since most desktop computers run Windows.

Windows already comes with a graphics system bundled, so X being free is meaningless

And I bet the MSWindows folks have some fast-action 3D games they can dazzle you with :)

That said, I have to admit XFree86 has come a long way since the early days. Good work, guys!

Nothing compared to mother nature

[Jugalator]

Men and women have lived in millions of years and we're still compatible. Ain't that cool? Mother nature must have been a heck of a designer.

Re:Nothing compared to mother nature

[Galvatron]

How do you know? Have you gone back to 1 million BC and tried impregnating a cavewoman? No? Then you don't really know if we're backwards compatible or not. Besides, there's been far less design improvement in that amount of time for humans than there has been for XFree86

Re:Nothing compared to mother nature

[Begemot]

My wife would argue, she claims that the only thing I'm compatible with is my comp.

Re:Nothing compared to mother nature

[joib]

And think about it, "Slot 1" still has an absolutely huge advantage in burst data transfer rate!

Re:Nothing compared to mother nature

[kzinti]

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

Re:Nothing compared to mother nature

[martinflack]

Hell, the last time I tried to ping my wife she gave me a protocol mismatch error!

Maybe shes's getting a DOS attack from another source. :-P

Re:Nothing compared to mother nature

[cpeterso]

Women encrypt with a one-time pad. Then they throw away the pad.

this is true. women use a new pad each month.

History Please

[shomon2]

Can anyone give a quick rundown of the most notable points in X's 10 year history? Or is there a URL that does that?

Thanks

Ale

Re:History Please

[larien]

Ok, I'll bite:

Why has Citrix surpassed X?
In what way do you mean? It is much more bandwidth friendly than X, but AFAIK it doesn't do some of the things X does.

Why has X only been a server with no attempt to make it a coherent and useable UI?
Urm, because that's the design of it? It has never made any pretensions to being any kind of UI, let alone a usable one.

Why has X been horribly unsupported by Video Card manufacturers?
For the same reason that sound cards, winmodems et al have been horribly unsupported in linux/*BSD etc.

Why does Apple whip up a better rendition of a complete GUI an order of magnitude faster than these MIT peeps?
Because X isn't a GUI and also because Apple have been working on GUI design for 20 years. KDE is less than what, 5 years old? For most of Unix's history, UI has been less important than the technical power. Now, blinkenlichts are becoming more important and the Unix/linux/*BSD community has to play catchup.

Re:Time for twm to die?

[joto]

I really hope you are joking and pretending to be misunderstanding things. I can't for the life of me understand how you can achieve this catastrophical level of confusion, and still think you can understand it enough to comment on it on slashdot. Oh wait, this is slashdot, well, I guess it's quite normal then...

Re:Hmm...

[T-Punkt]

Nobody said something even remotely like that.

But you can display the oldest "X binaries" running on your "Sun 3" on your "Alpha or PA-RISC or Intel machine" even it runs the latest and greatest X server, i.e. the protocoll is fully backwards compatible.

I bet you can even display simple X applications like xterm from today on the oldest X server for the sun 3. At least I could so with an old Sony NEWS workstation and NEWS OS (from 1990) (But sadly, starting a browser crashed the X server on the News...).

Re:Time for *BSD to DIE

[leereyno]

If BSD is dead or dying, why do you take the time and effort to write this repetitive rant about it? If you were to take out all the sentences that simply repeated "*BSD is dying" your post would be MUCH shorter. The form of persuasion you're attempting by saying the same thing over and over again fell out of favor among marketing experts during the Eisenhower administration.

Then there is the reason behind your post. Someone who was detached and objective would not bother to post something like this deep within a thread on a completely different subject. The fact that you have says that you're either selling something or at the very least that you have some sort of irrational bias against *BSD. Are you one of those people who actually thinks that it is a competitor to Linux? Linux and the BSDs are no more a competitior than Ford and Mercury are. Development work on any one of them helps all the others as well. A great deal of the code that you find in a standard Linux distribution comes straight from BSD, including portions of the kernel itself. Linux and *BSD are also very compatible on the source code level. Very few and far between are the open source apps that have been developed on linux and not ported to *BSD. Ultimately you can think of *BSD as simply another kernel on top of which your standard apps and utilities such as XFree86, Gnome, KDE, Mozilla, etc. all run. Because of this it doesn't need vast numbers of users to keep it going because it benefits equally from all the development done to create apps for Linux.

If you want to rant about something, find something worth ranting about. Attacking *BSD is about as senseless as the US invading Belgium, there is nothing to be gained and Belgium is not an enemy to begin with. Why not spend some time and energy PROMOTING something instead.

Lee

More

[Anonymous Coward]

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.

Cool... not :-)

[Jugalator]

They should have used the Java pet instead, just to annoy Sun and make some headlines. :)

Relevant quote

[halk]

"Mach is the biggest intellectual fraud of the last decade."
"Really, not X-Windows?"
"I said 'intellectual'."
-- overheard in Silicon Valley

Re:Relevant quote

[56ker]

What is Mach?

Re:interesting

[Jeppe Salvesen]

Try Mandrake. But I also encourage you to check up with the graphics board manufacturer web site, and find out about your monitor timings - escpecially if your hardware is new.

I have had minimal problems installing Mandrake - until I came across a laptop with an nvidia board. I went to nvidia.com, found the linux section, and followed the detailed instructions. Pretty much a piece of cake!

Slackware is still good for learning the nitty gritties and having a rock stable system, but it is not for the command line interface challenged. It is not intended to be.

Re:interesting

[Peter Harris]

Well done man, getting modded as insightful for admitting that you have been asleep for 6 years ;)

"Me too"

[MarkusQ]

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.

Re:Time for *BSD to DIE

[complex]

dude, you just got trolled.

Re:X sucks :)

[Bazman]

You dont have to deal with several hundred students using Xterminals...

- it's flexible, meaning each of our lecturers wants the students to use a different window manager, and the students edit their .xsession and window manager configs until I haven't a clue what does what and can't help them sort out problems.

- 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

Re:You're right...

[psamuels]

X is the best thing around that meets the exact specifications that X does.

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.

Re:10 years of binary compatibility

[elflord]

Everyone is using 2.95 because the 3.0 series still has critical ABI bugs, so the distributors won't include it. 3.1 will be out very soon, and should address these issues

Re:Still binary compatible.... and....

[psamuels]

still a monolith!

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?

Binary compatible?

[Adnans]

Only if your Linux system supports the old a.out exec format and the ancient libc installed, no?!
Go ahead, grab XF86-2.1-bin.tar.gz and see if any of the binaries run :-)

/tmp/bin$ file xload
xload: Linux/i386 demand-paged executable ZMAGIC), stripped

-adnans

Re:color depth

[Junta]

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.

The wisdom of "fortune"

[dave_mcmillen]

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.

Re:The wisdom of "fortune"

[daeley]

Here's a few more:

Accept any substitute.
Form follows malfunction.
The Cutting Edge of Obsolescence.
The trailing edge of software technology.
Making the world safe for competing window systems.
Let it get in YOUR way.
The problem for your problem.
If it starts working, we'll fix it. Pronto.
It could be worse, but it'll take time.
Simplicity made complex.
The greatest productivity aid since typhoid.
Flakey and built to stay that way.

Re:binary compatibility

[k98sven]

MS windows retains compatibility with 20 year old DOS programs and they are considered behind the times,
but XFree86 retains compatibility for 10 years and it is "impressive"?

Apples and oranges..
DOS is a 16-bit operating system for 16-bit processors,
the argument against DOS compatibility was that
to do this, Windows had to include a lot of 16-bit
code, instead of being fully 32-bit.

This caused windows to be notoriously unstable,
(WinNT on the other hand, is fully 32 bit, which
is one of the reasons 2000/XP are more stable
than the old 95,98,Me branch)

X never had any such problems.

Retained backward compatibility is impressive, because it is an indicator of a good original design. (in the X case)
But backward compatibility that serves to retain a flawed design is bad. (the windows case)

RFC 2671, RFC 2980

[marnanel]

DNS: see RFC 2671. It uses a label type that was deliberately reserved in the original standard in order to send extended information, and a new resource type, OPT, that lets you advertise what extensions you support and to send more kinds of request than could possibly be encoded in the original standard.

NNTP: see RFC 2980. (The extension mechanism seems to be that if the client sends an extended command that's not recognised, it'll get an error. :) )

What's in it for me?

[Jupiter9]

I want 3 of those 10 years back for wasting so much time trying to get my XF86Config file to work right.

Re:color depth

[HeUnique]

You're talking about RandR support. It's coming (maybe in XFree86 4.3.0 - don't know for sure), but it will allow you this exact feature, and you can also rotate your screen (90, 180,270 degrees)..

Still slow on DSL lines

[Anonymous Coward]

Let me express my obeservations of performance and buginess of X11 applications.

X11: Even with compression it's still extremely slow on DSL lines. The main performance consumer are a mouse cursor and graphics.

X11: I've tried it also through 10Mb hub in LAN - works good to read mail in VM mode of XEmacs, as for GNOME - it sucks, a lot of bugs and error messages.

X11: Also, on both 10Mb and DSL, Mozilla's drag-n-drop behaviour becomes unpredictable. Without drag-n-drop Mozilla works fine.

X11: On 100Mb networks works fine with some annoying behaviour of GTK. Generally GTK and GNOME specifically is not good to run cross network - it seeks for some local resources, like audio, CORBA, which are different on different computers.

VNC: Comparing to VNC on windows platform on same lines and speeds: VNC is much slower in lots of situations.

Web: Comparing to HTTP/HTML on same lines and speed: X11 is certainly worse. However, the application base of X11 is still broader, although the rate of new-coming web-applications is much higher.

Conclusion: X11 is better than VNC on slow lines, but much slower than Web, but X11 and VNC are for different platforms. As for web, web is much more optimal for slow lines. Eventually, when virtually everything will be Web accessible - X11 as a network protocol will dye. But it will stay forever as a layer between desktop applications and X server drivers. Probably, instead of the war of GNOME and KDE, we may see something like a war of Mozilla and Xemacs desktops :).

P.S. GNOME is designed against networking principals of X11, probably, b/c GNOME designers want to see GNOME working without X11. Bad for GNOME (all driver problems) and bad for X11 (good application is gone).

Re:You're right...

[4of12]

network transparency

It's nice, but maybe it could be extended even further.

I mean, I'm usually stuck with

XDISPLAY=myhost:0.0

and get the keyboard and mouse lumped together with the screen as local devices connected to one X server.

Perhaps there's something I'm missing about the flexibility of X, but in this day and age it seems like everything should be capable of being a networked device.

Can I, with X, set my keyboard to be one networked device, my mouse to be another networked device and the screen be another?

(As wireless networking takes off, this seems like it could be more useful than it sounds. A keyboard with its own IP address and port sounds a little bit silly.)

Broke it for this...

[SmittyTheBold]

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.)

Re:You're right...

[psamuels]

Can I, with X, set my keyboard to be one networked device, my mouse to be another networked device and the screen be another?

No - not yet anyway. It is interesting to look at how the X display model has held up over the years. As most of you know, the DISPLAY=myhost:m.n specification allows for multiple hosts (addressed by TCP/IP), multiple display servers per host (doing business on separate TCP ports, 6000+m), and multiple screens per display. Each display has a single set of input devices, which is shared across however many screens it has.

The X protocol designers clearly saw the need for multiple display servers per machine, and this is used for many things - most often, perhaps, running multiple X sessions on a single head, which you can switch between, but also running "fake" X servers which are actually tunnel endpoints with ssh or lbxproxy. However, the multiple-screens capability has mostly gone unused - since it would force an application to specify a particular screen number when drawing a new window. Applications shouldn't have to care about confining windows to particular monitors, so the usual solution is for the X server to present a single logical screen (SLS) larger than any one physical screen. This is one of the few instances I know of where the X protocol turned out to be too general.

OK, back off the tangent. What you propose is sort of the opposite to the screen model, and it won't work, at least not the way X is designed currently. Basically, all applications on a desktop have to use the same core pointer (mouse) and core keyboard. Why? Because the X server is only geared to showing one mouse pointer on the screen, and the window manager must know unambiguously where it is at all times so it can raise windows to the foreground, switch input focus, etc. And speaking of input focus, there is no provision within the ICCCM [the standards and guidelines for X window management) for keeping track of application keyboard focus with multiple keyboards possibly targeted to multiple applications.

In short, the keyboard and mouse must be common to all clients of a specific X server. That in turn implies that you couldn't set a client variable to use such-and-such a mouse or keyboard, since there's no way to guarantee that all clients have the same variable set. You'd have to configure it at the server end.

Which isn't to say you couldn't write an X input driver that internally gets its data from TCP/IP or bluetooth or something....

Re:color depth

[warlock]

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...

Backward Compatability of X

[lostchicken]

Will we be able to say the same about Perl in a few years?

If I understand the idea behind Perl 6 right, it won't quite run Perl 5 unless you compile the P5 code and decompile it to P6. If this happened to XFree86, wouldn't we see it as a stain on its history?

Let's try to make sure we can run this announcement (backward compat for 10 years) for all our projects.

Re:color depth

[spitzak]

The problem with X (at least when in 8bpp mode) is that the programs have local storage of a "colormap" where they know "this number produces this color". There was no mechanism in X so that the server could say "throw away your colormap and start over". Even if there was, there would probably be many programs that did not work because they were never tested with such changes (Windows had such a mechnism but it never really worked for exactly this reason).

The real solution is to have "true color" where a program does not keep track of a colormap, but instead asks for a color directly and the server does whatever it wants to get that color (such as allocate it from a colormap).

X supported this but had a serious design flaw: the calls for true color only worked when the screen was in true-color mode. You still had to manage colormaps if it was not in this mode. Since virtually all screens then had colormaps, most programs did not bother with the true color calls, or they made buggy untested versions.

When True Color became practical people quickly discovered that 90% of their programs did not work. Most manufacturers (Sun, for instance) were forced to add hardware to their cards so that some pixels could be in true color while others were in colormap. It wasn't until XFree86 started doing true-color on PC cards that lacked such hardware that programs started to be rewritten so that colormaps were not necessary.

Why did Windows not have this problem? In fact it was due to a good design decision, of the type that the X people seem to seriously lack the ability to make. The "true color" calls worked even when the screen was in colormap mode!. This meant that a program that just wanted a color worked when the screen was set to full color. Only programs that wanted to do funny things to colormaps failed, but on Windows this was only a small percentage of them (mostly games).

Why didn't X do this? It was due to a weird type of stupidity: The Windows version, when asked for a random color, produced a halftone of a fixed colormap, which looked horrible. But there were 64 (16 on early versions) of colors that looked good on all displays because they did not halftone.

The X people probably thought of this design, said "only 64 special colors looks good, while with our design the programmer can choose any set of 64 colors, and we won't implement that less-powerful design, besides they can always emulate it atop our design"

People writing Windows programs, however, said "I can use this complex mess to manage colormaps, or I can use this nice simple call to get a color." They then try it, and say "well, only these 64 colors work." But then they don't say "that sucks, I better learn colormaps". Instead they fix their program to only use the nice colors! And their programs worked right away on True Color because Windows had provided the stupider and simpler interface, and not worried that that interface could not do "everything".

I sincerly hope the X developers will learn something from this about what a good interface is. But from what I am seeing come out of there, I'm afraid it is not happening.

Re:Better headline for the story

[AJWM]

Heck, I was programming X back when it was X10. (X version 10, that is.) I suppose one of these days I should learn how to do without X10's XAssocTable stuff so that I can stop linking with -loldX.

Re:Time for twm to die?

[spitzak]

You seem to be confused. TWM is a possible window manager but is not required. In fact Gnome/KDE replace it with their own window manager.

It may make sense to question the idea of having a window manager at all. It seems quite possible to implement the windows in the toolkits and reduce the complexity to a "task manager" that only needs to be running if the user wants a list of running tasks. Yea, the window borders will look different depending on the toolkit, but I don't think it will be that bad, and it might lead to designs where there are no window borders.

Re:You're right...

[Arandir]

For most of us the killer feature is network transparency.

Absolutely! Those sitting at home with single boxes connected to nothing but their ISP will never know the utter usefulness of this.

I'm running Adobe Framemaker 6 on my FreeBSD box. How? Easy. It's called network transparency. The application is actually running on my Solaris box, but being displayed on my FreeBSD screen. Ditto for Clearcase, ClearDDTS and Rational Rose. Screw that old horrible Sun monitor that makes your eyes wither into dust, I can use the glorious Sony Trinitron on the Dell GX240 instead!

Sub7 ?

[cpeterso]

what is Sub7?

Re:Sub7 ?

[Shiny Metal S.]

what is Sub7?
It's a Trojan Horse.

Re:binary compatibility

[spitzak]

Many old X apps that assummed colormaps will not work on a TrueColor only (or TrueColor default visual) server. Typically they truncated the returned color to 8 bits so the colors they drew were totally wrong. This error is inexcusable (and does not exist in Windows) and is typical of the bad design of X. A sensible system would allow the program to set the current color by rgb values.

Also common is assumming an image could be built in 8 bits per pixel, assumming it could blink everything that was one color by changing a colormap entry, or that various colors could be produced by xor'ing pixels. These would naturally happen if programmers assummed colormaps, and these problems also exist in Windows programs.

In any case the fact that no extension was added for about 10 years is not something X can be proud of. The problem is that everybody who wrote an extension refused to write code to emulate it on old servers, instead insisting that programmers write code to detect and use the extension, and forcing them to emulate the extension if it was not found. It was easier for programmers to just emulate the extension (with modifications they wanted) and ignore it. For this reason nothing appeared for years and years.

Only recently has Xrender been added and started being used commonly. But even there it is a pain, you have to check for the extension and figure out how to draw everything two ways. However Xft (the antialised font stuff) does have the ability to work on systems without Xrender, for this reason almost everybody is working on antialiased fonts, but nobody is using the rest of Xrender.

BTW, a question

[bonch]

How do you feel about OS X? Just curious.