> Are these commercial xservers i586/linux compatible? Yes
> Can I swap them out for say, a md91 distro to get better performance? Yes - I haven't tried it myself so I can't say personally about performance, but others have thought it to be good. Of course, I think X performs just fine. If you renice -20 the X process, the Window Manager, and the panel, you will notice a definite improvement (that's how Windows does it). http://www.metrolink.com/products/metrox/index.html Jon > > Any OSS projects to 're-invent' the wheel? > > I'm not mocking rick's response, but the 'wheel' seems to be square and made > of stone. > > -----Original Message----- > From: Jonathan Bartlett [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 25, 2003 11:11 AM > To: [EMAIL PROTECTED] > Subject: RE: Why is RH9 slower than Windows98SE. Any advice? > > In addition, there are alternatives to XFree86. There are commercial X > servers that work very well, that have nothing to do with XFree86. > > Also, gtk (not GNOME, though) applications can run directly on the > framebuffer, I believe. > > > > Jon > > On 25 Jun 2003, Rick Warner wrote: > > > On Wed, 2003-06-25 at 10:09, Bailo, John wrote: > > > With all the alternatives in Linux, are there alternatives to X itself? > > > > > > Shouldn't there be more than one graphics servers available to Linux? > > > > None as far as I know. But in thinking about the question I have two > > responses. > > > > 1) Writing a full scale graphical environment is time consuming, > > difficult, and requires a lot of skill. There are not that many around. > > The Mac interface, Windows, Sun's SunView, X and X based derivatives > > (CDE, Gnome, KDE, etc.). Probably a couple of others, certainly the > > Star interface was used by Apple and MS for ideas, etc. X started as > > an academic project and then was adopted by the *NIX world as the basis > > for a lot of variants, but the hard work was all done at MIT and > > everyone leveraged off that investment. The basic point is that a > > full blown interface is something that will probably be done only as > > an academic project or if there is substantial value for selling the > > interface. Hence the OpenSource world has moved towards the end of > > leveraging off the X stuff as the basis for GUI's and trying to lay > > stuff on top of that to enhance the user experience. This has the > > side-effect of making it easy for programmers to write applications for > > the interface; any Xlib application can be ported to any X environment; > > it looks better if some higher level widgets are used, but it makes the > > application level much more enticing to developers. Cost of a non-X > > interface and the problem of getting apps for it both argue against such > > a beast. > > > > 2) X in and of itself has a number of advantages (some of which are > > are also disadvantages). It is designed to run on a network with > > distributed clients, there are low level API's that developers can use, > > the core of the interface is freely available, etc. The issue is > > performance, but that can be dealt with as a separate issue. There are > > three main sources of performance issues. First, the WM and other > > stuff overlying X can be bloated and non-optimized. KDE and Gnome > > are both fighting with this, there are alternatives that are lighter > > weight and better as others have noted. Second, video drivers are > > a problem. There needs to be incentives for manufacturers to either > > provide good drivers for Linux, or provide info to programmers that > > will do the drivers. In the early days of Linux, there was a boycott > > against Diamond and their cards as they would not provide data to > > driver writers. Diamond changed their minds and a lot of folks then > > bought Diamond cards as the accelerated drivers became some of the > > best around. Too many cards these days run with non-accelerated drivers > > due to 'secrecy' of the card makers. Good drivers on good cards do > > make a difference - a big one. Third, the fact that X handles > > everything via the network stack can drag down performance. The proper > > way to handle this is to optimize and compress the stream. Low > > bandwidth X stuff is around, and there have been proprietary solutions > > that solve this problem. I'd rather see more effort put in this area > > than folks trying to re-invent the wheel. > > > > In the end, my take is we do not need to replace X, just optimize what > > is there. > > > > - rick warner > > > > > > -- > > redhat-list mailing list > > unsubscribe mailto:[EMAIL PROTECTED] > > https://www.redhat.com/mailman/listinfo/redhat-list > > > > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED] > https://www.redhat.com/mailman/listinfo/redhat-list > > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED] > https://www.redhat.com/mailman/listinfo/redhat-list > -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
