Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
X GUI

Xfree86 4.2.0 Out 438

Posted by CmdrTaco from the more-of-the-same dept.
According to david_eliasson, Xfree86 v4.2.0 is out, but it'll probably be awhile before all the mirror sites have sycned up with the release, so you may want to just enjoy reading that changelog for a couple days before you bother getting the whole archive.
This discussion has been archived. No new comments can be posted.

Xfree86 4.2.0 Out More

Xfree86 4.2.0 Out

Comments Filter:

  • 4.2.0, huh? (Score:4, Funny)

    by Anonymous Coward on Saturday January 19, 2002 @03:50PM (#2869197)
    So, who wants to smoke a bowl and celebrate?
  • I hope they made the voodoo drivers and dri more stable. Does anyone know if the voodoo drivers support sli for the voodoo5 now?

  • Radeon support (Score:2, Insightful)

    by itzdandy ( 183397 )
    so when will radeon 8500 support DRI in xfree86?
    when will there be full hardware support for radeon 8500?
    • so when will radeon 8500 support DRI in xfree86? when will there be full hardware support for radeon 8500?

      as soon as you write them. this is the point of the discussion - while there are folks like me and (apparently, correct me if i'm wrong here) yourself who don't contrubute source, it won't do everythhing.

      in the closed source world, motivation is applied via funding: the customer's demand (supposedly) drives what's paid for. in the open source, the customer and developer are the same person, (supposedly) so its actually up to us to make it work. if we don't know enough c (my excuse) we should go buy orielly books :)

      • Re:Radeon support (Score:2, Interesting)

        by Anonymous Coward
        Funding can also be applied to open-source work. If enough people want the driver, you can put your money together, find a hacker, and pay them to write a driver. Some people might do it just for a free video card.

        Getting the specs from ATI (without an NDA that would prohibit an open-source driver) is probably the hard part.

      • Re:Radeon support (Score:2, Offtopic)

        by wiredog ( 43288 )
        I wouldn't buy the O'Reilly C books. I'm a C/C++ programmer and their C/C++ books are not aimed at language newbies, IIRC.

        Actually, the C For Dummies and C++ For Dummies books are pretty good for getting the basics. Then for C get K&R and for C++ get Stroustrup.

        That all will set you back about $150, but not all at once.

      • I submitted a story detailing the ATI Radeon problems... thanks Rob... REJECTED

        Another good story down the tubes.

  • Fink (Score:2, Informative)

    by Anonymous Coward
    Yet Fink [sourceforge.net] just came out with its 0.3.2a distribution-- hopefully they'll be able to bring these packages up to date quickly, so all us OS X users can enjoy the same XFree goodness as y'all.

  • ICBW but this looks like primarily bugfixes (Score:5, Insightful)

    by StandardDeviant ( 122674 ) on Saturday January 19, 2002 @03:53PM (#2869222) Homepage Journal
    ... lots and lots of bugfixes. Glancing through the changelog extract linked to from the story, nothing really *new* jumped out at me. Not that this is a bad thing, bugfixes and increased stability/driver support is always nice. :-) I noticed a lot of things having to do with the Xprt server and having to do with 3d accel (drm, OpenGL man pages, nv driver tuning, etc.).
    • Not that this is a bad thing, bugfixes and increased stability/driver support is always nice. :-)
      Indeed. Besides which, it indicates that the XFree team is committed to the boring, unglamorous drudgery of maintaining their product. This fact is important to everybody who uses XFree, not just those who benefit from the bug fixes!

  • Moving away from X (Score:5, Interesting)

    by demaria ( 122790 ) on Saturday January 19, 2002 @03:54PM (#2869226) Homepage
    Here's a question that I want to address carefully, because it does sound a bit like flamebait.

    Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency, enhanced programming environment, and a new, well defined and examined user interface? This would be going the Mac OS X route. In this model, I am not advocating abandoning X completely, but instead for backwards compatability run a rootless X server.
    • Why move away from X? All the features you cited are available, our could be, to X thru extensions or rewritings -- except for user interface, which is out of scope of X.

      In other words, what you want is just a X + extensions + wm + destop environment combination.

      Please do your reading in the subject.

      • Re:Moving away from X (Score:3, Interesting)

        by demaria ( 122790 )
        In my original post I failed to mention that, yes all of those features do exist today as extensions or whatnots (except a new programming environment obiviously).

        Yes, I want what would be today's X + ext + wm, but is this a good and efficient architecture, or piles of backwards compatability on top of each other? How about color matching of various displays and printers?

        • Re:Moving away from X (Score:3, Insightful)

          by leandrod ( 17766 )
          New programming environment is also there already -- and alternatives too: the GNU standard is GTK++, if you thing C++ is the ultimate truth you choose Qt, if you're into Objective C or Mac compatibility you have GNUStep... I only miss a Lisp or Scheme alternative, but it's probably I who didn't look hard enough. If you are thinking imaging, then there's Display GhostScript, DisplayPDF and Display PostScript.

          And what makes you think it is bad and inefficient?

          It is no backwards compatibility cruft -- there is a core API and architecture, and extensions; any part besides the core (which is clean and efficient) can be substituted, and even the core can be rewritten for efficiency if you like.

          Color matching is also an extension.

        • Re:Moving away from X (Score:5, Interesting)

          by pthisis ( 27352 ) on Saturday January 19, 2002 @05:10PM (#2869556) Homepage Journal
          X extensions shouldn't be thought of as just being tacked on, they're a good and efficient way of doing things. The whole point was that the rendering engine would be replaced via an extension, this was anticipated and designed for.

          In fact, when X was originally developed Jim Gettys et al considered putting _all_ graphics rendering in an extension (leaving just the core windowing w/o rendering in the core). They fully expected the original rendering model to be replaced fairly soon, but that's taken a long time. XRender hopes to do that and probably will largely supplant the old rendering primitives for new apps in a few years. Maybe sooner for gtk/Qt/other whizzbang bleeding-edge stuff.


          We toyed with leaving graphics entirely to an extension, but the argument that a window system without any graphics would be useless won out pretty fast :-).

          We never thought the existing rendering would last as long as it did: we expected significant extensions would have occurred long since.

          --Jim Gettys, 2001


          We can't get rid of the core X11 primitives because they are a part of the X11 specification and all apps use it and it isn't going to go away any time soon. Once render is complete and stabilized we can just encourge people to not use the core primitives. Eventually we can care less about making them fast and concentrate on making them unobtrusive.

          --Keith Packard, 2001

          From the thread [xfree86.org]
          Proposal for server-side Anti-Aliased fonts

          Sumner

          • With all respect (Score:2, Interesting)

            by HanzoSan ( 251665 )
            X sucks at rendering compared to its competition.

            OSX totally destroys it, even WindowsXP,

            The Xrender extention is nice, but its going to take years like you said, just to get stuff like alpha channeling.

            I agree X should use Xrender extentions however what are people to do in the meantime while OSX and XP kick our asses in the eye candy department and everyone says "Linux on the Desktop is dead" Before it even gets a chance to come out of the gates?

            Whats wrong with having a directfb or berlin alternative which unlike Xrender, do the stuff you talk about RIGHT NOW.

            I honestly dont think the media will sit and wait for 2 years or more while you slowly code Xrender.

            So the option is, wait a few more years for Xrender to be completed, or check out stuff like directfb and berlin which claim to do what Xrender will do years from now.

            Whats the best option? People want alpha channeling, scaling and OSX like effects, alternatives claim to be able to do it now, they port GTK and QT, and they claim to be compatible with X.

            I think this should be discusssed more.

            • Re:With all respect (Score:4, Insightful)

              by Wdomburg ( 141264 ) on Saturday January 19, 2002 @11:41PM (#2870904)
              >So the option is, wait a few more years for
              >Xrender to be completed, or check out stuff like
              >directfb and berlin which claim to do what
              >Xrender will do years from now.

              Well, Berlin is at 0.2.2, and requires some sort of underlying graphic system - directfb, ggi, sdl or glut.

              Both sdl and glut require an underlying graphics system as well, usually X. So those two are out if you want to do away with X.

              Now on to GGI - at least the library (libGGI) is release quality. This is actually just a userspace graphics library that sits on top of an underlying system - X, svgalib, fbcon or glide.

              We'll assume you want acceleration, freedom from X, and reasonable hardware support. So out go X, svgalib, and glibe. FBcon can be accelerated, as long as it used kggi, which is currently only available from CVS.

              DirectFB also depends on FBcon, but it is does at least have what looks like a near final release.

              So, our choices are:

              Berlin on DirectFB on FBcon
              Berlin on GGI on FBcon
              DirectFB on FBcon

              We may want to nix Berlin on GGI on FBcon, if only for the sake of having something which is SOMEWHAT near completion.

              I'm not sure where you're getting this figure of "a few years" for Xrender to be completed, as Keith doesn't have timeline information on his website at all, but alpha compositing, anti-aliasing, and sub-pixel positioning are all written and included in the current XFree86 distribution. As the primary author states, the big pieces left are polygons and image transformation. Given that the initial discussions were at the 2000 USENIX Technical Conference, I'd say their progress is remarkable.

              >Whats the best option? People want alpha
              >channeling, scaling and OSX like effects,
              >alternatives claim to be able to do it now, they
              >port GTK and QT, and they claim to be compatible
              >with X.

              Xrender is already able to do alpha channeling and anti-aliased text, which are a major part of the deficiencies. Image transformation for things like scaling are forthcoming.

              The alternatives, as discussed above, are not at a final release stage, rely on a linux only graphics layer (FBcon), have a narrower range of hardware supported (or supported well), and have a signifigantly different paradigm, thus complicating porting existing toolkits.

              So is moving to a completely different toolkit, possibly with an unsolidified API, with the added headache of bringing all the drivers up to the same level of stability and performance as XFree86 already enjoys the "best option"? Or is the best option really updating toolkits to take advantage of the features available in XRender now, and planning on supporting the upcoming portions of the extension as they become available?

              Matt
      • Aah, my words Exactly, there are sensible people on /. after all.
        Really, all those raging newbies that've heard 'X11 is shit!' running and screaming it to everyone.. "Scrap it!!!11!".. And the _never_ tell what's so much wrong with X11.

        One 'minor' gripe I have with XFree86 (that is, implementation) is that it freezes all other windows while moving one. I've heard it's because XFree86 server is not multithreaded, and it's too much of a PITA to make it mt.
        • I don't see this problem at all. I can move windows and have have others update underneath. Maybe its a driver specific issue?

          Infact, what you described is exactly one of my big gripes I have with MS Window (NT4, to be specific). You just click on a window to move it (not even actually move it) and all other apps freeze. Quite anoying.

          • Damn!
            You are right. I wondered why I have such a good feeling when working on my gateway machine.
            It has a Matrox Millennium card (Matrox is still the best..) and X 4.0.2. It can move windows without suspending updating of other windows.
            My 'main' machine however has a GF2MX-PCI, and it cannot move windows without suspending everything else. X is 4.0.2(nv driver) too. That's not nice. I'll check settings.
        • I've heard (and very occasionally participated) in X bashing, but only when I got really sick of the latency in like moving windows or the ugly fonts, but hey, it's free and it's powerful and it's stable, so I really shouldn't complain. The strange thing is it just doesn't seem that much faster now on new hardware and graphics cards. I remember running it on a 486-50 with 10 megs of RAM; I could run it with an animated desktop background, and it was still usable. But on newer computers it doesn't seem that much faster.

          But, linux itself doesn't seem much faster either. Maybe I should go back to the 1.2 kernel...
          • Ages ago I planned on doing some small application that would make my desktop 'alive'. There would be one backgroud, and on top of it, there would be many small animations going on.. Mouse-activated and all.
            For example there would be some view on forest, and there would be birds, monkeys, people walking.. And sound too. You know, all high-res rendered and stuff. I even wrote all the classes and data-types for it.. But I never got around to drawing and actual programming. Damn. What a fine programm would that be..
      • This is the same argument as always. Just use the extensions. But these aren't transparent to the programmer. Applications that use them have to specifically link to them. If you wanted, for example, AA fonts in an older application you'd have to rewrite it to make use of them.

        Furthermore, why isn't window management a part of the X server? Look at all the resources that go into the writing of window managers. There are scores of window managers, and they all really do the same thing. Okay, so WindowMaker's titlebars look different than sawfish's titlebars. The look of a window border would be better served by having an advanced built-in theme engine, rather than everyone having to create a new wm just to get the look they want. Window management should be something that Just Happens. After all, there is nothing special about putting windows on a screen. All of the other things that includes such as menus and docks are outside of the scope of window management.

        In short, X is too low level and it needs a lot of things built in that are now floating around as extensions and outside applications.

    • Re:Moving away from X (Score:5, Insightful)

      by psavo ( 162634 ) <psavo@iki.fi> on Saturday January 19, 2002 @04:06PM (#2869282) Homepage
      I think we have had our share of this discussion.. =)

      But what the hell, let's do it again!

      There's nothing wrong with your suggestion. That'd be probably the right thing to to.. If we didn't have such a shitload of X11 applications.
      Actually there is nothing _fundamentally_ wrong with X11. As you can observe, even that old architecture has lived far,far longer than anyone would have expected. What it is, 20-30 years now?

      The power of X11 is in it's extensibility, XRENDER was added and traparency & antialization is now possible, Even over network, any network. TrueType fonts were needed and were added. XFree86 even had sub-pixel antialization before Windows ever had (those loonies just forgot to mention it anywhere).
      X11 is perfect example of OO separation between different tasks. Server does drawing and client does it's own things. And message passing comes 'builtin'.

      So what is really wrong with X11? You tell me.

      • Re:Moving away from X (Score:3, Insightful)

        by larien ( 5608 )
        The problem with X11 is, in part, the separation of client/server; this causes extra latency and a heap of context switches. It probably also has a lot of extra cruft that a new drawing model could avoid.

        As everyone says, though, trying to get away from X11 is very difficult as practically every GUI application on linux/Unix uses X11, so it's got a lot of momentum.

        • Re:Moving away from X (Score:5, Informative)

          by pthisis ( 27352 ) on Saturday January 19, 2002 @04:20PM (#2869339) Homepage Journal
          The problem with X11 is, in part, the separation of client/server; this causes extra latency and a heap of context switches

          The context switches aren't a significant overhead. They weren't even a significant overhead in 1986 when Sun first started spreading FUD about this (at the time, Sun was trying to push NeWs over X11). See e.g. Jim Gettys' posts in the "rendering model in X" thread in the Xrender mailing list archives [xfree86.org]

          It's not all sunshine, he's willing to own up to places where X needs improvement (exposure lists are a big one, througput for e.g. texture mapping is another), but it's way better than a lot of people claim. And Xrender and DRI address the vast majority of the problem cases very effectively.

          Sumner
          • Disclamer: I'm not a fan of MS, I'm a fan of whatever works the best for the job.

            There are VERY obvious performance differences between any version of Windows and as new of version of X as you want. X Windows programs flicker like mad when moving or resizing, objects aren't responsive, the mouse frame rate is low, applications all have inconsistent look and feel, keyboard support is lacking... And if you say that I need to tweek it to get it as fast as MS, then MS wins.

            I really want Linux and BSD's to thrive, but if they really want to become desktop operating systems, they need some fundamental changes to the GUI.

            Here's what I suggest:
            - Build new server built around a sort of COM (like ActiveX). If the COM objects are installed on the server instead of client, there will be less traffic going through pipes (less latency) and makes the GUI more object oriented at the root (remember NeXT?).
            - Separate Server and graphics drivers. Why the frick is ATI Raedon changes in the X11 change log? They should be driver changes, not server changes.
            - Design the GUI interfaces without a mouse. Everything should be accessible through a keyboard, no exceptions.
            - And speaking of NeXT, they had some great ideas on how to take advantage of 8 of the 32-bits of color.

            May the flames begin.

            Ozwald
            • One of your points address non-xfree related thing:

              Design the GUI interfaces without a mouse. Everything should be accessible through a keyboard, no exceptions.

              This is totally a toolkit issue. gtk/gnome2 has addressed this issue and everything will be easily accessible via keybaord. I'm not sure where qt/kde stand on this.

            • Obviously you are so pragmatic you failed to do your bit of learning...

              Have you any hard data to say your flickering X desktop wasn't misconfigured? Configuration is not tweaking, but most GNU/Linux distributions suck, and there aren't yet good autoconfigurators for dump people like you.

              You fail to realize that the GUI not inconsistent, it is flexible -- if you install only Gnome, only GNUStep, or only FLTK apps you get a consistent desktop; the problem here is lack of enough well written applications, as most programming effort has been into either backend code or else wasted in forks and competitive efforts because of licensing or technical issues. But here X and POSIX are a good foundation, what still is missing is a popular enough GUI side combination of widgets, window manager and applications.

              Drivers are there for performance and cleannes, and so are they there in Linux and BSD. Freezing drivers interfaces for too long creates cruft.

              Keyboardability is arriving, at least in Gnome.

              As for NeXT, have you heard of GNUStep?

              Finally, I didn't quite got your COM rant... if you want things in the server, X terminals to you!
              • Finally, I didn't quite got your COM rant... if you want things in the server, X terminals to you!

                I think he means that for example toolkits should be moved onto server side, which could be potentially faster than what we have at the moment. This could probably also be handled by simple OpenGL:ish 'DisplayList', or 'Macro' which would expand into certain graphic shape.

                This would potentially ruin much of the extencibility of X11 system as components should be installed on server before using it. So if You didn't have GTK-5 'extension' bolted on your server, you wouldn't get application to work.
                • Thanks, finally someone who understands compared to others assume suggesting COM is a trick to sneak MS technology into Linux [linas.org].

                  I'm not for destroying extensibility. Instead, I would love to see a system where objects are installed onto the server, maybe even at run-time off the web if an application needs it. Even better, a system where a developer can extend an existing control to add new functionality or build a new control off of generic objects.

                  Just a suggestion, if you guys don't like my ideas, I won't lose any sleep. Just trying to help.

                  Oh, and the driver thing too, don't forget that.

                  Ozwald
                  • Oh, and the driver thing too, don't forget that.

                    The driver thing is already there. NVidia, for one is doing it. Half-assedly, though =). (Matrox too??)
                    You are corect however, that maybe they should separate drivers from infrastructure a bit.
                    Actually the whole difference of XF86v3 vs XF86v4 was about it. (including binary compatibility accross OS). They have now all the possibilities to seperate drivers from other things.

            • Re:MS Windows vs. X, same hardware (Score:5, Informative)

              by pthisis ( 27352 ) on Saturday January 19, 2002 @05:19PM (#2869598) Homepage Journal

              There are VERY obvious performance differences between any version of Windows and as new of version of X as you want. X Windows programs flicker like mad when moving or resizing, objects aren't responsive


              If you had read the thread I mentioned in the article you replied to, you'd see the anser to this one:


              > > Not to be too non-technical...
              > > > > If the protocol overhead is so small, why can't my 1200 mips (600mhzPIII)
              > > machine resize windows without widgets streaking? My 486 could do
              > > this fine running MS Windows. Is this because many widget toolkits (GTK,
              > > QT) use XPutImage? There must be some way to speed things up.

              blame your widget set. basically (sorry owen and co on the list) gtk a
              (and i presume qt) dont render optimially at all. the do a semi-decent
              job.. EXCEPt for opaque resizing, and when redrawing is more than a few
              lines and boxes... this is a toolkit issue and imho the current set of
              toolkits (motif, qt, gtk etc.) do a god-awful job of this kind of
              stuff. right now i have silky smooth "opaque resize" stuff working here
              with enlightenment 17 - but i do the rendering completely differently
              to gtk/qt - its all a canvas and thus the rendering happens in a
              "backing" so updates are smooth. on todays hardware this is the best
              way to do it and have almots no artifacts ANd retain speed.

              > "Streaking"? Are these opaque resizes? Alot of apps aren't doing
              > event compression. They repaint the whole damn window every time they
              > get an event. They could have at least checked that there weren't
              > more events in the queue and got rid of them instead of handling each
              > one in turn.

              true. its a very bad thing that there are a LOT of apps that behave like
              this... a LOT. some of the most commonly used are guilty of this
              (netscape for one....)



              the mouse frame rate is low


              If you enable Silken Mouse in XFree86 4.0 and later, this should be fixed. Certainly an implementation issue and not an architectural issue (i.e. not a reason to throw out X and start over)

              applications all have inconsistent look and feel, keyboard support is lacking...


              These aren't X11 problems but GUI problems, GUI standardization is certainly a huge issue. But, gtk-2.0's accessibility enhancements include excellent keyboard support and some steps toward simplifying and unifying look&feel. KDE is moving in that direction as well. Obviously you need to use a single unified UI on your desktop, but having two decent ones available to choose from is not a bad thing (not to say that either is decent yet, but they're both heading there rapidly).

              Sumner

              • Re:MS Windows vs. X, same hardware (Score:4, Interesting)

                by Fnkmaster ( 89084 ) on Saturday January 19, 2002 @05:57PM (#2869763)
                Very interesting post - I agree that Gtk and Qt are probably culprits for not properly playing nice with X Windows and its rules. I think part of the problem is the fact that there never seems to have been any coherent work done on this. The windowing system oriented people who work on X say "the toolkit authors fault". The toolkit authors would say "it's your drivers or the limitations of X Windows".


                While I do appreciate the flexibility of X Windows, I honestly DON'T think the windowing system and toolkits should be these totally orthogonal projects, and the toolkits just "draw as they see fit" on a canvas that they expect the windowing system to render dumbly. This is the X model, inherited from the dumb terminal days. I have had this argument out several other times here on /., I am not a newbie or a moron, and I AM a professional software executive with over 8 years of programming experience (though admittedly not writing windowing systems or toolkits).


                I certainly believe firmly in the benefits of choice and competition, and agree with most /.ers on that. I just don't think that the toolkit is the right place for it. Linux is competition for Windows. Berlin (could be) competition for X (someday). But Gnome/Gtk and KDE/Qt as competing toolkits, desktop environments, etc. that are totally decoupled from the Windowing system? It should honestly be enough to have competing apps built on the same toolkit. A somewhat similar aesthetic for the desktop.


                I appreciate what X Windows does for us, I just don't think it's the right solution for a desktop operating environment. Because of all the X apps out there, I think anything that comes out needs X compatibility as a backwards compatible route, but I don't feel that we should look to X Windows for the future. Just my opinion.

                • Re:MS Windows vs. X, same hardware (Score:5, Interesting)

                  by pthisis ( 27352 ) on Saturday January 19, 2002 @06:17PM (#2869841) Homepage Journal
                  I think part of the problem is the fact that there never seems to have been any coherent work done on this. The windowing system oriented people who work on X say "the toolkit authors fault". The toolkit authors would say "it's your drivers or the limitations of X Windows"

                  Nope, read the thread I quoted and you'll see that gtk developer Owen Taylor agrees and that gtk 2.0 includes some of the optimization mentioned. The toolkit and X11 authors do work together on these things, and the toolkit authors have had a huge amount of input into the design of the XRender extension and the DRI infrastructure.

                  While I do appreciate the flexibility of X Windows, I honestly DON'T think the windowing system and toolkits should be these totally orthogonal projects, and the toolkits just "draw as they see fit" on a canvas that they expect the windowing system to render dumbly. This is the X model, inherited from the dumb terminal days.

                  Actually that's not the X model (BTW, X wouldn't run on a dumb terminal--even vi wouldn't run on a true dumb terminal (ie glass tty)). The X model is to provide high-level graphics primitives to the application, which then submits them to the server which can turn them into whichever low-level calls are most efficient on the hardware in question. Not only that, but the library used to submit those request can (and does) batch them together so that the application writer can have a simpler model and still get efficient code--for instance, multiple XDrawLine calls are batched by XLib into a single XDrawLines call that's sent on to the server, saving on round-trips and in some cases saving on bus traffic to the video card by eliminating redundant traffic. Or servicing those high-level requests in whatever manner is most efficient for the hardware in use.

                  Highly efficient graphics can be done this way. Witness SGI, who were for years the undisputed leaders in the graphics field. They used X11.

                  But think of X as being more of a device-driver with a unified API, the GUI is to be built on top of that. It's a highly reasonable and well considered model that is ideal for building the high-performance GUIS of the future on. Far better than e.g. a framebuffer, which is already obsolete (doesn't handle many 2D features like overlays & alpha blending, doesn't do 3D acceleration, doesn't allow for hardware security a la SGI, doesn't handle hardware video decoding, etc) and is low-level enough that you can't have the driver do intelligent optimizations without rewriting the apps. And designed with the foresight to be extremely flexible.

                  Sumner

                  • Vi is *for* dumb terminals (Score:3, Informative)

                    by fm6 ( 162816 )
                    This is the worst kind of offtopic nitpick, but I have to point out that Vi does run on a dumb terminal. There's still an entry in /etc/termcap for the LSI ADM3. In fact, "Dumb Terminal" was originally an LSI trademark for the ADM series.

                    Of course, even on a fast connection, it's painful to run vi on a terminal that lacks cursor addressing. But there's a slightly improved version of the ADM3 (the ADM3a) that has this feature. And it just so happens that the ADM3a was the standard terminal at UCB when Bill Joy was there. Which is why the first version of Vi only ran on the ADM3a. And Vi still has minor ADM3a-specific features, such as using the h, j, k, and l keys for cursor control (the ADM3a had little arrows painted on these keys).

                    Come to think of it, here we find the whole origin of the Vi/EMACS divide. Twenty years ago, UCB was a state institution with cheap "dumb" terminals, and MIT was a private institution with expensive "smart" terminals. Each institute produced a corresponding text editor.

            • There are VERY obvious performance differences between any version of Windows and as new of version of X as you want. X Windows programs flicker like mad when moving or resizing, objects aren't responsive, the mouse frame rate is low,

              Those are problems with the toolkits. None of the modern toolkits (Gtk+, Qt, wxWindows, FLTK, Mozilla, etc.) use X11 very efficiently. The redraw logic in Gtk+, Qt, and Mozilla is, in fact, in violation of X11 guidelines. The reason is that these toolkits are mostly written with a Windows GDI mindset, either because that's what their authors are familiar with, or because they want to achieve cross-platform compatibility and it's easier to treat X11 as a second-class citizen.

              applications all have inconsistent look and feel,

              X11 is not a user interface or desktop, it's a network transparent windowing system. If your user interface is inconsistent, you only have yourself to blame for it: don't run X11 applications written for different toolkits or desktops. You get similar inconsistencies if you start running Motif or FLTK or wxWindows or Mozilla applications on Windows or MacOS.

              And if you say that I need to tweek it to get it as fast as MS, then MS wins.

              I'm posting this from Galeon running on a vanilla Debian installation on a 200MHz Pentium with 64M of RAM and a 5 year old graphics card. Windows wouldn't even boot on this configuration without excessive paging, and IE is a dog. In the past, all the graphics benchmarks I have done ran faster on good X11 implementations than on Windows. So, I challenge your implicit the claim that Linux+X11 is less efficient than Windows. But even if that were the case, on 1GHz machines with 512M of RAM, any such differences are academic.

              However, the Gnome and KDE desktops are comparatively slow and resource intensive, probably similar to recent versions of Windows. I couldn't run them very well on this machine (although they do run). That is something you will have to take up with the authors of those desktops. But they, too, are designed for modern machines, where it really doesn't matter.

        • The problem with X11 is, in part, the separation of client/server; this causes extra latency and a heap of context switches. It probably also has a lot of extra cruft that a new drawing model could avoid.

          AFAIK, any _decent_ windowing system has this problem. It comes with clean seperation. Even WinNT with it's bolted-in-kernel vid drivers has to tackle this. On every windowing system the 'client' and 'painter' run in different processes, so evryone is doing context switches.

          As everyone says, though, trying to get away from X11 is very difficult as practically every GUI application on linux/Unix uses X11, so it's got a lot of momentum.

          Well, amount of _clean_ GTK+ & Qt applications is rising, and both of them can be rather easily ported to different windowing systems. And they have been (Embedded qt, framebuffer GTK+..).
          One day if someone will get really annoyed and does something about it.. Well get new windowing systems with GIMP in it =). That'd be nice. But I really doubt any performance gains.
          Slightly OT, I was really impressed by Rasterman's evas -thing, It's such a shame he left it in middle (again ;). OpenGL acceleration would really do good..
        • X11 batches requests, so the overhead of context switches compared to the overhead of drawing stuff is negligible. In fact, X11 is better off than, say, Windows GDI, which incurs similar context switches but hasn't been designed from the ground up with context switching in mind.

          Now, about latency. If you compare local access to X11 with local access to, say, Windows or OSX, I don't think you'll see practically significant differences. (Well-written applications will use shared memory for any kind of bulk data transfer.)

          About the graphics model. The X11 graphics model is complex. It really does expose a lot about the underlying graphics hardware to you and it gives you pixel accurate rendering. That was crucially important in the 1980's and has served X11 extremely well for nearly two decades. Today, it's less important, since you don't get a lot of low-depth screens anymore. I would expect that in the future, the RENDER extension will become the predominant graphics API and the core X11 graphics APIs will receive less attention. Implementing the core X11 graphics doesn't need to be a lot of code, and you don't have to worry about all the oddball bitmap formats if you don't want your applications to run with oddball display devices. But in some markets, that kind of control is important, and X11 provides it in a portable and network transparent manner.

          Overall, X11 is an old system and has accumulated some cruft. It's also a complex system because it does some really nifty things that neither Windows nor MacOSX have really tackled well. On balance, I think it's still a very modern network transparent windowing system, and if you were to design something with similar functionality today, it wouldn't look all that different or be all that much simpler. So, I vote for keeping X11, not because it's widely used, but because it's actually quite good. And I hope people will spend the time to understand X11 better. The people who designed it were very good; give them the benefit of the doubt.

      • Re:Moving away from X (Score:5, Insightful)

        by AegisKnight ( 202911 ) on Saturday January 19, 2002 @04:23PM (#2869358) Homepage
        Here's what's wrong: Deployment. The reason X has a bad image is that most Linux distros by default *don't* have good fonts. Not every app has antialiased text (although with Mozilla and KDE desktops, things are starting to change). There are a lot of technologies out there that, while technologically sound, have a bad image just because they're deployed poorly. If some upstart Linux distributor built a completely solid desktop experience (WITH *good* TrueType fonts, not just allowing you to import them from your Windows install), the whole image of X would change.

    • Re:Moving away from X (Score:3, Interesting)

      by redhog ( 15207 )
      You do not want to merge the widgetset and the windowing engine, as (drawing) area clipping and buffering has absolutely nothing to do with each other. In addition, do you honestly think that would help the adoption of the new system? It would just be a new war such as the Gtk/Qt/Athena/Motif/Tk one. But including the windowing engine. Imagine if you could not run a KDE app inside your GNOME desktop!

      I see the need for two things:

      a) a new windowing server supporting partial transparency, anti-aliased text, non-horisontal text, virtual colour-depths (that is, that the app wouldn't know what the real colour-deph was, so that they could be moved between displays with different depths without noticing it) and moving of clients bweteen servers.

      b) a client-server (or just back-end/front-end) aproach to the widget-set too, so that the programmer could use any widgetset library he/she wants, and the user still be able to switch the look and feel of the app to match the rest of his/her apps.
      • > Imagine if you could not run a KDE app inside your GNOME desktop!

        I meet this situation every day -- I can't run X clients in my (sadly) Windows desktop. I can run a X server in Windows, but Windows makes a good integration impossible.

    • Re:Moving away from X (Score:5, Informative)

      by stripes ( 3681 ) on Saturday January 19, 2002 @04:08PM (#2869290) Homepage Journal
      Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency

      There are people working on adding a new rendering model [xfree86.org] that does antialiasing and sub-pixel addressing. "People" being mostly Keith Packard [xfree86.org].

      enhanced programming environment

      There is no reason you can't do that to X, in fact if you compare things like xlib to Gtk--, or Xt to Qt there has been huge progress. Oh, and there is GNUStep too, which is mostly like NeXTStep which is what OS X is based on...

      and a new, well defined and examined user interface?

      That is the hard part. In part because backwards compatibility works against you.

      This would be going the Mac OS X route

      I think OS X has a lot going for it, but the biggest thing really is that the apps do mostly work alike, which is rather unlike X11. I know I'm partly at fault since the X11 apps I worked on (xtank and w3juke [sourceforge.net]) are not much alike :-)

    • Re:Moving away from X (Score:4, Informative)

      by po8 ( 187055 ) on Saturday January 19, 2002 @04:11PM (#2869303)
      Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency, enhanced programming environment, and a new, well defined and examined user interface?

      No. Antialiasing and transparency are most of the way into the X server already. Any enhanced programming environment or better user interface is unlikely to be more difficult to implement on top of the X server than atop some from-scratch thing.

      Basically, the X protocol does all the hard parts of a window system fairly nicely. Its rendering functionality was until recently unfortunate, but Packard's client-side rendering via the Render extension appears to be adequate for anything anyone wants to do with GUIs these days.

      The current client-side libraries are not so good, but this can be fixed without changing the X server or protocol. See XCB [pdx.edu] for one proposed step in that direction.

      IMHO, if one-tenth the energy that was put into whining about X and flailing at never-quite-ready replacement rendering systems went into these sorts of things instead, we'd have a nicer-than-Mac/Windows desktop GUI for free by now.

      • "IMHO, if one-tenth the energy that was put into whining about X and flailing at never-quite-ready replacement rendering systems went into these sorts of things instead, we'd have a nicer-than-Mac/Windows desktop GUI for free by now"

        This would require three things: consistancy, usability, and testing. All applications would need to look the same, behave the same, and the overall environment would need to undergo massive usability testing. Right clicking would need to preform the same action in every program. Most of all, someone would need to write up a user interface guidebook that the application developers would adhere to and follow exactly (much easier said than done in the open source world ;D ).

    • Re:Replace X with what? (Score:2, Funny)

      by Anonymous Coward
      Yo Mama...of course.
      she has too much to display perhaps...I'm gonna need Xinerama.
    • Check out Evas [enlightenment.org]. It features an excellent, very easy to use/simplified API, hardware acceleration, anti-aliasing and all of those cool things and is designed in such a way that you don't need to be concerned what kind of hardware your app will run on - evas will scale accordingly. Plus, there's rumors that rasterman is building an Evas client-server API that could almost supplant X, while not necessarily supplanting X...I think it's a pity not enough people are looking at this excellent library.

      Enlightenment 0.17 is built upon Evas, and from my experience with it, it does run very fast.
    • Growing up with Unix - there were horror stories of a 'Hello World' X11 program compiling to a 500K executable. I was flabergasted - as my TRS-80 only had 32K. (and I was a lucky TRS-80 owner with the memory upgrade). Now days, the perceived bloat of X Windows isen't a big deal anymore - hell, my poket Psion device has 16,385K of memory and it fits in my pocket.
    • There's absolutely no reason that I can think of why somebody shouldn't produce a desktop like KDE or Gnome, with its own graphical protocol, that can share native apps and X apps on the same desktop. I was doing that in Windows 95 back in '97, and in OS/2 Warp two years before that. Integrating the two is not a problem.

      So yes, let's see someone put a non-X desktop out there, and we'll see how it competes with X-only desktops.

    • Re:Moving away from X (Score:4, Insightful)

      by Arandir ( 19206 ) on Saturday January 19, 2002 @07:02PM (#2869994) Homepage Journal
      There's nothing wrong with X11. Nothing other than what a bit of tweaking can't fix. It works and it works well.

      There is one major reason people bitch about X: t's big.

      They're right that it is big and complex. That's they way it's supposed to be. X is a network GUI. You can run your application on one machine and have it display on another (or multiple machines). This is a very powerful feature. It's awesome. But it makes X big and complex.

      If you're running a standalone desktop it doesn't do you any good. If you've come from the Windows world and think that standalone desktops are the only thing that exist, then you begin to question the sanity of using X at all. But Unix (including Linux) is not a standalone desktop OS. You simply CANNOT replace X11 because to many people are dependent upon it.

      Adobe Framemaker doesn't exist on Linux or FreeBSD. But I use it on my FreeBSD box anyway. How? By logging in remotely to my Solaris box at work. Now I get to use the world's best desktop publisher at home on my PC. All because of X.

      X11 isn't going to be replaced. But there is something that could happen. There could be an XFree86-Lite. An X with the same API as all the other X's, but designed and optimized for a non-networked standalone desktop. Strip out all the stuff that home PCs would never use. But make it compatible with the existing X. Hell, you could write it all as a kernel mod for all I care. But at least you would get your tiny weakling X for your desktop and I would still have my big and powerful X for my workstation and we could still use the same X applications.

  • At the top of the change log (Score:3, Informative)

    by fireboy1919 ( 257783 ) <rustyp AT freeshell DOT org> on Saturday January 19, 2002 @03:59PM (#2869255) Homepage Journal
    I think its pretty significant that they've finally made the system work with the old Rage cards. They still sell those (for about $12), and they have a strong hold on the non-gamer market. Heck, I have one on the workstation I'm working on now (don't worry, I've got a game station too). It could help convince businessmen with old Pentiums that they should use Linux if they can get it to work with their typical hardware on the first try.

  • Mirrors for Xfree86 (Score:5, Informative)

    by Adrian Voinea ( 216087 ) <adrian@Nospam.gds.ro> on Saturday January 19, 2002 @04:08PM (#2869288) Homepage Journal
    Here's a nicely formatted list of mirrors for you lazy bastards ;)
    Let's make the slashdot effect on xfree86.org a little more bearable :)
    ftp://ftp.calderasystems.com/pub/mirrors/xfree86 [calderasystems.com]
    ftp://carroll.cac.psu.edu/pub/XFree86 [psu.edu]
    ftp://ftp.cs.umn.edu/pub/XFree86 [umn.edu]
    ftp://download.sourceforge.net/pub/mirrors/XFree86 [sourceforge.net]
    ftp://ftp.freesoftware.com/pub/XFree86 [freesoftware.com]
    ftp://ftp.infomagic.com/pub/mirrors/XFree86 [infomagic.com]
    ftp://mirror.sftw.com/pub/XFree86 [sftw.com]
    ftp://phyppro1.phy.bnl.gov/pub/XFree86 [bnl.gov]
    ftp://ftp.rge.com/pub/X/XFree86 [rge.com]
    ftp://ftp.valinux.com/pub/mirrors/xfree86 [valinux.com]
    • I suppose you just copied that list off of xfree86.org. I don't blame you, but they need to strike freesoftware.com from that list. It's been AWOL for months.

      Cursed be Wind River for all eternity.

  • Great news for laptop users! (Score:4, Informative)

    by Adrian Voinea ( 216087 ) <adrian@Nospam.gds.ro> on Saturday January 19, 2002 @04:10PM (#2869301) Homepage Journal
    One of the major problems I had running XFree86 on my laptop was having to switch between a port replicator (aka docking station) and using the laptop's display. For those of you that don't know, a port replicator lets you use a standard monitor, keyboard, mouse, etc. Switching between various XF86Config files got to be a royal pain in the arse.

    So... those with laptops give this option a try in XF86Config:
    Option "UseBIOSDisplay"
    • So will the TV out work on my Dell Inspirion 4000 (ATI Mobile chipset)?
    • Interesting.

      Do you know how it will handle different resolutions per monitor on laptops?

      On my thinkpad I can have a max. resolution of 1024x768, whereas on my external CRT monitor it's 1600x1200.

      In order for me to get 1600x1200 res. on my crt monitor on my laptop was to add a special directive in the XF86Config file (usecrt or something), but that meant that I had to change the XF86Config file everytime I switched to and from my LCD and CRT.
      Windows however does this automatically.

  • README, Release notes, etc. (Score:5, Informative)

    by Lac ( 135355 ) on Saturday January 19, 2002 @04:36PM (#2869408)

    I found additional documents looking through the website. These are much more interesting to read than the changelog.

    The README [xfree86.org]
    The release notes [xfree86.org]
    Installation details [xfree86.org]
    Driver status [xfree86.org]

    Enjoy!

  • Xfree is sufferring from poor PR (Score:5, Insightful)

    by Error27 ( 100234 ) <error27.gmail@com> on Saturday January 19, 2002 @04:43PM (#2869440) Homepage Journal
    I think it is interesting to compare kernel development with X development.

    LKML has 1-2k emails per week. We have Kernel Traffic, Linux Weekly News kernel summary, kerneltrap.com, #kernelnewbies and there is generally one kernel update per day on linuxtoday.com. There are tons and tons of other articles about kernel development on Linux websites.

    Compiling and installing a new kernel is easy enough that people are doing it on linuxnewbie.org

    As a result the Linux kernel is one of the greatest pieces of software that exists today. People are willing to do a phenomenal amount of work to have their code included into the kernel.
    We are at the point where even the most excelent code has to compete to be included. There were at least three different scheduler implementations for 2.5, two different VMs, and two different asynchronous io implementations. It is very good to be in the position where you can pick and choose what code will go into the kernel at this level.

    On the other hand for Xfree had a closed email list until a year or so ago. There are about 250 emails per week to the Xpert mailing list. There are few websites with Xfree development articles.

    Compiling and installing Xfree is difficult.

    People constantly complain about X needing to be replaced. While there are real problems with Xfree, most of the stuff that people complain about to slashdot is complete crap.

    To me this suggests that Xfree needs to concentrate on their PR skills. Xfree guys need to make development easier for newbies. Key developers need to have more interviews. They need to prove that developing X is just as cool as developing the kernel. There need to be more frequent updates--posted to linuxtoday hopefully.

    Compiling and installing Xfree needs to be easier. I think about it this way, once you compile something, you are only one step away from developing. All it takes after that is to open up an editor and change something.

    To me Xfree is as important as the kernel. Without it I would not use Linux. This is true for the great majority of Linux users. Xfree deserves more attention and credit than it currently gets.

    • That's an interesting analysis. While I could argue some of the finer points (kernel development is different by not using CVS, many Linux servers never even install XFree86), that's not really the point.

      I nominate you. Find out all you can about XFree86, watch the changelogs, write stories for Linuxtoday or wherever, and spread real information about it. Open up an editor and start developing.

      If not you, who will do it?

    • Compiling and installing Xfree needs to be easier.
      Amen, brother! My most recent attempt to install Linux was completely successful, except that I couldn't get X to work. Very frustrating.

      How much of this is an issue where the companies that make monitors refuse to open their specs? The proliferation of hardware is insane. The Mandrake distro I was trying to install had a list of hundreds and hundreds of monitors -- a list which didn't include my monitor. When I searched for my monitor's model number in Google, nothing even came up! You'd think there would be standards, but even old standbys like SVGA didn't work for me. Seems like the lack of standards might be one side-effect of the MS monopoly -- hardware manufactures know that as long as their product works with Windows, it doesn't matter if they conform to any standards, and it doesn't matter if they publish their specs.

      Apple sure has it easy. They only have to make Quartz run with their own monitors.

    • Re:Xfree is sufferring from poor PR (Score:5, Informative)

      by JollyTX ( 103289 ) on Saturday January 19, 2002 @05:57PM (#2869761)
      The XFree86 source tree looks absolutely horrible the first time you try to find out how to compile it.

      I looked at the make files for a _long_ time before I though "hell, let's just do make World and see what happens".

      X built without a single hickup. Why doesn't the README say "If you're using Linux, just do make World and it'll work" ? ;)

  • Mr. Taco Effect (Score:3)

    by Andrew Dvorak ( 95538 ) on Saturday January 19, 2002 @05:15PM (#2869581)
    Mr. Taco just wants us to hold of on our little /. effect ritual until further notice, after he has downloaded all of the archives!

    --Andy

  • hmm (Score:2, Interesting)

    by nomadic ( 141991 )
    I'm curious, anyone have any experience with the other x86-based X systems? I know there are a couple of non-free ones, but I've never had the chance to see any of them. How do they measure up?

  • Drivers for my laptop! (Score:3)

    by Mike Hicks ( 244 ) <hick0088@tc.umn.edu> on Saturday January 19, 2002 @05:21PM (#2869609) Homepage Journal
    Heh, cool. I picked up a copy of the CVS version yesterday. I knew that as soon as I did that, a new version would come out..

    I need this version, as it should have accelerated drivers for the Radeon Mobility chip that came in my Dell Inspiron 4100 laptop.

    I just wonder how long it'll take to whip up a Debian package for it ;-)
  • That is, what video card(s) could I buy that are absolutely, unconditionally, all-features-but-the-hamster, no-problems, all dancing 3D-whizbands supported by XFree86? No recompilation, no binary-only drivers, no unexpected visits from Dr. Murphy ...

    That is, what card to choose for setting up a system that it would take a concerted effort not to get right just by installing, say, Mandrake 8.1, that will run GLTron and Tuxracer without hiccoughing, that will never call attention to itself, at least in the bad way?

    timothy

  • One thing omitted in the Release notes... (Score:3, Informative)

    by Junta ( 36770 ) on Saturday January 19, 2002 @07:59PM (#2870199)
    Unless they royally screwed something up in the past few months, a show stopping XVideo bug with tdfx that was in 4.1.0 was fixed. I've been running CVS for months because of the bug. Basicly, if UYUV or YUY2 colorspace overlays were opened with the tdfx driver, the whole thing would crash out.... Shortly after then it was fixed in CVS, but it takes so long for them to release, I just had to use CVS. So if you use tdfx and certain media programs crash your X (particularly DivX videos are notable...), this is a *very* cool update...

Slashdot Top Deals

This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance. - Steven Wright, comedian

Close