Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
X GUI

XFree86 10 Years Old 441

Posted by CmdrTaco from the way-to-go-everyone dept.
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.
This discussion has been archived. No new comments can be posted.

XFree86 10 Years Old More

XFree86 10 Years Old

Comments Filter:

  • Much more importantly (Score:4, Interesting)

    by rcs1000 ( 462363 ) <<moc.liamg> <ta> <0001scr>> on Wednesday April 24, 2002 @04:07AM (#3399895)
    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...

    • On the nostalgia tip (Score:3, Interesting)

      by twilight30 ( 84644 )
      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.

    • Re:Much more importantly (Score:2, Interesting)

      by Ankh ( 19084 )
      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 [berlin-consortium.org] 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 (Score:4, Interesting)

      by aussersterne ( 212916 ) on Wednesday April 24, 2002 @04:26AM (#3399960) Homepage
      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...
    • Yes...I remember..it was around 93-94 or so. It was FUN doing that stuff. It's still fun.
    • 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 ;)
    • 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.

      • 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 (Score:4, Funny)

      by Paul Komarek ( 794 ) <komarek.paul@gmail.com> on Wednesday April 24, 2002 @10:53AM (#3401234) Homepage
      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 (Score:4, Interesting)

        by ArsonSmith ( 13997 ) on Wednesday April 24, 2002 @01:57PM (#3402576) Journal
        # 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.
    • WinDOS wasn't exactly a cakewalk in the early 90's either. People seem to have short memories regarding that.
    • 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.
    • 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.

  • Sure, but... (Score:2, Funny)

    by NetRanger ( 5584 )
    ...it still doesn't have Albert Einstein helping you search for files on your computer. You call this advancement!?!
  • 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 (Score:3, Interesting)

      by Chainsaw ( 2302 )
      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.
      • 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"

        • 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.
          • 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).
          • 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.
          • 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 (Score:5, Informative)

        by Anonymous Coward on Wednesday April 24, 2002 @05:01AM (#3400043)
        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 (Score:5, Interesting)

          by ajs ( 35943 ) <{ajs} {at} {ajs.com}> on Wednesday April 24, 2002 @09:59AM (#3400969) Homepage Journal
          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 (Score:3, Informative)

            by po8 ( 187055 )

            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 [pdx.edu], 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.

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

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

  • "X"Free86 (Score:4, Funny)

    by popeyethesailor ( 325796 ) on Wednesday April 24, 2002 @04:11AM (#3399908)
    Now the X has another meaning :)

  • Seems a bit... odd (Score:2, Insightful)

    by AaronStJ ( 182845 )
    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 (Score:2, Insightful)

      by JLTech ( 571307 )
      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.
      • 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 (Score:3, Interesting)

          by psavo ( 162634 )
          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 (Score:5, Insightful)

      by Baki ( 72515 ) on Wednesday April 24, 2002 @04:41AM (#3399998)
      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.
      • 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.

  • X kicks ass, XFree86 doubly so. (Score:4, Interesting)

    by aussersterne ( 212916 ) on Wednesday April 24, 2002 @04:18AM (#3399935) Homepage
    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.
    • 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.

      • 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
        • 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.
          • 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!
        • 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. (Score:5, Insightful)

        by psamuels ( 64397 ) on Wednesday April 24, 2002 @09:36AM (#3400868) Homepage
        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.

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

  • X rules the waves! (Score:3, Informative)

    by YeeHaW_Jelte ( 451855 ) on Wednesday April 24, 2002 @04:34AM (#3399984) Homepage
    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! (Score:2, Informative)

      by sti ( 47073 )
      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:X sucks :) (Score:5, Funny)

      by Bazman ( 4849 ) on Wednesday April 24, 2002 @07:25AM (#3400292) Journal
      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

  • 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.
    • 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
    • My wife would argue, she claims that the only thing I'm compatible with is my comp.
    • And think about it, "Slot 1" still has an absolutely huge advantage in burst data transfer rate!

    • Re:Nothing compared to mother nature (Score:5, Funny)

      by kzinti ( 9651 ) on Wednesday April 24, 2002 @08:05AM (#3400422) Homepage Journal
      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
  • 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

  • More (Score:3, Funny)

    by Anonymous Coward on Wednesday April 24, 2002 @05:51AM (#3400109)
    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.

  • Relevant quote (Score:5, Funny)

    by halk ( 139476 ) on Wednesday April 24, 2002 @06:30AM (#3400153)
    "Mach is the biggest intellectual fraud of the last decade."
    "Really, not X-Windows?"
    "I said 'intellectual'."
    -- overheard in Silicon Valley

  • Binary compatible? (Score:2, Insightful)

    by Adnans ( 2862 )
    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 [xfree86.org] and see if any of the binaries run :-)

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

  • The wisdom of "fortune" (Score:3, Interesting)

    by dave_mcmillen ( 250780 ) on Wednesday April 24, 2002 @08:37AM (#3400555)
    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.
    • 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.

  • What's in it for me? (Score:4, Funny)

    by Jupiter9 ( 366355 ) <mark&spiezio,net> on Wednesday April 24, 2002 @08:51AM (#3400613) Journal
    I want 3 of those 10 years back for wasting so much time trying to get my XF86Config file to work right.

  • Still slow on DSL lines (Score:2, Interesting)

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

  • Broke it for this... (Score:3, Informative)

    by SmittyTheBold ( 14066 ) <[deth_bunny] [at] [yahoo.com]> on Wednesday April 24, 2002 @11:42AM (#3401591) Homepage Journal
    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.)

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close