XFree86 Fork Gets a Name, Website

Piethein Strengholt writes "Today the Xfree86 fork is a fact. A new project has started and is located at: xouvert.org. Xouvert has been started due to the corporate structure and the slow development of XFree86. They hope to reduce the risk to XFree86 of incorporating new drivers and features."

Comments

Why not just implement a "testing" branch of X?

[mhesseltine]

It seems that this group wants to push the envelope of features in X. Why not just do something like the Linux kernel numbering? e.g. 2.4 -> stable, 2.5 -> testing. Then, people could make a decision as to if they wanted to run the bleeding edge in an attempt to use new features. It'd also save the hassle of building for 2 graphics systems, and merging patches between the two code bases.

I hope they integrate NX compression

[divec]

If they're trying to include useful third party contributions, they could do worse than include NX, a revolutionary new compression and proxying technology that makes it possible to run an X session over a 9600 modem at a useable speed. But I didn't completely understand their policy on licences (the NX infrastructure is GPLed, whereas X is under the MIT licence).

Re:I hope they integrate NX compression

[listen]

No. You've completely misunderstood.

I am talking about exporting your whole local session to another box. The server side, not the client side. The server side of NX makes a whole other X server, ie a new session. I'm talking about taking your normal X session, and exporting that.

Look at KDEs remote desktop feature. At the moment, it is a horrible hack, which takes screen shots and uses the VNC protocol to send them over the network. In an ideal world, it would just connect to the X server, say "I want all the drawing commands from now on.", and the X server would send that, which would be then translated to VNC or RFB or NX. This would be far less heavy weight, and far more responsive.

Re:On the first line of the page.

[stephenry]

As far as I've been led to believe, there are *no* developers for the current Xfree, that being the need for a fork in the first place. Whereas now people may show an interest in working on Xfree, they have little hope of ever making an actual contribution (due to politics and the general lethargy surrounding the head honchos). So in that way, there really aren't any developers to lose.

I personally applaud this fork, anything that encourages support, and let's be honest, momentum, to a application as critical as X, can't be anything but a good thing. One thing is for certain, these guys have made an effort to changes things; and that's far more than those in Xfree, or the aborted mess of a website, xwin, have done!

Re:Excellent

[aussersterne]

All of the major UNIX vendors at one time or another have looked at implementing a shared memory transport for X messages on the theory that it would reduce overehead. In benchmarking, however, it was routinely found that Unix domain sockets imposed very little or in some cases less measurable overhead than shared memory. Net effect: no speedups to justify implementation. And in case you weren't aware, we do now have DRI and XV for 3D and video, which do dump network transparency in favor of speed in these extreme high-bandwidth cases. In fact, Linux+X outperforms Windows in terms of raw frame rate in many games on the same hardware (i.e. Quake+Nvidia).

But that kind of raw data pumpking is not very useful for normal applications, which don't need heavy bandwidth at all! You seem to think that your AGP bus is a fat-pipe framebuffer and that given a simple enough toolkit, it would somehow be a speedup to blast 32-bit screen dumps onto it at full speed. But even if this were the case, the content of those dumps would have to come from somewhere. In the API of every modern windowing system (including MS Windows) you'll find heavy reliance on some sort of message passing interface to make the nuts and bolts of the user interface; in short, every windowing system is "network transparent", it's just that most of them are only flexible enough to use one transport method, unlike X, which lets you choose the transport method. And I challenge you to find me any non-motion-video non-3D desktop application that is bandwidth or latency limited even on 100Mb ethernet, much less gigabit ethernet or local transport (get netperf on your own PC and check out the unix domain bandwidth!) Most any kind of local transport is going to have negiligible overhead compared to the overhead imposed by data inefficiencies in toolkits themselves (message redundancy, uneeded refreshes, etc.), and neither of these runs up against any kind of bandwidth or latency ceiling on a modern PC either. Both KDE and GNOME have major architectural inefficiencies outside of the widget rendering path. Search google.

And as far as burden of proof goes, you're the one proposing to throw away one of the most important features of the Unix desktop. I often hear complainers say that "90% of Unix users never need network transparency!"

I don't buy that number. You're getting the Windows market confused with the Unix market mate, I'd guess that 70-80% of regular Unix users do make use of network transparency becaue the vast bulk of regular Unix/X users are doing so in an administrative capacity. I'd love to see a Slashdot poll on this point.

Re:Terrible choice of name.

[antiMStroll]

What was wrong with "Xwin"?

It's already taken?

I suggest a re-name, but with an open naming contest this time.

In what system do we force project names on independent developers who didn't ask for an opinion? If Xouvert is a mistake, it's theirs to make. The code will survive if the project doesn't.

Re:Drop XFree86, use Y instead

[jd]

Fresco, which got renamed to Berlin, which got renamed to Fresco, seems mostly delayed due to a schizophrenic attack.

Anyway, Fresco|Berlin is merely a GUI built on top of the GGI/GII interface. XGGI does much the same, but works with X instead.

The problem with X is that it is too bulky. We need a RISC GUI, with layers which supply the X API. GGI/GII seems like a good foundation. KGI does, too, but development with KGI is too stop-go.

Anyway, switching protocol isn't the solution. Neither is a simple re-implementation, or the addition of new code. What you need is a compartmentalization of the code, so that each part of the code can run efficiently and quickly.

Think of it this way:

• X can't exploit clustering or SMP, because everything is built into one server, or packed into humungus libraries the size of a Moa (and about as fast)
  
• Even though it's more modular, these days, there seems to be no feature to swap out modules that aren't actively in use, to conserve memory - they're brought in at load-time, not just-in-time
  
• Even though X is client-server, X has no capacity to balance the workload according to the available resources of the client and server (a-la MOSIX)
  
• There is very minimal "accelerated" code for specific processors or graphics cards, which is why it is much slower than many proprietary implementations. (Even the Gnu C Library has a fair chunk of accelerated code!!)
  
• X is pixel-only, which makes using vectors, curved shapes, or indeed anything non-pixel, a horrible pain -- it also makes anti-aliasing horrible, as you can't supersample a quantized system
  
• It's very very hard to take advantage of new features or capabilities with X, as the alpha-channel fans have discovered -- you can bolt onto it in a heirarchical manner, but X isn't very extensible laterally
  
• I like the X protocol, but I think we should abandon the concept of having just one server that supplies the whole protocol and also nothing but the protocol -- break X into fast-acting independent components which can be added or removed on-the-fly, producing a protocol that is shifting to do exactly what you want, not merely everything the designers could think of
  

Re:On the first line of the page.

[Mark Bainter]

While I'm not against going out on a limb and doing something innovative, I just wonder if it would have been better to try and accomplish this within the project that currently exists?

Well, maybe because the XFree team isn't interested in anything except improving graphics drivers? I mean, I love X, I think it's a great concept, but XFree86 needs improvement. Not necessarily in overal concept, but in implementation. Lots of cleanup and rewrite work to be done that could make X a lot better than it already is.

But if nobody in the core team is interested in any of that, then you have no choice but to try other methods of getting it accomplished. However, I'm disappointed that I don't see any of the X developers I"d expect to see listed on the project page. It makes me hesitant to jump on this thing as a great move. Regardless, I don't think it's a bad move, but it's not the fork I've been waiting to see. I guess we'll have to see how things play out.

I'm encouraged by their choice of repositories though. It'll be good to see how Arch works for them. I anticipate they'll be very happy with it.

Agreed!

[MarcQuadra]

I'm with you, while X isn't the simplest thing one could think of, it really does perform amazingly well. The frame buffer as a 'performance solution' is a total dead-end as writing a stream of pixels to a buffer is a LOT slower than using X to draw complete objects.

I do think X is a bit creaky though, maybe it is time to start a new one, one where major (and even compatability-breaking) changes can happen. Some things on my wishlist:

*A single, standard, simple font system.

*Integration of a more modern toolkit and WM, even if it has to borrow heavily from GTK+ or another project. This would be inclusive, it wouldn't prevent you from using other toolkits and WMs (think WindowMaker instead of TWM in the base set).

*Ability to run like Quartz Extreme (as an OpenGL-based system). Also, not as a requirement, just as an option.

*There's no excuse for not vectorizing this from the bottom-up, and we'll be thankful when the commercial OSs get this done and we've already got it. Think about running your monitor at 1600X1200 and telling the system it's 200 DPI so it zooms everything accordingly. Apple has this up their sleeve now, and Longhorn might unleash it on Windows.

*Transparency, which personally doesn't get me hot and bothered, but I guess people think it's cool.

*Ability to act as the 'console' layer for the OS, no more framebuffer-for-console, X for graphical. Have the thing run a full-screen native terminal, and have the OS work with it.

*extensive database of video cards and monitors for easier configuration, this should be integral to the graphics system. It took me a LONG time to find the specs on some of my monitors and I'd rather not do it ever again.

*Generally simpler/more elegant design. I'm pretty sure that a lot of what's in XFree86 today is there just to prop itself up, while a newer system might have a better chance of coming out with a clean design.