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

[linzeal]

1024x768?

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

[fktup]

Oh do I! Sometimes when I help someone new get 3D working under Linux I reflect on those days. When I bought my first computer I returned my windows CD and they gave me a 150$ rebate. Spent 2 weeks editing that stupid file *sigh* Say did you blow up any monitors back in the 90's? hmm shouldnt rant incoherantly on slashdot after a coding binge. -- note to self

Re:Much more importantly

[BiggyP]

we call that the Debian Potato method :P
but hell, it's more fun than having X set up automagically during installation, mandrake's just plain cheating.

http://www.vmlinuz.freeserve.co.uk/

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

[Anonymous Coward]

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

I've been thinking more about Berlin and it's not really necessary. Software evolution tends to work better, and Berlin is unnecessary right now. KDE and Gnome will become resolution independant if given enough time, and because they'll step there slowly like evolution they'll bring many more developers with them than if it were a revolution. I mean when you've got all letters in vectors, and all icons in SVG, then you've got very little left that needs to be resolution dependant. Bitmap images can be scaled - they are already in Opera. The placement onscreen is currently pixel based but there's no real need for that and given time that could be changed. I used to hope for Berlin but it's just too slow moving, and there are other ways there. KDE and Gnome will get there first.

Re:Much more importantly

[nomadic]

I remember that moment after I had finally gotten the configuration files working. That sudden burst of ecstasy, quickly broken by the sight of a grey screen and the realization that now I would have to spend time configuring the windows manager...

The problem back then is the monitors weren't so robust; you could seriously damage one by getting the syncs wrong. Nowadays you just get an invalid signal message.

Course, once you did get it working you realized just how bad windows 3.1 was. I remember having a scrolling desktop with an animated background, multiple windows open. On a 486-50 with 10 megs of RAM...

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

[ymgve]

Why it didn't have 'standard' 1024x800 screen mode, I'll never know.

Because as far as I know, 1024x800 is not standard. 1024x768 is. :)

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

[lfourrier]

already trying to diminish risk of Tempest with a non standard resolution?

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

[mysty]

xvidtune does that and sax2 too

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

[JSR $FDED]

Ten years, still binary compatible and completely outdated and dead in the water.

I guess we have all learned something today.

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

[PissingInTheWind]

You can get xroach as a RPM here.

Re:Much more importantly

[Anomie-ous Cow-ard]

with some ancient S3 chip, and TWO WHOLE Mb VIDEO RAM!

That perfectly describes the card in my machine right now... *sigh*

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

[Arandir]

Funny, last time I checked out Mandrake, it kept insisting that my Matrox G450+ was a cheap generic framebuffer device. Nothing I could do would convince it otherwise. I never did have the patience to dig deep enough to see where it kept overriding my manual settings. Frankly, if DrakX is what is going to save Linux, then Linux is doomed...

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

[wizbit]

It's much like installing Windows 3.11.

You mean it comes on floppy disks and makes you use an ugly GUI?

:)

Re:Much more importantly

[psamuels]

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

Not nearly as easy as it used to be. Sure, there are plenty of stupid 'xhost +' users still in the wild, but thanks to the rise of single-user Linux boxes, many distros actually default to the X server not listening on TCP/IP at all! Good for security, bad for people with xroach.

(Ahhh, fond memories of xflip, xterm -e 'echo foo; sleep 5' (aka poor man's instant messenger), NAS, ...)

Re:Much more importantly

[Arandir]

Actually these boxen are Solaris machines. They all used to be wide open. But we recently upgraded to Solaris8 and the default is not to secure the display. Oh well, I can still tweak with the LynxOS lab machines...

Re:Much more importantly

[Anonymous Hobo]

Try xeji for more of that on-other-peoples-DISPLAYs fun.

Re:Much more importantly

[Jeremiah Cornelius]

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

Re:Much more importantly

[Anomie-ous Cow-ard]

PCI, S3 ViRGE to be precise. Works well enough as long as i don't try to do fancy graphics...

Re:Much more importantly

[BiggyP]

and it is entirely possible to setup such a machine and do real work on, i'm not saying there is anything wrong with mandrake at all, just not as good a way to explore Linux, besides, when the next proper release apears i'd expect it to be able to rival at least red hat 6 in the installability stakes.

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? ;)

Re:Sure, but...

[AVryhof]

hehehe, that Puppy comes from MS BOB so I guess it wasn't a total flop....just had to wait and resurface when more dumb people were using computers.

Re:Sure, but...

[linzeal]

I believe einstein will help you out if you ever get stuck using office. Just change the ms agent from clippy to einstein, he genoiuyus!!!

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

[AVryhof]

A clipboard supplied by X itself so the Window manager doesn't need to supply one.

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

[Anonymous Coward]

Er... the window manager doesn't supply a clipboard. The X selection mechanism does - it's major problem is that, for reasons of statelessness for easy network-transparent operation, the "cut"/"copied" clipboard only lasts as long as the source - i.e. there's no independent "buffer" for the clipboard - it was always the X designer's intent that a clipboard daemon be used (just like the one that is deeply buried on windows, BTW), but people didn't progress it beyond the proof-of-concept xclipboard, which only handles text/* mimetypes..

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

[prefect42]

I think you're highly confused as to the role of the X server and that of the window manager.

Integration of everything into X isn't the answer you're looking for.

But if you think it is, fine, it doesn't require anything major, since the pluggable design of X allows you to add what you like.

I remember from a discussion on the design of X, the designers suggesting that even the basic primitives should be modules, but decided that a windowing system that was unable to draw a window without a plugin was a bad idea... ;)

jh

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

[fredrik70]

It's unfortunatelly not as simple as just hiding the underlying API, Sometimes (like the top menubar you mentioned for example) KDE and Gnome got a completely different way of working. Even *if* they used the same API calls they do not use them in the same manner. They got different ideas from each other and implement things differently

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

[FooBarWidget]

I do.

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

[Iffy Bonzoolie]

Maybe we don't want a standard toolkit library, but perhaps we want to expand the set of "hints" that a window manager can give to client applications through X system to include look-and-feel information (like themes, menu bar location, etc...) Ideally you would have a system where it would be easy to define new hints, but you also don't want similar hints defined differently by different WMs. You also want these hints to be arbitrarily complicated, perhaps containing (at least a pointer to) an image or somesuch (like a widget background). Lastly, you want clients to be able to ignore hints that it doesn't understand (thus the name "hint"). Any language that can implement an X application should be able to read and understand these hints.

-If

Re:suggested X changes

[psamuels]

Instead, good ol' X11 once again accomplished it's primary mission -- keep the protocol open while still finding a way to encourage propreitary lock-in for the applciations. Maybe KDE/Gnome ain't as "proprietary" as their commercial forefathers, but your post illustrates that the situation hasn't improved much since the last widget war.

I'm not sure quite what you mean to imply by the term "widget war", but really - it's not so much a war as, perhaps, an archery competition. Nobody is being hurt by the proliferation of applications under both the GNOME and KDE frameworks. It appears to me that both projects have a rich, mature library environment and rapidly maturing development tools - fragmentation doesn't seem to have hurt there. Lots of KDE users use Gnumeric and Mozilla, and lots of GNOME users use KDevelop. Developers don't even have to worry about picking the "right pony" - the two widget sets are easily compatible enough to coexist on one's desktop. (They look a lot more harmonious together than Motif versus OpenLook!)

The "KDE/GNOME war" was pretty much invented for TV, as it were. The mass media love to find a rivalry to report on. Ask any of the actual hackers involved about "beating" the "other team" and they'll probably laugh at you. The war is waged more on public fora like Slashdot among mere end-users than anywhere else - just like any other modern holy war.

Re:suggested X changes

[fredrik70]

hmm, funny how my comment earlier could be a flamebait..
Well anyway, I was more thinking of having all object already on the X Server an x-client just telling what object(widget) thay want and were.

Don't know much about X if I should be honest, but does X compress the info it send over? Would that be of any advantage?

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

Re:suggested X changes

[andrewski]

Actually, dd is perfectly suitable for backups both remote and local, of varying types of media in a variety of cool ways. You may not use it 'anymore', but I suspect that's because you haven't used it in the first place.

"X"Free86

[popeyethesailor]

Now the X has another meaning :)

Re:"X"Free86

[mosschops]

I've always thought the 'X' meant 'Close'. Oh wait, wrong window system...

Re:"X"Free86

[sebol]

It's now pronounced as 'Ten'Free86 ?
'Ten'Windows?

Re:"X"Free86

[Dwonis]

But does NP = 7 ?

Re:"X"Free86

[hconnellan]

Could be true if N=1

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

[psamuels]

It is not really binary compatible, but protocol compatible.

Right you are. But note that binary compatibility goes back to the original release of X11R6, which happened in April or May of 1994, if I remember correctly. That's assuming you still compile against the same C library, of course - and most of us moved away from libc4 some time ago.

Maintaining compatability is just as simple (OK a bit less since it is a complex protocol, but the extention mechanism was very clever)

Agreed.

as backwards compatability for ftp,nntp,dns etc.

Note that SMTP, FTP and HTTP have nice extension mechanisms as well. (SMTP: the ESMTP EHLO response lists all supported extensions. FTP: the HELP command lists all available server commands. HTTP: you can do just about anything you want with extra headers / header flags.) I don't know about NNTP (probably a similar extension mechanism to SMTP) or DNS.

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.

Whooooo!!

[XfleckX]

haha for a second I was gonna say "hey way wasn't X started in the mid or late 80s?!" but then i realized we're just talkin about X*FREE*86 here not X11 itself. woops. but why did i share my idiocy anyway??? whatadork.

color depth

[Anonymous Coward]

It should be possible to change colordepth in runtime!

Re:color depth

[justsomebody]

And for automatic
XVidMode extension

Re:color depth

[WWWWolf]

Err CNTL-ALT-+ ? Have you set your resolutions up in your config?

No, color depth, not screen dimensions.

Once X is started, AFAIK you can't change from the bit depth. Usually this isn't a problem, but when running on >16bpp and using programs that absolutely insists on using 8bpp (such as the original abuse.x11 - thank God for Abuse-SDL! =), there's no other way except to restart the server OR run multiple servers.

That's not an issue to deal with too often, fortunately, but I'd love it if screen resolution could be changed on the fly. And when I say resolution, I mean DPI, not screen dimensions (that's what XVidMode and Ctrl+Alt+(+/-) are for =)

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.

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

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

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:color depth

[crazney]

You talk with me too much, Hetz ;-)

David.

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.

[bonch]

I wish I could be as excited about XFree86, but for all the years I've used it, it still doesn't touch the responsiveness of my Windows computer. I'm not trolling, just stating my experiences. Simply dragging an X window in any window manager for me creates a trail of artifacts behind it that I can see being drawn over. This is on my 266mhz. On my old 66mhz, on the other hand, Windows 3.1 is smooth and responsive. I'm not even going to go into the complexities of configuring X, which has thankfully improved a bit over the years but not by much.

I just wish XFree86 was faster and easier to use. Needless to say, Linux remains in text mode most of the time whenever I use it. Hopefully, I'll have better experiences with XFree86 on better hardware.

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.

[fredrik70]

IIRC the highest priority task in Windows is driving the mouse pointer. Isn't the mouse hardware interrupt driven under windows?

Re:X kicks ass, XFree86 doubly so.

[HeUnique]

And neither of them got the vast driver support that XFree got, and neither of them does video and 3D as XFree offers. BeOS surely offers 3D - but the drivers it got was good 3 years ago. DirectFB doesn't give you 90% of your card's features (maybe accelerated 2D if you're lucky, and some video support - nothing like XvMC extension)..

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.

[r3dn3rd]

"X was X before X was cool" - My friend Justin Happy Birthday X.

Re:X kicks ass, XFree86 doubly so.

[TRACK-YOUR-POSITION]

I would gladly give up network transparency (which I haven't used since I left college and VNC-type stuff is a fine enough replacement for) for the ability to change resolutions (and desktop size) without closing all graphical applications. That's how little I care about network transparency. Speed doesn't really bother me that much, but there is defintitely no elegance whatsoever in any of X. There are NO nonproprietary useful old X windows apps. X is why my mother will never, ever be able to run Linux.

Hopefully we'll all abandon it when we try to keep up with Quartz and Longhorn in the future...vector based is the future...

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.

[TRACK-YOUR-POSITION]

Impossible to install. I've NEVER run X without having to edit config files by hand before I could see ANYTHING. That's just X11, not linux, not gnome, not kde--X11 alone always requires a human being to mess with text files.

It's been true for 10 years, so it seems pretty damn inherent to me.

Yes, the front end (gnome or kde) is there. But you can't get to the front end unless you're a techie.

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.

[psamuels]

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.

You may or may not be fingering the right culprit. I know, when software seems slow or unreponsive, it is very tempting to look at it, find one thing you think is inefficient, and say "that's why this is slow".

Linux is a complex system. XFree86 is a complex system. GNOME is a complex system. The basic user experience will see factors from all three affecting perceived "speed". And often this "speed" is not actually raw speed per se, but latency - which means the amount of time needed to react to an event. Linux is known to have lousy worst-case scheduler latencies - which often don't matter, but occasionally do. Latency is a trade-off against raw efficiency and against system complexity - simpler designs are more efficient (as a rule) but have higher latencies.

There is also complexity in your UI that is not X-related. The huge number of shared libraries used in GNOME, for instance, may affect startup times for your applications, making it seem as though something takes "forever" to pop up its first window. (More later.) Responsiveness while running an app can be due to system paging, or due to the speed of the IPC mechanisms - GNOME uses its own Bonobo component architecture, running over the ORBit implementation of CORBA. CORBA is widely recognised as being potentially quite inefficient, though handy to program for and possible to optimise in some cases.

Solutions: if your Linux box is too heavily loaded down, well, get a bigger machine. (Not likely your problem.) If it has unacceptibly high scheduling latencies, try either Robert Love's preemptible kernel patch or Ingo Molnar's low-latency patch (or both), both of which are designed to help with specifically this. If you think ELF shared libraries are seriously bogging down application startup times, consider Jakub Jelinek's new "prelink" program, which optimises ELF binaries and libraries to do most of the run-time linking ahead of time, a technique used successfully by IRIX for years (for the same reason - IRIX, too, uses the flexible-but-slow ELF binary format). If you are swapping too much, your applications are memory hogs and you really need more memory to support them properly. If it is the GNOME ORBit-based IPC, well, not much you can do except whinge at GNOME, or help them optimise their CORBA implementation.

Overall point being: don't be so sure it's really the X client/server network-transparent protocol that's making your mouse pointer jumpy. (Indeed, if your problem is a laggy or jumpy mouse pointer, it can't be the client/server thing, since the mouse pointer is implemented entirely by the server.)

Re:X kicks ass, XFree86 doubly so.

[TRACK-YOUR-POSITION]

That's why I added "and desktop size". Meaning I've never found anyone who likes that XFree86 "virtual desktop" feature (not talking about that multiple desktop idea that a lot of window managers have, is definitely a point in X's favor.)

Re:X kicks ass, XFree86 doubly so.

[TRACK-YOUR-POSITION]

Maybe you should run VNC over the 56k modem, because over 100BaseT X is slow and choppy for me. ;)

Re:X kicks ass, XFree86 doubly so.

[TRACK-YOUR-POSITION]

X is actually very elegant, for everything except drawing ...

Wait a minute, what else is it supposed to do?

I guess all things considered, for being more than 10 years old, Xlib is certainly more elegant than Win32...

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]

My card is a Voodoo 3. I've posted about this before--how anytime I mention the slow performance of XFree86 for me, it's always about drivers or misconfiguration. Ah, well. Like I said, I'd love to try XFree86 on better hardware than what I've got! The slow performance of XFree86 is the only thing stopping me from adopting it as my main desktop instead of Windows XP.

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.

[aussersterne]

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.

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?

Re:X kicks ass, XFree86 doubly so.

[Arandir]

If you're running Windows XP on a 266Mhz and you're getting smooth responsive behavior, then please tell us what wonderful shit you've been smoking...

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]

It must be the memory, so that it avoids the horrendous swapping one gets on the typical 266Mhz with 16Megs.

I had a 100Mhz with 16M and Linux was very slow. Oh the GUI (windowmaker) was smooth and responsive, but once I loaded up Netscape and a couple of other apps, the latency was nasty. Then I upgraded it to 32Megs and all the problems went away.

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

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.

Time for twm to die?

[ramoth4]

TWMis old. Nobody really uses it. Sure, GNOME and all the other WMs sit on top of it, but it seems to just slow X down for me (I'm running it under XDarwin on my G3). Why not just make it a bunch of Libs instead? Or am I misrepresenting this? Just my 2

Re:Time for twm to die?

[shippo]

At least you've got TWM working under XDarwin. For me it segfaulted every time I tried it on my iBook.

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:Time for twm to die?

[psamuels]

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

He or she probably conflated "twm" and "Xaw" aka the Athena widget set. Not that there are all that many "modern" programs still using Xaw, outside the X distribution itself, but that's my theory.

and still think you can understand it enough to comment on it on slashdot.

Heh. As you say, this is slashdot.

Re:Time for twm to die?

[WWWWolf]

TWMis old. Nobody really uses it.

Erm. Obviously you don't deal with multiple X configs. =)

Personally, I had a "game setup" once that ran "lighter" X11 session, and all excessive services on my machine were turned off. What WM, you may ask? twm. Didn't want WindowMaker to affect my framerate =)

Nowadays, I consider setting up a separate "movie player" setup (because nVIDIA drivers screw up the XVidMode stuff when using TV-Out, so I can't really play games if TV-Out is enabled all the time!) - again, twm would be just fine for that setup.

Sure, GNOME and all the other WMs sit on top of it,

None of the other window managers depend on twm! If you don't like it, you can remove it =)

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:Time for twm to die?

[ramoth4]

After a little bit of reading, and the helpful replies of /.ers, I've figured out my error. I wasn't BSD biased, or angry or whatever. I was just mistaken, probably due to XDarwin (I lauched GNOME from twm).

Anyway, I love Open Source stuff, and I think that /. IS overpopulated with dumbasses, just like the rest of the net. Oh, how I long for the days when only people with brains could get on the net.

10 years of binary compatibility

[PSC]

Ha! Now that's an aim for the G++ guys to shoot at... :-)

(Yes, yes I know the GNU C++ compiler isn't ten years old yet, but that's the least of hindrance :-)

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

BACKwards compatible..

[sudog]

I doubt if it's binary compatible..

You're right...

[brooks_talley]

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

Heck of a job, that.

-b

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:You're right...

[prisonernumber7]

Didn't Microsoft Windows get all that graphical network-access with Sub7 a long time ago already?

:)

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

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: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!

Re:binary compatibility

[Komarosu]

but Windows is not 100% compatible with old DOS apps. tbh i think you will struggle to run anything created before DOS 5.0 and anything that uses special graphical extensions.

On the other side, ive not seen a old X app that wont run on the newest server version.

Please prove me wrong if u want :)

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!

Re:Sitck that DOS up in your ass!!

[Komarosu]

ahhh the maturity of it all. |m r33t Ur n0t...phht

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

[kzinti]

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

--Jim

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.

Re:Nothing compared to mother nature

[kubrick]

Have you gone back to 1 million BC and tried impregnating a cavewoman?

Yes.

I could tell you more, but I'm afraid I'd have to kill you.

:)

Re:in relation to rcs 1000's post....

[smallblackdog]

I do get laid, thanks. But still I worry about that. And don't give me any of that young man crap. Heh.

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:History Please

[Anonymous Coward]

okay.
http://www.cat.org.au/maffew/cat/xfree-dawes.htm l
here's an interview, a few years old now unfortunately, but it covers a bit of the history of X11. it's an interview with the XFree86 leader, david dawes.

Re:2nd post

[Goldberg's Pants]

Indeed. It's kinda cool. Ten years, and only 4 versions. Certainly not shovelware, and X4 is VERY cool indeed.

Re:in relation to rcs 1000's post....

[larien]

I can attest to how good the "benoit" drivers are; I use them on my linux firewall/webmail server and it ran solidly for almost 3 days while I was in London and I used it to access my e-mail from cybercafes there.

However, even that recommends some kernel patching (HDLC stuff) which may scare beginning users. It also took me a little trouble to get working, although that's more down to my mistyping some stuff and not noticing :)

Mac...

[david_nelson]

Mac OS, 20+ years and still binary compatible. ;-)

(If this is not entirely accurate, I apologize...not trying to troll.)

Xfree86 is great -- I'm using (occasionally) it on Mac OS X.

Re:in relation to rcs 1000's post....

[smallblackdog]

Cough, ok. Maybe there is help for newbie problems. Thanks for all the links, irc channels and stuff. I'm using mandrake 8.2 and on install, it partially install it. Like, it can see the modem but when I try to dial out it says the connection failed and from there I'm lost. I'm gonna go check around. Thanks again.

Yay for the BSD license

[Anonymous Coward]

X is a model showcase for the popularity of the BSD license. It triumphs in both commercial and academic settings, just like BSD itself.

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

Windows

[barnsleyBigUn]

If you get the Windows applications from Version 1 (1983-1985) and use Borland Resource Workshop to change the resources into version 3.x resources you can still run it. Remember you need to resize the windows because Version 1 did tiling all the time!

So, is maintaining compatibility a good thing or bloat? ;-)

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.

Re:binary compatibility

[linzeal]

Try running master of magic on xp.

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:Relevant quote

[halk]

Mach is the micro kernel in the core of several failed operating systems, including GNU Hurd.

The referenced decade is of course 80's, not 90's.

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:binary compatibility

[linzeal]

Sure, I'm pretty certain its not a hardware issue (kyro,cmi8738) both which have worked with other dos games. I'm not on my winxp box (at home) only got linux and win98 at work. Does winxp besides its pretty cool compatibility mode have a way of using a seperate dos autoexec.bat and config.sys for dos programs like win98?

Dos compatibility mode, with 256 and 640x480 forced currently takes me to a halted buzzing opening screen. I would really like to get rid of my old dos/win3.1/win98 box this, master of orion and X-wing/Tie-Fighter are keeping me from donating that box.

Re:Time for *BSD to DIE

[complex]

dude, you just got trolled.

Re:binary compatibility

[jawtheshark]

Try running the original SimCity for DOS. It will start, but the character set is horribly broken: you can't read a thing.
I don't call that backward compatible. :-)

Re:Lets party

[Mark Round]

Try here.

And when you want to give it a go :- Download it.

BONE networking stack, themable GUI, new font controls, hardware OpenGL..... Yum. But you didn't hear ir from me ;)

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

Oh yes....

[jotaeleemeese]

And I have had the opossite experience.

So that leaves us where?

Re:in relation to rcs 1000's post....

[jawtheshark]

Hmmm, one of the things that is important when running Linux (or BSD for the matter) is that you have to inform yourself well before buying anything. Why didn't you research what works and what not? Honestly, I admit that having a non-working device is part of the "Linux experience" when you're a newbie. I had similar problems with a PCI ISDN card and a USB ISDN "modem". (Both bought for a Windows machine, before I got "enlightened")

I learned my lesson when I switched to ADSL, and simply bought a ADSL to Ethernet "modem". Works great, never looked back (see my journal entry here) Don't forget, sometimes it is preferrable to buy a bit more expensive equipment that will work on many systems because you never know what system you'll be running in the near future.
Oh, and we really should stop using the word "modem" when talking about ISDN or ADSL...They're not modems.

And now the offtopic part: You get laid at 16? Damnit, I'm 25 and I'm nearly never getting laid :-( Enjoy it man, abstinence is hell.

Mouse-o-matic

[Anne Thwacks]

The mouse pointer ought to be updated in the interrupt service routine, like in OS/2, so your mouse pointer is fast, even when the machine is slow as hell.

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:in relation to rcs 1000's post....

[jawtheshark]

Yes, you may have a point on not being able to choose your hardware. On the other hand, most computers come with WinModem. It would be great to get them work on Linux, but most of the time it doens't work. So people shell out good money to "replace" it.
I see the ADSL modem in the same light. If it doesn't work well enough for you, put it back in the box and buy something better. You might even be able to sell the USB version to a Windows user.
For the record, the P&T has the local monopoly here too, but they gave the choice between different ADSL systems. However the one I needed (wanted) was the most expensive one. I think it is even possible to get the subscription without ADSL "modem", and use your own. Let's say we have a nice telecom monopoly :-) Last time I checked they even had HOW-TO's posted for Linux.

Well, I spend way too much for computer parts ;-)

*waves hand*

[evilpaul13]

not trying to troll, but they could make a not network transparent version that's faster couldn't they? I don't often find myself needing a remote X session on an OS that has a useful command line interface (almost anything not Windows/Mac).

Re:*waves hand*

[psamuels]

not trying to troll, but they could make a not network transparent version that's faster couldn't they?

Check out the MIT Shared Memory Extension, standard with XFree86 for about as long as I can remember. Actually it's still network-transparent, but if the client and server both use the SHM extension and are on the same machine, they don't go through network sockets. There are similar extensions available for local access to 3D acceleration and whole-window 2D (like for movie playback).

If you want to completely avoid having separate client/server processes, then no, to my knowledge that hasn't been done. There would be a theoretical advantage in not having to construct / parse the packets, or switch contexts between client and server, but I'm not sure if the speedup would be noticeable on modern hardware.

Better headline for the story

[Engelbot]

"X 10"

A decade of the technology that would eventually bring you the pop-under ad! :-)

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.

So what???

[Pig Hogger]

Ten years and still binary compatible.

So what? Windoze is more than 15 years old, and it is still bug-compatible, too!

Re:taco's neigbor

[fredrik70]

can I sense a streak of bitterness???

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:2nd post

[psamuels]

It's kinda cool. Ten years, and only 4 versions.

Ah, but in another sense they bloated their version numbers by starting with 11. What was the original XFree86 (née X386)? X11R3? X11R4? I'm pretty sure X386 came well after the X protocol reached major version 11....

A lot of great software doesn't feel the need for version number bloat. Linux (also 10 years old) hasn't yet reached version 3 ... Apache (about 8 years old) only recently hit version 2 ... NetBSD (around 10 years old, I think) hasn't hit version 2 yet ... gcc (what, 15 years old or so?) is getting ready for 3.1 ... Mozilla (3 or 4 years old) hasn't even hit version 1 yet ... oh wait, that's not generally considered a Good Thing.... (:

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:in relation to rcs 1000's post....

[netsharc]

Google my friend, google.

other than X

[archen]

How old is TWM anyway?

Re:binary compatibility

[oz1cz]

Compatibility with a bad system is bad. Compatibility with a good system is good.

As someone once put it: "The good thing about X is that the underlying operating system is still visible. The bad thing about Windows is that the underlying operating system is still visible."

Replacing X...

[NeoOokami]

I've seen many flame wars over how X sucks and it needs to die, and all the counters, the primary being X works here and now why change? I personally don't care for using X much, but I don't advocate it's death. My question is why others are so hostile towards projects that seek to try to make something better. ANYTHING can be done better, especially after ten years. And I'm not saying people should abandon X at all, but I don't see the point in harassing the projects that seek to make their own windowing environment. I keep seeing people complain about lack of support and such and they need to remember that when XFree86 was younger it didn't have much support either. Why are so many people opposed to giving new ideas a chance? I thought the entire point of a GPL community was so that new ideas can grow in the first place?

Re:Replacing X...

[repetty]

Okay, I've noticed lots of people saying "There will be others that say X sucks..." but no one has, so I will.

X sucks.

X is probably the biggest factor suppressing the flowering of Unix and Linux and their worldwide adoption -- for all the reasons that anyone who has used it already knows about.

It X wasn't around, something much better would be. That is my point.

--Richard

Re:Replacing X...

[Anonymous Coward]

I'm surprized that the individual distros don't come out with their own version. However, I think that it would be good to keep some standards so video card developers don't have to make anymore drivers.

X has come a long way, and it still has a long way to go. But I would point the blame at the video card makers for making new video cards every week and constantly updating the drivers every month. Don't they have any review boards to check the code for all possible improvements before they sell the parts to the public. Then there would just be one set of drivers for each card.

The thing that X and the distros are starting to do is to include information and drivers on a wide range of monitors and video cards in order to install them easily.

Setting up X windows should only take 10 seconds to pick your video card, distrobution, and monitor from a list. Then the OS and games should use the video card to it's fullest potential.

Another reason to celebrate

[sjonke]

1 Year of 10 Year Old Code. Hoorah!

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

X Window_s_?

[Anonymous Coward]

I see it again and agian - XWindows - even by people who shoud have known. The name is not XWindows. Take a look at them manpage for X:

The X Consortium requests that the following names be used when referring to this software:
X
X Window System
X Version 11
X Window System, Version 11
X11

But I don't care anymore. I use X at home and hope my job decide to make MSWindows XWindows someday.

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

X turns 10

[eleven357]

I just wanted to say Happy Birthday To Xfree86. This makes me wonder what X will be like 10 years from now. Hopefully ten years from now my daughter will be asking me what windows was and not what X is.

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.

64 bit color

[Freddy_K]

Now all we need is 64 bit color!

Or how about some 40 or 48 bit color in the mean time?

Why is it that...

[CAIMLAS]

... we linux/open source folks cry "criminal!" about MS keeping old code in their OS, screwing up performance, when XFree86 has a pile of old code for legacy's sake, also screwing up performance?

I wish XFree86 would just be rewritten, with the legacy shit (and I do mean shit - from say, pre-1995, even) just ripped out. Or at least made modular, and have them rewritten to a new archatecture that makes more sense for X's current main role - desktop systems. You will not be running X on much else nowadays. There is VNC to cope with most things that remote X had the role of.

In this case, legacy is a bad thing, IMO. It hinders the quality of the product. There is no reason for X to take up so much RAM, , leak, etc. etc.

Re:Why is it that...

[Anonymous Coward]

Fuck you! X can't just take out everything, because if it did, it wouldn't be X. X is a standard protocol, and as such, The XFree86 Team has a standard to conform to.

You say the old code is for legacy's sake, and want to take it out for newness sake. Code before 1995 can't POSSIBLY be good, can it?

You want an X server re-org? You want it to be more modular? Sorry, we already did that. It's called XFree86 4.0.

Re:"XFree86 is its finest implementation"

[TheShadow]

well... since the criteria for "fine" includes being free... XFree86 is the finest by default.

Sub7 ?

[cpeterso]

what is Sub7?

Re:Sub7 ?

[Shiny Metal S.]

what is Sub7?
It's a Trojan Horse.

Re:X sucks :)

[Arandir]

meaning each of our lecturers wants the students to use a different window manager, and the students edit their .xsession and window manager configs

Students should be taught to follow orders! Damn them and their independent thinking!

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.

I'd be much happier if they didn't "fix" things...

[BlueTT]

I love the XFree86 servers, but I'd be much happier if they didn't decide they had to "fix" things.

A good example of this is the XFree86 Xaw widget library. They broke some functionality ("auto" scroll bars appearing when a text widget was smaller than the size needed) and changed other bits of it with the net result that an Xaw application that's been around forever not only doesn't work right when compiled with their libraries, it also dumps core.

The same app, of course, works wonderfully when compiled with the official X11R6 version of Xaw from x.org.

The funny thing is, XFree86.org still ships xmh with their distribution, despite the fact that it no longer works after their changes to their version of Xaw...

Re:interesting

[sejmeister]

Actually, I just burned one out a couple weeks ago. Brand new KDS flat-screen 17 incher. It emitted some foul odors and quit working. Then again, what do you expect from walmart displays?

Re:XFree86

[zapfie]

It really is a testament to....OHH, PUPPIES!

I really wish people would actually FINISH their.. hey, was that a penguin?

BTW, a question

[bonch]

How do you feel about OS X? Just curious.

Re:BTW, a question

[Arandir]

Probably the best of both worlds. It's pure Unix underneath, command line and arcane parameters and all the other gory details. On top it's a slick interface with a hell of a lot of usability work put into it. But one is not stuck with one or the other.

The Mac user is a different breed than the Windows user. Everyone talks about how the Mac is easier than Windows, but Mac users, in my experience, have a higher tolerance for complexity than Windows users. I'm not quite sure of the reason for this, but I suspect that it derives from the overall design of their systems (pre OSX included). One example is how their respective applications are installed. Under Windows you just about have to use InstallShield or some other installation wrapper to deal with a single global registry, locked DLLs, adding menu entries to the start button, installing and uninstaller, putting a shortcut on the desktop, etc. Under Mac you just unarchive the package where you want it and it works.