The XFree86 Fork() Saga Continues 580
Mortimer.CA writes "An article up on OSNews about the XFree story
mentioned earlier. Included is: replacing fontconfig with Sun's stsf; XFree86 co-founder David Wexelblat saying that XFree is today obsolete and should be changed; Keith Packard replying, and more."
Correct URL (Score:3, Informative)
http://www.osnews.com/story.php?news_id=3090 [osnews.com].
Not http://slashdot.org/TheXFree86Fork()SagaContinues [slashdot.org]
Phooey on network transparency (Score:5, Interesting)
Re:Phooey on network transparency (Score:5, Informative)
It is important as well to maintain standards compliance with X11, so you can use a particular application with any X server without having to be concerned without running into compatability issues. Frankly, I dont think the need to change X11 protocol is there, we have DRI (and similar things) for apps that truly need high bandwidth, but web browsers, office suites, drawing programs, even animations and video, all work well under X11., i use them all the time under X and dont see a problem.
I really dont see this "bloat" or "cruft" people keep talking about in X11. X works fine for me, its great, its fast, and its small compared with XP! Its fast even with video applications. For those really demanding 3d or high bandwidth applications, we can have DRI and similar things which applications which truly need that kind of bandwidth can use. But most apps such as word processors, web browsers (animations and all), drawing programs, even realplayer, work excellent on top of X11 protocol.
No, we dont need to change the X11 protocol, and even on old computers I have found X protocol is more than fast and adequate in its display speed and capabilities. It seems to be working just fine, X protocol does not need to be changed and we do not need to enter a new era of incompatability, inflexibility, lack of versatility in unix GUIs. Standards compliant X11 protocol provides an excellent, time tested platform which is working very well and will continue to do so far into the future.
X11 itself is just fine and I see no need to change it, it is working great. Xfree86 as well actually has been doing a pretty good job I think of putting out a decent, stable, high quality, X11-compliant, versatile, flexible, system with many useful and beneficial features not removed. Perhaps it could do a little better yes, but it seems to be quite good already. One person commented on the size of a Xfree86 package being 70mb, however, the server itself is about 2 mb in size, most of the rest is drivers i am sure. Drivers should continue to be distributed with X, but it should now be very easy for OS distros (Redhat, etc) to offer drivers in seperate archives, so users can choose to install only the module they need. Of course, there can be seperate projects for video card drivers, especially with the new loadable module system, as those drivers become stable then they can always be included in the main Xfree86 distribution
Re:Correct URL (Score:5, Insightful)
Just because YOU don't, that doesn't mean that OTHER PEOPLE don't.
Re:Correct URL (Score:5, Insightful)
When I'm working remotely on Windows boxen using Terminal Services, I often find myself sighing wistfully and wishing Windows had a wire protocol. Terminal Services and similar solutions at their best are generally ill-concieved hacks and at their worst are just plain evil and rude.
Re:Correct URL (Score:5, Insightful)
There's certainly some cruft in X11. Hardware has progressed to the point that forcing applications to notice details of the graphics card's colour model no longer really makes sense. And I'll be happy when TrueType is ubiquitous in X apps (it's getting there). But you can have my network transparency when you pry it out of my cold, dead fingers.
Re:Correct URL (Score:5, Insightful)
Everytime I hear someone say "X really needs to die", they blame the wire protocol. Well, the first step in optimization is to prove that the optimization you plan to do is actually necessary.
I have seen a large number of projects where "blind optimization" involves reworking large chunks of code only to find out that they haven't really solved the real problem.
As one doctor put it to us a few months ago: "If you think your baby is colicky, she isn't."
Myth of X slowness (Score:5, Insightful)
Quit blaming X. That's not where the speed problem is. As for difficult and complicated - your right. But mature technologies that properly handle a wide variety of cases tend to be that way.
Re:Myth of X slowness (Score:5, Informative)
What about packing and unpacking the X11 "wire" protocol? Modern CPUs (i.e., any CPU that lives and dies by its L1/L2 caches) are limited by I/O bandwidth. As long as the un/packing isn't totally insane, that CPU will spend most of its time waiting for data. Sure, you can shave off some percentage points by going to an optimal binary encoding but Moore's law means you're just polishing the brass on the Titanic. Um, maybe that's not the best metaphor...
Moz *is* a pig, but on this machine even it can scroll theIMHO the real killers are:
Re:Myth of X slowness (Score:4, Interesting)
Given that so many popular widget sets / window managers / desktop themes do like to stick shading and bitmaps on everything, and that many users think this looks kewl, and that in any case Mac OS X and other systems seem to exploit the video card's hardware to do this stuff quickly, wouldn't it make sense to fix the X protocol so that such eye candy can be displayed without slowing the system down too much?
Re:Myth of X slowness (Score:4, Insightful)
It's wrong to blame X for slowness.
Rubbish. On my home machine, Win2K is fast, X is slow. I'll address your points individually: 1 .Slow anti-aliased fonts.
I have anti-aliased fonts in Windows. It ain't slow. If X provided a decent standardised AA fonts interface that was correctly integrated into it's core functionality, then this wouldn't be a problem. AA font rendering should not be that CPU or GPU intensive. It's been around for years -- it's not THAT hard a problem. If a PDA can do sub-pixel font rendering, then a Pentium III shouldn't have much of a problem.
2. Some video card drivers are slow.
Agreed, but most of the intensive rendering on my machine is using the same driver (nvidia). If pixmaps didn't have to be uploaded to the server, then perhaps there wouldn't be a problem. If uploading to remote servers was transparent, and handled by the windowing system itself, then it shouldn't be a problem.
4. Window managers do dumb things, like excessively redrawing apps when you switch virtual terminals.
Yes this does happen. But have you ever compared the number of redraws under X, compared to the number of redraws under Windows by running on a slow PC? Windows does much more redrawing (how many times does it really need to draw my desktop icons every time I press Win-M, for example?!) yet manages to run its display faster than X on most systems. Again, eye candy is fast on Windows, slow on X, on the same machine with the same drivers and the same video card.
5. Poorly implemented eye candy. If X had decent alpha-channel support, decent pixmap caching and hardware accelerated shading or speedy direct rendering, then we wouldn't need poorly-implemented eye candy hacks.
C'mon, I like X, and it's got a lot going for it; but I can't pretend it's not a slow resource hog. X can't even blit a window around the screen at full speed. And that isn't my video card slowing it down(my card can do this in it's sleep), or my drivers(because I can do it blazingly fast using GGI, DirectFB, or SDL): it's X itself.
In short, I think all of these concerns could (and should) be addressed by improving the underlying X architecture. The app layer needs to be brought closer to the hardware display layer.
And while we're on the subject, can't somebody come up with a decent accelerated video display architecture that works on the console and under X. Sure, it can be done: but do you use GGI, KGI, SDL, DGA, X11, DirectFB, plain framebuffer, svgalib, ... ?? Surely somebody sees the need for a unified linux display architecture? Would save a hell of a lot of heartache writing video drivers..., not to mention choosing APIs...!
Don't ask for much, do I? ;-)
Article... (Score:3, Informative)
I'm waiting for episode 2 (Score:4, Funny)
All I can say is..... (Score:5, Interesting)
Re:All I can say is..... (Score:5, Insightful)
Re:All I can say is..... (Score:3, Insightful)
It looks somewhat interesting - I personally think X11 sucks ass, so any alternative looks interesting - but something about the project really bothers me. I can't find their interface guidelines anywhere.
Now see, the thing that annoys me the most with X11 is the disparate behaviors of common widgets and dialogs. Every toolkit and software author seems to have it's personal take on the matter, and it can become pretty confusing at times. And when I read that Fresco intends to be highly configurable, I hope
Re:All I can say is..... (Score:5, Insightful)
Re:All I can say is..... (Score:4, Insightful)
I'm just tired of all the layers, libraries, conflicting interfaces, and general slowness because of all the cruft that is supported for those few power users who always chime in on
Re:All I can say is..... (Score:5, Interesting)
And Multimedia extensions would be nice. It'd be cool if there was a network transparent sound protocol that ran in parallel with X to deliver the sound portion of apps.
Maybe I just haven't been following it much, but it seems like it just disappeared.
Re:All I can say is..... (Score:5, Informative)
Admittedly, it has been almost two years since X.org released X11R6.6 [x.org], but work is in progress on X11R6.7.
Nobody is working on X12, because X12 implies breaking compatibility with X11, and no one has yet come up with a compelling reason to do so that can't be handled via extensions to X11.
Obligatory star wars post: (karma scharma!) (Score:5, Funny)
"The saga continues..."
"Use the fork() David"
(BTW, expect to bring about introduction of new post-rating: +5 Lame!
You know what? (Score:5, Interesting)
Or another possibility: maybe the way XFree86 is currently implemented by the major *nix vendors is overly complex by default.
Either way, both the situation and the implementation are starting to look really messy.
Re:You know what? (Score:5, Funny)
Re:You know what? (Score:5, Insightful)
If I was King of XFree86, I'd first open it up to more people, then I'd tear out the utilities and put them separate, put the fonts separate, throw away the /xc/config monstrousity and replace that with configure --prefix= etc. etc.
Separate pswrap, mkshadow, xau, xnest, xext, all the gl's, xt, xv, xi, pex, speedo. The list is wildly bloated. Sure, maybe all that junk can be separate projects on the same Sourceforge page, but as it stands now, it is a whale.
I've also downloaded and compiled Packard's stuff, and I think his is pretty messy, too.
Re:You know what? (Score:4, Interesting)
Thankfully, I seek out documentation OUTSIDE the XFree source. The archaic imake system, the need for 121 files in xc/config/cf! What's up with that? How is that supposed to be better than configure --prefix etc.etc?
I sure was lucky to find out about WORLDOPTS="", otherwise, if the compilation had hit a snag, I may have never known, because the XFree compile would happily chum along. Fine maybe for some systems. Maybe it is cool to grep an 11 megabyte &> log file. Maybe it is old school.
Keith's code is nice, is creative and works well, it is just the XFree86 World system he's fitting into. Fontconfig package 2.1 took me a long time to get right.
fork() power (Score:4, Insightful)
From everything I see, it's too late in the game to make a new graphical interface - unless it has a compatability layer to work with X apps. But even then, we'd need to develop it FAST to make sure *NIX doesn't fall behind in the OS game.
Re:Whoa there, cowboy (Score:5, Insightful)
I think alot of people have the misconception that having more layers between applications and the hardware slows things down. That is not the case. Those formal layers (as introduced by the X11 protocol) are just abstractions of what would have to be there anyway. They end up reducing bloat and memory consumption, as well as saving programmers time, so that every programmer who wants to make a 3D visualization program doesn't have to reinvent the wheel by recoding into his application how to access and manipulate the graphics-card/monitor.
STSF Looks Pretty Cool (Score:5, Informative)
Here's some links to the screenshots of stsf running on Solaris 9:
xclock -digital -fg yellow -bgpixmap SolarisLogo.pm -fga 0.5 [sourceforge.net]
LANG=zh_CN.UTF-8 xclock -digital -bgpixmap RicePaper.pm [sourceforge.net]
Re:STSF Looks Pretty Cool (Score:4, Interesting)
Re:STSF Looks Pretty Cool (Score:4, Funny)
Re:STSF Looks Pretty Cool (Score:5, Insightful)
Here's why:
STSF has OpenType Font Support, which is accepted as a standard for rendering indic and other complex asian texts(arabic, urdu, etc) by the developer community. By having OTF support at the X-server level instead of the toolkit level(like pango for gtk), almost all GUI's if internationalized would render in all Asian Languages. This is a great step forward for spreading linux into asian countries, but it's unfortunate this politics has to happen. BTW, some of the STSF development was done here in Sun's Bangalore centre.
Anyway, some related links:
More about Opentype fonts:r ead_id=1856380&forum_id=12019
http://sourceforge.net/mailarchive/forum.php?th
Building OTFt ro.htm
http://www.microsoft.com/typography/otfntdev/in
Unicode FAQ about Indic:
http://www.unicode.org/faq/indic.html
Links about fonts, otf,xserver,etc:
http://indlinux.org/links.php
The indic_computing mailing list - expect to see a lot of heat generated because of this announcement:r um_id=2967
http://sourceforge.net/mailarchive/forum.php?fo
Hmm. That's not right... (Score:5, Insightful)
The concept of the community voting for membership in the leadership of the project is an almost, if not totally, non-existant concept in the Open Source world (feel free to show me examples). I'm not talking about advocacy groups, like Linux International. I'm talking about development projects. XFree86 has no interest in this, as far as I can tell.
I can think of one right now. So can he, since he mentions it a few paraghraphs later. The FreeBSD Core team is elected [freebsd.org]. To be core on FreeBSD you have to be an active developer, and have not pissed too many other developers off recently (or at least pissed them off less than most other people). Sounds like a good idea to me...
Oh. Wait. Sorry, I forgot. FreeBSD is dead. I really should stop using it sometimes soon. Can't be using a dead OS on my desktop...
Re:Hmm. That's not right... (Score:3, Insightful)
Choice? (Score:5, Insightful)
Whatever happened to choice in this debate?
We can choose between various [windowmaker.org] window [kde.org] managers [gnome.org], various [redhat.com] linux [slackware.org] flavors [debian.org], and even office [openoffice.org] suites [koffice.org]. Why don't we have a choice with our window system?
Why would it be any different for a fork of X for a choice between client/server and direct rendering, if backwards compatability was kept?
Would that not help the the people who only use Linux on their desktop, while allowing people with networks to use the tool, as it is now, that works for them?
Re:Choice? (Score:4, Insightful)
A windowing subsystem needs to provide enough framework to make application development easy and enough flexibility to allow developers to do what they want to do. Windows software is not mainstream today because the developers had a choice of subsystems - it is mainstream because they wrote for the one that was biggest and trusted Microsoft to provide compatibility in future versions. Brilliant move, that.
Unix has long been plagued with vendor-specific code that hinders broad development efforts. The **only** reason Linux is so popular today is because of the single windowing system. Average users don't care about how fast it can fork() or whether it's virtual memory management is superior - they want lots of apps, they want them to be pretty and they want them to all run on top of each other.
Forking X is a terrible idea. Perhaps if they go for it, they'll choose an appropriate name... Y?
-Elentar
Re:Choice? (Score:5, Insightful)
Actually that's way wrong, and if you notice Linux is so NOT popular today on the desktop. (it is popular on the server where graphics largely don't matter, or at *least* were not a convincing feature)
Er, you do. (Score:3, Informative)
If you don't like XFree86, the folks at XiG [xig.com] would be happy to sell you a copy of AccelX. MetroLink systems still offers Metro-X [metrolink.com] (which was the bomb back in the RedHat 4 days...dunno about now), and if you don't have any money to spend, you can still download, compile and use the honest-to-god MIT/XCon
Re:Choice? (Score:5, Interesting)
As usual, the people who bitch about X are going to have to find some new reason to bitch about X.
Video-Card-Centric clearing houses (Score:5, Interesting)
The thing is, drivers can be released independently of X itself. For ATI Radeons, for example, there are at least 3 different drivers they can use. It would be nice if somebody set up a website with a page for each video card (or family of cards) that had links to all of the available video drivers for that card. Even better would be if such a website could act as a catalyst for uniting these independent driver developers so that, for example, the GATOS radeon driver developers and the DRI radeon driver developers could combine the best aspects of their drivers. This could possibly help route around the blockage that the XFree86 project too often represents.
Actually, I think that such "hardware-centric clearing houses" would be useful for all kinds of hardware, not just video cards. Look at linuxprinting.org to see how well it can work.
-DA
Re:Video-Card-Centric clearing houses (Score:5, Informative)
Well, yes and no. For example, I occasionally work up a new port for FreeBSD, which then gets submitted via a problem report. Someone who has commit rights may, or may not, commit this to the official tree. I've not submitted nearly enough of a body of work into that tree to have anyone trust me to write directly to it. This means that if I need to edit what I've done, I once again have to submit another problem report.
There's nothing at all wrong with this model. It insures that every aspect of what is being committed to the tree has had at least some review by those folks who have taken on the responsibility of the entire project. If that driver in question really is stable, and the author has more to contribute in the way of code to it, then eventually commit access very well may be granted. One lump of code does not automatically default into full trust.
Another example relating to port submissions: I recently did up a port for an application I submitted via a PR. I felt I did a pretty good job on the various pieces that go into this. Turned out someone else did the same thing, but from a different platform. Apparently there were issues with what I did compiling on an Alpha that I couldn't have possibly known about. Both submissions were taken together to produce one correct version that worked across the board.
The point of this is that the folks actively involved with the bigger picture of a project are going to be more aware as to how various pieces need to fit and work together. That's why there's a need for a hiearchy and commit control within any project. I would think this to be especially true for one as large and complex as XFree86.
Heh...nice title... (Score:3, Funny)
Ya booor skay, ska boo ske-deeke-skeee Fork()!Fork()!Fork()!
.
Origins of XFree86 - been there, done that! (Score:5, Informative)
Anyway, one thing that rarely gets mentioned is how XFree86 itself was a fork. A fork from a recalcitrant developer, namely Thomas Roell. Roell went on to be a principal (probably founding) engineer at Xinside, later renamed Xi Graphics. Roell was the primary author of X386 which was the only freely available X server for x86 systems (typically SVR3 and SVR4 unices from a handful of companies like AT&T and Dell - yes Dell actually had their own Unix distribution and it was pretty kickass too). X386 had limited chipset support (IRC, Tseng Labs ET4000 was the faster chipset it supported) and little if any support for hardware acceleration.
Anyway, the story gets a little murky here, because I wasn't in on all the background machinations, but a couple of developers who are now in the core group (DavidW for one, and I'm thinking David Dawes and Tsilias, but don't quote me) got together and forked their version of X386 to add support for more chipsets and more OSes, kinda leaving Roell (unhappily) in the dust. It didn't help that Roell's got an ego (which he *mostly* deserves) and that DavidW had a kind of angry-young-man online persona at the time either.
It appears that Roell eventually got over it, but never enough to join in the fun. Instead he went on to do commercial X server development, ultimately at XiG.
But, the moral of the story here is that XFree86 itself (even before it had a name, I remember the vote on the mailing list, I didn't vote for it, thought it was kinda dorky, but I guess my own suggestion was even dorkier since it didn't win) is a fork of code that was floundering and not being developed fast enough for the tastes of some people. People who were willing to put their code where their mouthes were and to improve the situation, and who didn't really care too much who they pissed off in the process as long as the end result was a big improvement - and that it definitely was.
I've been out of the loop on XFree86 for many years, but from the outside looking in, this current spat has the ring of history repeating itself to me. It is just more public since the userbase is a couple of orders of magntitude larger than it was the first time around, and there was no slashdot back then either...
Re:Origins of XFree86 - been there, done that! (Score:5, Interesting)
Is it just me or is it a little bit cheeky that David W has a say in this at all. It's not like A) he is hacking Xfree anymore, or even using UNIX for that matter. He's been using Windows since Myst came out, for crying out loud. I read the emails, and when you have folks like Keith, Alan, Owen, and Havoc complaining about how XFree is run then isn't it likely that something is actually wrong?
X is obviously turning obsolete (Score:5, Interesting)
I still remember the transition from X10 to X11.
However, version 11 is almost 15 years old and we
never saw any version 12 (not that I beleive version numbering is any important).
Although I saw some nice extensions being added to the X protocol, there are many parts of the X window system that are now obsolete.
For instance the standard X11 font rendering system looks like it has been kept in the stone age (only recently the Xft extension solved part of the problem).
I really like the network transparency of X and the client-server model, because of all it's advantages and, if you look at it in detail, you will be surprised that it doesn't impose any performance penalty: because of the way the X protocol is implemented, commands are queued by the client and are sent to the server in batches, in order to minimize client/server context switching.
However, in the last 12 years we have seen the graphics hardware improove a lotm but the core X system didn't improove almost anything.
Now we have hardware capable of displaying full motion video, hardware video decompressing, anti-aliasing, alhpa-blending and transparency, 3D, etc.
Meanwhile, X got some extensions to support some of these features, but there are no "standard" APIs and the evolution has been very slow.
X is great, and many of the complaints about X that I regularly read here in
Maintaining XFree86 (Score:5, Interesting)
Efforts to extend XFree86 to support modern graphics capabilities (XRender, Xft, R&R) are floundering because the level of skill needed to develop and maintain them is simply too high. The XFree86 codebase reinvents many wheels, is difficult to maintain and really does carry a lot of legacy footwork that makes it difficult to work with.
That said, XFree86 works amazingly well for what it is. I just don't think XFree86 development is sustainable. The same effects can be achieved with a thin layer like DirectFB [directfb.org] without the overhead. You get the same functionality, usually better performant and with far less code necessary in the implementation. Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
Re:Maintaining XFree86 (Score:4, Interesting)
Before anyone gets confused, lets be clear and point out that this is the IT equivalent of a theory. Basically, we are told the client should be just smart enough to render controls and pass input events back to the server. This is theory because there are no implementations of this in widespread use.
The quote suggests that Bonobo or Kparts would implement the client side controls. These controls are then driven from the server via RPC or some other mechanism.
Some argue that web browsers could do this. Perhaps. The inherent statelessness of web clients preclude large classes of GUI applications and makes others very difficult. Can you imagine a browser based implementation of, say, Paint? (activex/java doesn't count.) Lots of applications have grids with re-sizable columns, yet common browsers have never provided this without add-ons or substantial hackery.
There have been and are real attempts to make this theory work, however. An excellent example is XWT [xwt.org]. Check it out. There are others, but they're even more obscure and even less likely to ever actually matter.
Why is this? Lots of people have this notion of half-smart clients that provide 99% of "direct" GUI fidelity by rendering controls on behalf of some server somewhere. There is nothing new under the sun. Yet it doesn't happen.
Here is my contribution: Z Windows (I think there is a Y Windows out there,) an evolution of X Windows:
- Separate the frame buffer from the window system. Graphics drivers would be "mini" drivers that abstract the hardware just enough and no more.
- It's obvious audio must be integral. Integrate it.
- TrueType won. Get over it. Integrate it. Anti-alias it out of the box. Provide a simple means to cope with font substitution just like Microsoft does. End of font problems.
- Create a standard window manager. All others accept the consequences of being weird. Life is short.
- Base the programmatic interface of the whole thing (API) on something worthwhile. Trolltech's QT would be a good place to start. Sharp did it and it works fine. Plus there is an entire suite of application software already written to it. Gnome would be fine too, I don't care.
Now you have a clean, straightforward system that has a good API, sound, good fonts and drivers that are easy(er) to implement. Applications arrive shortly thereafter because your using a worthwhile API.
What about network transparency? Well, in case you haven't noticed, the most widespread use of network transparent GUI is Citrix. It works well, thank you very much. It would work even better if it had been incorporated from the start by the underlying GUI. Citrix is nothing more than a highly optimized screen scraper, much like VNC. It turns out, despite the best thinking on the matter, that this is sufficient for 99.9999% of all remote GUI purposes, and the remaining 0.0001% (high performance graphics work) you want local anyhow.
Congratulations. You now have a worthy GUI system for the next 15 years. Now wake up.
Re:Maintaining XFree86 (Score:5, Insightful)
With the modularization of hardware drivers in XFree86 4.x, this is much less of an issue. You can drop in your own hardware driver into a stock XFree86 (in fact, a binary hardware driver written for linux will often work on FreeBSD, it's that good). What more are you looking for?
- It's obvious audio must be integral. Integrate it.
Why is that obvious? I, for one, don't see it at all. XFree86 sends stuff to your video card and your monitor, the audio drivers send stuff to your sound card and your speakers.
- TrueType won. Get over it. Integrate it. Anti-alias it out of the box. Provide a simple means to cope with font substitution just like Microsoft does. End of font problems.
Wake up. TrueType is supported; it's easy to anti-alias (not everyone wants antialiasing, even windows doesn't do it out of the box); and XFree86 actually ships with some TTF fonts (luxi mono/sans/serif, which look lousy in my opinion, but that's not their fault -- they're not font developers, they take what people donate them).
- Create a standard window manager. All others accept the consequences of being weird. Life is short.
XFree86 does ship with a WM -- twm. Like it? I didn't think so. So they should replace it with something like, sawfish? Metacity? KWin? WindowMaker? You have all those options already, why ask XFree86 to add another useless option? What we possibly need is a standard specification that allows one to replace one compliant window manager by another.
- Base the programmatic interface of the whole thing (API) on something worthwhile. Trolltech's QT would be a good place to start. Sharp did it and it works fine. Plus there is an entire suite of application software already written to it. Gnome would be fine too, I don't care.
Again, if you like Qt, use Qt. If you like Gnome, use Gnome. What's the point of XFree86 making those decisions for you? It's all about choice -- in fact it's good that Qt and GTK+ are abstracted (especially Qt), since they can be ported readily to other platforms like MacOS and Windows, which means your applications can be ported quickly too.
Re:Maintaining XFree86 (Score:3, Interesting)
Why is that obvious? I, for one, don't see it at all. XFree86 sends stuff to your video card and your monitor, the audio drivers send stuff to your sound card and your speakers.
X is network transparency. It should not just be about graphics, it should be about providing a standard means by which the end-user experience can be piped to any display anywhere easily.
This is not to say that X should give up speed for flexibility. Rather, I believe that
Re:Maintaining XFree86 (Score:4, Insightful)
Re:Maintaining XFree86 (Score:5, Interesting)
Here are my suggestions for XFree86:
1. Simplify the server.. let me guess that 90% of the code is redundent, out of date, etc. Really, a nice re-organization of the codebase would make it a lot more coherent. The framebuffer rewrite got me excited, but lets keep going. A basic tree might look like this:
You get the idea.
2. Get rid of font servers. Seriously, integrate font management into X. I mean adding and removing fonts from the server at the user level too.
3. Replace the base rendering model with XRender (or allow a mixture). It's time some of the extenstions moved into the core server (Shape anyone??)
4. Let the server cache graphics list. This will help abstract gtk and qt toolkits from the rendering. That way, a server can be loaded with a description of a button, and take care of the drawing and refresh of that button. I'm _not_ talking NeWS here.. I'm talking "what graphic primitives redraw this component." These lists could be shared between KDE and GNOME. You could create them in SVG and they could be translated to X primitives by the toolkits. Then, toolkits only need to manage a single SVG file. Wanna new look for your desktop, just drop in a new SVG.
5. Modularize the core. Ouch, that will hurt.. but sometimes people want to use X just for a device setup and a framebuffer. (Think embedded). Re-architect around the idea that X is an orchestrator of devices, inputs, and graphics primitives. That was the original spirit of X, and should carry on.
6. With all that in mind, kill imake. Seriously, who uses imake besides X? Bueler? Bueler?
7. Clean up Xlib. Merge the other libs into the library. We have smart linkers these days, ya know. Since we killed imake, we can use configure or something along those lines to fix this.
8. Document it all. Document how a window is created, and what parts there are all the way down to the rectangle lists. How this list is translated into graphics onto a screen. XAA is fairly well documented. XVideo is a bit rough. XRender has somewhat real documentation, and you can read the thoughts of the designers on the public lists.
Let me know when the revolution starts..
Pan
The Killer App (Score:4, Insightful)
Between the Linux LTSP [ltsp.org] project and FreeBSD's diskless booting [freebsd.org] routines, we "should" be seeing a complete overhaul in how people think of deploying desktops to end users. This is as true at home as at the office.
Most likely the main reason we haven't seen a huge trend away from the "fat client" architecture is due to the complexity involved with configuring a "thin client" setup. It's definitely not due to the technology being there. XFree86 is the infrastructure that makes this a reality today for those brave enough to dive into the man pages.
I dearly hope that whatever internal difficulties this project has it can get through. It's just too darn important to all of us to see it splinter off into multiple directions.
Re:The Killer App (Score:5, Interesting)
Here at home I have one high-powered machine. Some of the time I access it directly. Some of the time I access it from the kitchen or the living room via JavaStations (
At work we have a pair of high-powered servers. One is a production box; the other is development. 9 people work on it all day, ever day. Some just ssh in and use screen; some ssh in and then run X apps remotely; some run full-on KDE sessions. All are using cheap, throwaway PCs from other departments. How? Because X is NETWORK TRANSPORT designed to make EFFICIENT USE of POWERFUL MACHINES for MULTIPLE USERS.
The quote goes: "Those who do not understand UNIX are doomed to reimplement it, badly." I propose a corollary: "Those who do not understand X are doomed to bitch about it unto Eternity."
Re:It hasn't killed anything in ten+ years (Score:4, Informative)
People have wanted network transparency for years. Unfortunately the applications they wanted to access remotely only ran on Windows. It wasn't until recently (thanks largely to Linux) that X11 has gathered enough applications to be remotely workable.
X terminals powered by Linux servers have huge advantages in all sorts of settings. When the Linux desktop revolution comes the clients will be using X terminals.
Go Keith! (Score:5, Interesting)
Linux is utterly irrelevant to the majority of "real-world computer users", people running MS Windows and MS Office. But client-server displays are highly relevant to the core areas where Linux and UNIX is being used: scientific and engineering apps, large multi-user servers, compute clusters, large business apps, public computer terminals, and server applications.
X needs to be replaced by a direct-rendered model, on which a backwards-compatible X server can be reasonably trivially implemented.
Does Wexelblat even have a clue what he is talking about? What is more "direct rendered" about the graphics subsystems of other desktop operating systems? All display subsystems these days run in separate address spaces, all of them involve context switches for rendering, and all of them (including X11) can use shared memory and direct hardware accesses when it makes sense. Microsoft and Apple are finally beginning to catch up with X11, except that their systems are burdened with much more junk that is necessary for them to be able to pretend to being a 1970's style frame buffer library. Furthermore, in terms of the graphics subsystem, those supposedly "direct" systems can easily be remoted--the reason why they aren't is because they lack all the other conventions and infrastructure that X11 has for multiple displays and client communication.
And these kinds of replacements have been tried numerous times before. People have always chosen X11, even if it meant uninstalling vendor-supplied GUIs and installing MIT X11 from sources (which is no mean feat). X11 has survived against all odds, because it satisfies the needs of its users well.
That is not to say that X11 is perfect--far from it. Its protocol has warts and it has its own share of historical baggage. But those problems have nothing to do with "direct rendering".
I had no opinion about whether Keith's leaving XFree86 made sense or whether it was justified before reading Wexelblat's posting, but Wexelblat has removed all doubt: with idiots like Wexelblat on the XFree86 team, XFree86 has no future. All I can say: Go Keith!
Re:Go Keith! (Score:3, Insightful)
Before some nit-picking sets in, I'm referring to display subsystems of major desktop operating systems. And, yes, I am aware that NT runs display code in the kernel, but you are smart and can figure out yourself in what sense that is a "separate address space".
Incidentally, XFree86 could be moved into the Linux kernel, giving Linux a windowing architecture very similar to that of NT and probably a modest performance boost, but I frankly
Re:Go Keith! (Score:5, Insightful)
There is no sense for XFree to have their own drivers (video, or otherwise, at least on Linux..). By going through the kernel for video, you'd also eliminate the issue of having to be root to run X, and there'd be no more "fighting over the video" (try running svgalib, X, fbcon, etc together and see how long your system lasts).
Personally I have no problem with X11. I just don't like how XFree86 is so doggone big and includes its own drivers, when modern OS's like Linux have this stuff already. XFree86 is bigger than KDE. I mean, come on now.
Re:Go Keith! (Score:4, Informative)
This is what libGGI was, back in the day. Even had automatic selective fallback to emulation for any features that weren't implemented in the video hardware. Ah, the roads not taken..
The key issue (Score:5, Insightful)
On the one hand, David Wexelblat has strong words about Keith Packard's actions:
What Keith has done is among the most low-class, unprofessional, and tactless things I have ever experienced in my professional career.
For Keith to blatantly lie to the Core Team about what he was doing is utterly unacceptable.
But what Keith is doing, at least how he's handled it, is just flat out wrong. It's literally dishonest, and morally repugnant. Doesn't mean that there aren't some valid issues to work, or that there is no need for branching, but (a) it remains to be proven, and (b) I'll be damned if I'll quietly accept it being done by someone who is lying to my face.
Whew. On the other hand, here's what Keith Packard has to say:
Some have suggested that this was a secret attempt to undermine the XFree86 project: this was not my intent. I have tried as hard as I can to work within the existing XFree86 structure.
It's hard to think that this is some kind of misunderstanding. Either Keith has been lying, or else he hasn't. It's impossible for us to really decide for ourselves, since the emails containing the alleged lying are not public.
David Wexelblat said:
There is an email thread documenting this. Some members of the BOD wanted to post the email, or quotes therefrom, with the announcement. I and some of the others were utterly uncomfortable doing that. I don't think anyone on the BOD or Core Team would have any issues with an independent audit of this email thread, if there are concerns about the veracity of what I say, but airing that in public isn't appropriate, IMHO.
I'd like to see someone I trust given the job of auditing those emails, and judging whether Keith Packard has in fact been lying.
P.S. A fork might be a good thing, in the end. Keith Packard says he believes his fork can attract more developers and improve more quickly than the status quo. If he can pull that off, we will all be better off. But unless he can clear his name, he may have trouble attracting developers.
steveha
Re:The key issue (Score:4, Insightful)
Unfortunately we don't, and probably never will, know the exact circumstances behind this split in developer ranks. It mirrors Matt Dillon's recent dismissal [slashdot.org] from the FreeBSD project.
Re:The key issue (Score:3, Interesting)
-- genuine differences of opinion regarding direction
-- unclear leadership
-- poor interpersonal issue resolution
In any case if you look at his resume [keithp.com] this guy is the kind of guy who should be on an X
X design decisions (Score:4, Insightful)
There was a design decision made when creating X that displaying windows on a local workstation should be as easy as displaying windows on a remote workstation. This decision affected several things about X, and made the X API's extremely difficult to learn (pick up an X book, you'll see), but extremely powerful.
Basically, what some people are saying is that that decision was wrong - that it's not correct to design an entire graphics API around the concept of displaying windows locally and remotely.
Really, the most objective way to analyze that claim is to look at how many windows users open on their own workstation, versus how many remoted X applications they run. Compare that percentage. Then take a look at how much more complex X was made to handle the eventuality of having to handle remote windows, etc, etc. Is it worth it?
Me personally, I don't think so. The only real use I've had for remote X applications was in terms of systems administration - but this is stuff I could have done as easily with something like ssh, or, if I needed some kind of graphics, PC Anywhere, or Timbuktu. And for applications to be faster, better behaved, and less bloatey, I'd be willing to install some PC anywhere-style application on the occasional remotely-controlled server. For the most part, people would be able to leave it out.
That being said, I've never used X in a thin-client environment - it's possible that it could perform quite well - and I've heard that the X protocols are very good at keeping network use down. It still strikes me as not the right distribution of power between server and client, but what the hell do I know?
Re:X design decisions (Score:4, Informative)
X is essentially the number one reason to choose Linux/UNIX over Windows in multi-user computing environments, as far as I'm concerned. If X were ever discontinued, it's likely that in the next upgrade cycle I'd move my labs over to Windows, because without the cost-savings and administration features offered by X, there is no compelling reason to deal with the increased learning curve and driver issues in the Linux world.
Re:X design decisions (Score:5, Interesting)
It doesn't have to be a "thin-client" environment. All you need is a networked environment. At my work we are split about 50/50% UNIX and Windows developers. Windows developers are almost literally tied down to their workstations. That's where their environment is so that's where they have to work. They don't even notice it, because it is so ingrained into their thinking.
On the other hand, I have a Solaris and FreeBSD machine in my cubicle, and I can use them from *anywhere* in the company. In fact, I can use them anywhere in the *world* if I would ever bother signing up for remote access authorization. My cubicle is not my prison. I do a lot of work in the development lab, and it is extremely nice to be able to treat any random workstation there as my own personal environment. I can edit code in XEmacs, peruse its documentation in FrameMaker, check it in with ClearCase, and then move on to the next bug with ClearQuest, all while browing the web and checking my email with Mozilla. This is because of X11. My Windows coworkers can't do that. They're always running back to their cubicles to do their work.
Here's another example. A lot of my coworkers use both UNIX and Windows. They all have KVM switches. I hear they're very popular. But since I don't use Windows, I've never seen the need for one. I can run multiple applications from multiple machines on whatever display I happen to be sitting in front of. Without having to beg IT for permission to buy to the software or hardware to do it.
There are two paradigms at work here. One is the "single user on a single machine running locally." The other is "multiple users on multiple machines running anywhere they want." X11 supports both paradigms. Windows supports only the first. Please don't dumb down X11 to the Windows level.
Re:X design decisions (Score:5, Interesting)
a) tremendously reliable
b) very easy to maintain
c) offered users tons of freedom
Contrast this with your typical Windows corporate setup. Anything other than total lockdown makes the system entirely unmaintainable. As a result user / desktop support ratios are very high and users and constantly frustrated by how little they can do. Virtually every corporation should be running dumb X terminals. It really would cut costs and empower employees.
Take a simple example like software installation. On a Unix system I can safely let users install anything. The apps they install can't run with any more privs then they have and they can't hurt the system.
On windows OTOH letting people use any printer in the building means they have to have permission to install drivers. Letting people install drivers is:
a) hard because they are forced to understand details of printer models
b) allows them to completely muck their system up
Re:X design decisions (Score:4, Interesting)
It's true that this (application) client/server paradigm is tilted heavily toward the idea of centralized servers accessed by smaller clients. And where this topology exists and is necessary, people use X this way and it matters. For average users, it doesn't.
But that's the status quo, and it won't last.
We're going to inevitably move to a distributed computing model, and it only makes sense to do this on a per-application basis as a first step. Almost all the pieces are there. The piece that isn't there is a mechanism that matches slack to need transparently.
In my (years past, not current) daily use of UNIX workstations, I would manually spread my workload around to different boxes just because it made sense to do so. But it was a pain. Imagine if that were automatic and transparent.
In my opinion, X's network transparency will once again become incredibly useful. It's utility just needs to be properly leveraged.
Hmm (Score:5, Insightful)
"- There is no reason for Core Team matters to be public. This is the
leadership forum, not a public forum."
What is the difference between Core Team members keeping their plans secret and not allowing the public to participate, and Keith Packard keeping *his* plans secret and not letting the Core Team know about them, which he is getting lambasted for? Sort of hypocritical. If the X license is an Open Source license, the Core Team doesn't have any special rights with regard to modification and distribution than Joe Hacker who wants to fork it does. X (X11R6) hasn't changed in a hell of a lot of time (relative to most opens source projects), so what is the purpose of shielding XFree from the public? Some panties need to be untied.
Re:Hmm (Score:5, Insightful)
If you don't take this approach, you run a terrible risk of proposing an awful idea to a large audience. The more audacious the idea, the more credibility you lose. Hell, even really good ideas are often hard to swallow if somebody just does a brain dump of their first draft.
Again, bullshit. It is often impossible to know whether you want to strike out on your own without quietly discussing it with other people.You are essentially arguing that it is unprofessional to explore the job market without first quitting your job. Dumb, dumb, dumb.
As far as I can tell, XFree86 Core are hugely insecure and neurotic. People with self confidence and competence would have simply made Keith a counteroffer. Happens all the time in the real world, which apparently is not where XFree86 lives. E.g., Senior Engineer at Small Turbine Corp. interviews at Pratt and Whitney. What STC execs should do when they find out is to shit themselves, clean up, and make a counter-offer. What they should not do (but alas sometimes do anyway) is fire Senior Engineer on the spot.
The fact that XFree86 Core went apeshit demonstrates (1) they know what Keith was saying is true, and (2) they have a pretty fucking big chip of their collective shoulder. The fact that they went into a frenzy of mailing-list creation, Bugzilla installation, and project reorganization proves #1 beyond any doubt. Other evidence covered extensively elsewhere strongly supports #2.
Dear Keith... (Score:5, Interesting)
...after reading your long message, and also reading David Wexelblat's message, and reading all the stuff that came before, it's pretty clear to me: the X Core Team doesn't want to talk. They don't want outside input, they've deluded themselves into thinking that other Open Source projects are just as closed as they are, and they really don't see where all these outsiders get the right to have an opinion. They ask why you (Keith) didn't open a discussion with them, but then act hostile to nearly everything that is discussed.
I don't know how to write a driver for X, but I do know people. And you're banging your head against a wall as long as you try to work within their system. Good luck with whatever you decide.
Re:Dear Keith... (Score:5, Insightful)
More to the point, the main criticisms against Keith Packard come from David Wexelblat, who while saying that he supports open source, in his own words:
I personally don't have much interest left in hacking code; I don't code much at work any more, and not at all in my free time. If I ever do, I will do Open Source. Whether it will have anything to do with Linux or X, I don't know; I doubt it. It will probably have something to do with my other hobbies, and be Windows software.
Also:
Some of you may be too young to have any idea who I am. I, along with David Dawes, Jim Tsillas, and Glenn Lai, created XFree86 a little less than 11 years ago. I have been basically inactive with XFree86 for a goodly number of years now, but remain on the Board of Directors, and lurk on the Core Team. I care very much about this project and the people involved, and pop my head up once in a while to kibbitz when necessary. It's necessary now.
So, on the one hand he is interested but at the same time he does not contribute to the project, he believes X is obsolete and admits to only using Windows OS. It begs the question, if he so much cares about the project, why not resign and let someone por involved take his place?
I think we should take arguments from this discussion with a grain of salt.
Wake up! (Score:5, Informative)
I knew Keith back in the X Consortium days, before anyone was even attempting a serious port to X86 boxes - because they were just too pathetic. Keith has always had an excellent attitude, and cared deeply about the technology, the developers, and the user community.
If Keith has problems with the way something is being handled, only a *fool* would refuse to listen. And that doesn't say much for the folks at Xfree86 who kicked him out, with essentially no notice.
If you've paid any attention at all, XFree86 has been slowing down. Releases get slower and provide less. The driver issue is well documented already.
The X Consortium did far more with far less than XFree86 has been doing the last couple of years, and (IMO) did it much better.
I haven't been involved in XFree86 (I haven't even tried to for several years), so I don't know what the underlying problem is. But I would definitely listen to Keith, and to David Wexelblat, as well.
Maybe, just maybe, we'll get something that works.
[And for those who want to chuck X, well, go use Windows, or suggest a better alternative. To date, I haven't seen anything close. And if you didn't have to live in the pre-X11 world, you have *no* idea what you're proposing - unles syou have that alternative handy.]
X needs a fork (Score:4, Interesting)
KeithP is one of the few people who could make a fork work.
I have a hard time with David Wexelblat who doesn't work on XFree86 and doesn't even believe in it, insulting one of the key developers.
The future of X (Score:3, Insightful)
'Wexelblat shouldnt have anything to do with XFree86 or X anymore..
He very obviously doesnt believe in it anymore - if he ever really did.
This isnt the kind of attitude you want having ANY control over XFree86 or X.
Ex:
"client-server display systems are utterly irrelvent to the majority of real-world computer users.."
are you kidding me?!?
what a dick!
Perhaps Keith Packard wasnt trying to 'subvert' anything..
Perhaps he was trying to start a revolution - that looks like it might be needed.
DirectFB (Score:5, Insightful)
It looks pretty cool and is quite fast.
Don't know how practical it is or what issues are involved, but anyway if the X ship is sinking, I'm voting for DirectFB.
Of course the X boat is not sinking though.
All those who are sick of X can just stop using X, and see how you go
XFree86.org = ICANN (Score:5, Interesting)
The actions of XFree86.org convince me that they want to restrict user choice in the GNU/Linux world, and prevent anyone else from running any X11-implementations other than XFree86. Their refusal to modularize drivers is one thing convincing me of this.
I can not think of any major projects which are as poor as XFree86 in regards to including the community and being accountable to the community. Many of the people within that "organization" are in fact figureheads who don't even believe in XFree86, like one of the founders linked to. If you don't use XFree86 at all, and only use Windows, then imo, you have no business being part of an XFree86 team.
Keith is right to fork off XFree86. He has tried to address his concerns from within the organization, and has been unable to do so. Just like Auerbach. There is only so much one crusader within an organization can do when the rest of the organization is bent on corruption.
XFree86 is proof that even a project covered under a license approved by the OSI and the FSF can be corrupt and non-transparent.
At attempt at reason (Score:4, Interesting)
Keith, if you are listening, may I suggest that you formally and thoroughly document your objections to current XFree86 development and provide constructive criticism on how it might be improved? If there are technical complaints, such as relating to performance, perhaps you can write code to prove the need for change.
XFree86 team, if you are listening, may I suggest that a patch tracking feature be added to the official web site? For example, if a patch is submitted to support a new XRender feature but not yet committed to CVS, show this and offer the patch for download right there. As a user, it greatly frustrates me to not have any idea when new features and support will be added and you must admit, the XFree86 release cycle is rather slow. As a user/developer, it would be greatly beneficial to me if I could see precisely where the work is being done. And if extra help is needed in some area, advertise this openly. Relating specifically to driver patches, may I suggest that driver changes be added with far less caution than changes to core libraries? I personally believe that if someone like responsible like ATI submits a patch to support their latest hardware, there is absolutely no need to sit on that patch. Get it out there and get it tested ASAP.
There was a reason for the shakeup in FreeBSD (Score:5, Insightful)
Reading Wexelblats email where he basically tells people that this is none of their business, is like hearing an echo of the argumentation launched against new bylaws in the FreeBSD project.
If David is not actively contributing to XFree86, he has no business telling anyone how to run the project.
I think the active developers of XFree86, both committer and non-committers, should grab a copy of the FreeBSD bylaws and elect a new core team.
The FreeBSD bylaws are far from perfect, but it would be enough to get started and once the dust has settled, a revision to more closely match the needs of the new project can be made.
Let me get this straight: (Score:5, Insightful)
a) Fontconfig
b) RENDER-extension
c) Xft
d) Work on transparency
What has Wexelblat done recently? According to his owns words:
a) He hasn't hacked Xfree in years
b) He uses Windows these days
c) If he will code something (unlikely), it will be for Windows
d) Only thing he does related to Xfree is to lurk in the core-devel mailing-list
And here we have Wexelblat flaming Packard! Hello!?! Of the two, it seems that Packard cares ALOT more about Xfree than Wexelblat does! He actually works on it and improves Xfree, while Wexelblat plays Myst on Windows! Looking at their recent activities, Wexelblat should just shut the hell up. He hasn't done a thing, who the hell is he criticizing Packard!?
Wexelblat should be kicked out of the BoD and Core and replaced by someone who wants to work on the project and improve it! It's no wonder Xfree has stagnated if there are core-members like Wexelblat who haven't contributed to the project in years! Ironically, it was he (if I remember correctly, could have been someone else as well) who kept reminding that "Xfree is a meritocracy". If it's a meritocracy, why are there useless deadbeats like Wexelblat in Core? Because of their past accomplishments? Maybe Wexelblat was an uber-hacker 10 years ago, but TODAY, he contributes nothing to the project.
Here it is! (Score:5, Insightful)
Our Take: One thing is clear after reading all these messages: a lot of people are not happy with what's happening with the development of XFree86. It is obvious that more discussion is needed to decide what's going to be implemented and what not, and from these emails there, it seems that there was no real/common direction discussed between the interested parties until yesterday. No real communication seemed to exist!
Let's hope that this open forum list will show what people want and need and will 'open' the XFree86 organization in a way that will allow more CVS commits, as the project seems kind of stagnant and doesn't move as fast as it should have, as some Red Hat employees also noted (for example, direct changing of resolution was introduced just a few months ago with RandR extension, while Windows 95 could do that in 1995).
The XFree86 project always looked a bit conservative to me while more development and openess is needed. There is no need for a "new XFree", but there is a need for more development and 'fixing' on the existing codebase.
Re:XFree Obsolete? (Score:5, Funny)
Psssshht! I mean really! Who wants to setup a thin-client model at their business anyway? I mean saving millions of dollars? What's up with that?!
and it has ugly ass fonts....
Damn straight! Anyone who has zero knowledge about X knows that the fonts are hard coded into the display manager. And that there's no way you can add new fonts to it.
and it has shit write to hardware through TCP ports...
Like, I'm saying, yo! There ain't no client/server interface. When you be sending them X packets to the other computer, you're talking directly to the hardware! That's why every X command is "add ax,bx" and sh*t like that! It's pure assembly, bro!
Everyone knows that the only way to do it is to build a gigantic motherf*cking graphics subsystem into the kernel so that your system resources are halved and your OS crashes every week. Like, that's the ONLY way it should be.
Re:XFree Obsolete? (Score:5, Informative)
When communicating to local hardware, there is no TCP/IP anywhere. It communicates over a local socket. It has been implemented with shared memory, and guess what? It didn't perform any better than over a local socket! That's why you don't see shared memory in XFree today.
And i dunno about you, but my fonts look just fine. They're probably the same TrueType fonts you've seen a million times on Windows.
b.c
Re:XFree Obsolete? (Score:3, Insightful)
>>>>>>>>>
Check out this [gatech.edu] and this. [gatech.edu] The letter shapes, even on the complex Kaufmann font, are incredible. They'll probably look color fringed on a CRT, because I took these with subpixel AA enabled.
hardware through TCP ports
>>>>>>>>>>
Um, XFree86 uses UNIX domain sockets (very fast on Linux) for local connections, not TCP sockets!
Re:XFree Obsolete? (Score:3, Interesting)
Re:Correct link is... (Score:5, Funny)
Re:Bad Link (Score:3, Funny)
Re:Could this be it? (Score:5, Insightful)
>>>>>>>>>
That's hilarious. Graphics hardware has gotten so advanced, that direct access actually *hinders* performance because it prevents the graphics card from optimizing things as well (a developer for the BeOS Radeon driver once told me this). DirectDraw has been getting significantly more abstracted, to the point where it was put on top of Direct3D which, like OpenGL, is a quite high-level abstraction. Look at the way current graphics cards are designed to run:
Making individual calls to the graphics hardware (over the AGP bus) to draw each element is hideously slow. Instead, graphics hardware is designed to take a pointer to a memory region containing a big batch of drawing commands. The CPU fills the command buffer, sets up a DMA on the graphics card, and waits for an interrupt for the GPU to finish processing. As a result of this, OpenGL implementations work the following way: the OpenGL library (in userspace) creates a command buffer from the OpenGL calls the application makes. When the command buffer is large enough (or the application does a flush), it makes a (expensive) call into the kernel driver, which sets up the DMA and drawing operation and returns control back to the app. Notice, that because of the batch-orientation, the performance bottleneck is not in the communication between the application and the hardware. Even if having a client server model makes the flush stage 10 times slower (it's more like 2x or 3x in reality) there won't be a significant performance difference. Given that OpenGL libraries live entirely in userspace, with a small kernel driver responsible for setting up DMA operations and responding to interrupts, there is no reason to believe that putting things "close to the metal" will make things appreciably faster.
let me add to that... (Score:5, Insightful)
The notion that there is anything "direct" about Windows GUI rendering is silly. And for the Mac, it's even sillier, given that it uses a PDF-based system derived from DisplayPostscript. The world has moved to an X11 model, it's just that most application programmers haven't figured out yet that the world has shifted under their feet.
X11 needs major work, things like transparency, rendering, server-side vector graphics, etc.--and that is happening. But one thing it doesn't need is turn into a pretend-frame-buffer library. The other thing it doesn't need is to have a lot of junk and policy hard-coded into the server (widgets, window management, etc.), like some would-be competitors are trying to do.
Re:let me add to that... (Score:3, Insightful)
But that statement doesn't even make any sense. X11 is a protocol: it's nothing more than a well-defined sequence of requests and responses between clients and servers. What does a "direct-rendered" implementation of that mean?
NT has pretty much the same architecture: the display server lives in the kernel and applications live in user space. Requests and responses go t
Re:Could this be it? (Score:5, Informative)
The reality of it is that NT's graphics system and X11 are not all that different. It's just that at a higher level, there is no support for remoting applications in NT.
Yes, it is true that if people wanted to, we could move X11 into the kernel, in analogy to what NT did. We have moved the NFS server into the kernel for the same reason. X11 is probably leaner than the NT graphics subsystem that got moved into the kernel, so this wouldn't be a big deal. However, we really don't need the maintenance nightmare. Keeping X11 in user mode is a sensible choice, even if it costs some performance.
Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.
There are many possible reasons for that. Maybe you are running Gnome or KDE, for example. But X11 isn't at fault.
Get rid of X and you have a desktop OS that can actually compete. You DO NOT abstract the windowing system first and then tack stuff to it (say "OpenGL") - you put the graphics close to the metal and then abstract that instead.
The graphics is close to the metal in X11: you send the server a bunch of high-level operations you want it to execute and it does it for you, using hardware acceleration and highly optimized drawing routines. X11 is really like Apple's Quartz in that regard, only that X11 uses a more efficient binary protocol (server-retained vector graphics is an extension for X11).
By your argument, we should all be programming in framebuffer libraries running in user mode. We had that. It's slow, it's unsafe, and it's very inconvenient. Trust me, I have been there.
That's why DirectX is the darling of game developers.
And how many application developers do you know who program in DirectX? There is a reason why we have DirectX/DRI on the one hand and GDI+/X11 on the other.
Re:Could this be it? (Score:4, Insightful)
I don't think the original poster is talking necessarily about moving the whole of X11 into kernel space. I think rather what s/he is talking about is moving the graphic sybsystem into kernel space and letting whatever else draw to that.
Example that I like to use: Darwin/OS X. The kernel contains the framebuffer driver, and provides a CoreGraphics API to applications. XFree86 has even been modified to use this interface on Darwin, with the benefit that it doesn't have to maintain its own drivers, it doesn't have to run as a privileged user, and, quite frankly, it won't blow shit up like it tends to on Linux.
I think this makes a lot of sense. Put the low-level stuff like video *drivers* into the kernel, then export a standard API that people can use. Let Berlin or XFree or an SVGALib wrapper or whatever use those calls on different virtual terminals, and switch between them. Have the kernel keep track of who's doing what, and ignore whoever isn't front and centre.
It would certainly remove the mess, but it wouldn't help the 'other' distros that weren't the ones that got the driver support (i.e. someone writes Radeon driver for Linux kernel, under GPL, someone else has to write one for *BSD).
--Dan
Re:Could this be it? (Score:3, Interesting)
Well, what do you imagine would be the alternative to "sending commands over the wire"? X11 and NT do pretty much the same thing when you run them locally.
Under NT, the window system lives in the kernel, and graphics is usually drawn by a co-processor. If you call that "local nativ
Re:Could this be it? (Score:3, Insightful)
X does just fine in a desktop environment, despite being designed the way it is. It runs on a wide variety of hardware from Onyxs right down to my iPAQ, provides more than enough flexibility for window manager authors and works transparently over a network.
Heck, most of the time even Terminal Services on Windows 2000 (running
hmm (Score:5, Insightful)
and that meant X turned from snappy enough to blisteringly fast
what is the problem with X then?
the problem is that the linux kernel is optimized on most distibutions NOT for low latency but for high throughput, due to its being used mostly for server boxes.
so if you actually take the time to either pick a kernel that is suitable for desktop use or compile one yourself (which I duly recommend, I learned a LOT from doing so) you have a high-latency/high-througput server kernel. X being slow has nothing to do with X itself, but on the kernel that is running underneath.
your comment about kernel tweaking is sort of like playing quake 3 on a p66 and complaining that its slow and ID software told you to (gasp) TWEAK YOUR COMPUTER! Unthinkable!
Re:Could this be it? (Score:4, Insightful)
You're talking out your arse. The DRI is a direct rendering infrastructure. It applies just as well to 2D as 3D. For example, from the DRI website
The DRI provides a direct rendering path. It's a mistake to think that the only library that could use that path is Mesa. Xlib (aka 2D) currently goes through a slow path; encode to socket to decode to DIX to XAA to DDX to hardware. A DRI/Xlib implementation could go straight from the client to the hardware. Practically you'd only use DRI/Xlib for bandwidth intensive requests. For everything else there's no real value in bypassing XAA.
Your misunderstanding actually highlights a deeper problem. So many people are calling for XFree86 to be scrapped in favour of a direct rendering windowing system. That windowing system already exists and it's called XFree86.
Re:Do you recall Armageddon ? (Score:5, Insightful)
Oh, dear God! People who know what a modern desktop system needs are making XFree86 a better platform for such! They're even going so far as making it possible to use the X font system for something besides western European and east Asian languages!
If KDE people want to work on XFree86, they should go for it. But don't bitch because desperately needed new features get implemented by Gnome people if you don't.
Fonts (Score:3, Informative)
Just to point out. If you are using the large paper white XTerm monitors from the late 80's early 90's Xfonts look wonderful. PC monitors are generally not 75 or 100 dpi. Take your windows system and change the dpi to an X setting and you'll get the same problems.
The issue with jagged fonts on clients is clients
Re:Your logic is flawed. (Score:3, Insightful)
I guess my opinion comes from the fact th
Re:my suggestion (Score:5, Interesting)
I don't agree with Havoc Pennington on many things (like usability matters), but I do agree with this. Keep the client-server model, it's virtually free (wrt resource costs). The real performance sink is in the rendering of fonts, opengl, window managing, redrawing et al. X11 just needs to catch up with the capabilities of current graphics hardware. There's really not much wrong with it, besides that it lags behind somewhat.
This fork might be just the kick in the arse XFree86 needs to get it up to speed again. Nothing like a little ruckus amongst the developers to get the creative blood flowing again. Go Keith!
Re:my suggestion (Score:4, Interesting)
There are other costs. Encoding/Decoding are the big ones. Context switching is another.
The real question is, if you removed these two sources of inefficiency, what would be the actual speedup in terms of graphics performance. For 3D it was lots, therefore the creation of the DRI to provide direct rendering. For 2D? Best guess is almost no improvement at all; the hardware is not capable of going faster. The only exceptions are bandwidth beasts like video that have been solved in other ways.
If somebody wanted to prove the point they could write DRI/X11 as a complement to DRI/MESA.
Re:Wexelblat is right, network transparency pointl (Score:3, Insightful)
Re:Obsolete? (Score:4, Insightful)
1. Find URL and highlight it.
2. Find a handy browser. Realize it has a URL already. Highlight the URL and whack delete.
3. Damn.
4. Find the original app with the URL (hope the window wasn't closed!).
5. Fucking highlight it again.
6. Switch back to the fucking web browser.
7. Finally paste in the fucking URL.
The use of profanity in this algorithm is mandatory.