Slashdot Mirror
The XFree86 Fork() Saga Continues
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."
I have a bad feling that this is goint to be one of those situations where *every* party involved is both right and wrong on some level. Even uglier is the possibility that this could occur on the *same* level. The fact that situations like this could arise in the first place tells me that maybe the architecture of XFree86 (the ideas underlying the code itself) is overly complex for today's needs.
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.
C|N>K
I recently saw somebody try to contribute a new driver to XFree86. He was told that he was welcome to contribute the driver, but that he wouldn't be allowed write access to it once he had handed it over. What a ridiculous policy!
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
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
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?
- pluggable implementations (on Linux alone, there's XFree86, MetroX, Accelerated-X,
...)
- better opportunity for security (though I grant it's not often taken)
- cleaner interaction between applications displaying on the same desktop-- most of the "hacks" won't let applications running in different places share a desktop transparently
For that matter, most desktops released within the last 8 years are so slow and bloaty themselves they can't afford a wire protocol abstraction layer between them and the display driver! Try something truly lightweight, like twm or one of the early incarnations of fvwm with something better than those miserable default configurations, and watch your desktop scream, even with X's supposed weight....when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
That being said, I've never used X in a thin-client environment
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.
A Government Is a Body of People, Usually Notably Ungoverned
Well, I've been working on this exact problem for a long time now, as have numerous others. I am a (currently lurking) member of Xfree86 (back in the dark days when you had to sign non-disclosures). I've met and talked with a few of the core people even.
/include /server/lib /server/communication /server/protocol /server/modules /server/windowing /server/rendering/DRI /server/rendering/Mesa /server/rendering/XRender /server/font /server/drivers/xxxx /server/plugins/ /client/lib /client/blah blah
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
I said no... but I missed and it came out yes.
One of the problems with X11 is nobody is working on X12. Hell, nobody is working on anything better than X11R6 as far as I can tell. I remember an article in a UNIX magazine about five years ago talking about multimedia extensions, but that was right before the X consortium sorta went *boom* or whatever it is that made them completely invisible (do they still exist?) now.
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.