Slashdot Mirror


XFree86 10 Years Old

ChazeFroy writes "XFree86 is now 10 years old. To quote from the page, 'What makes this particularly eventful is that it is fully backwards compatible; this is a true testament to the spirit of the original X protocol of which XFree86 is its finest implementation.'" Ten years and still binary compatible. Very cool.

5 of 438 comments (clear)

  1. Re:Seems a bit... odd by Baki · · Score: 5, Insightful

    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.

  2. Re:suggested X changes by Khazunga · · Score: 3, Insightful
    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.

    --
    If at first you don't succeed, skydiving is not for you
  3. Re:X kicks ass, XFree86 doubly so. by aulendil · · Score: 3, Insightful

    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

  4. Re:X kicks ass, XFree86 doubly so. by psamuels · · Score: 5, Insightful
    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.

    --
    "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
  5. Re:X kicks ass, XFree86 doubly so. by Pope+Slackman · · Score: 3, Insightful

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