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."
http://www.osnews.com/story.php?news_id=3090.
Not http://slashdot.org/TheXFree86Fork()SagaContinues
I am TheRaven on Soylent News
I looked at some of the screenshots for stsf and I think that it's pretty sweet. The standard Motif font menu labels are hilarious though, the selectable fonts look awesome and the old motif fonts in the menus look terrible.
Here's some links to the screenshots of stsf running on Solaris 9:
xclock -digital -fg yellow -bgpixmap SolarisLogo.pm -fga 0.5
LANG=zh_CN.UTF-8 xclock -digital -bgpixmap RicePaper.pm
My blog
How this got modded up is beyond me. Not only is it not insightful, it's downright wrong!
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
As David W points out, XFree86 is around 11 years old. I was around when the project was started and was a low-key member (my name was all over the documentation for many years afterwards and may still be, I haven't checked for a long time).
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...
wouldn't be allowed write access to it once he had handed it over. What a ridiculous policy!
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.
The line must be drawn here. This far. No further.
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.
I was appalled at how many folks jumped on Keith after the initial /. article. I mean, they were basing their responses on a one-sided tale.
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.]
I manage several smallish lab networks on a volunteer basis that make heavy use of the 'thin-client' capabilities of X to offer a room full of computing services to users from a single SMP server machine. These capabilities have reduced cost by an order of magnitude and greatly simplified the administration that I have to do.
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.
STOP . AMERICA . NOW
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:
-- ;-)
Kuro5hin.org: where the good times never end.
I really dont understand people who are complaining about network transparency and who wish to destroy one of Xs best features, and destroy Xfree86 as a X11-compliant implementation, by changing the X protocol. It seems to be working very well as it is. I use network transparency all the time to run applications running on a fast server across to several cheap, old PCs. It is a crucial feature, and provides much better performance than purely bitmap protocols. It has saved a lot of money, instead of having to buy a bunch of expensive workstations, you can simply use an application server, and some old ancient PCs as terminals which cost next to nothing, just try that with XP . To share applications on XP (a single application, not a display), you have to pay hundreds of dollars in licensing fees just for the products to do so. This feature has been avialable on X for 18 years, and freely avialable thanks to Xfree86.
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
X.org is the replacement for the old X Consortium, and it is working on new technologies for X, including the Media Application Server (MAS), a "network transparent sound protocol that runs in parallel with X to deliver the sound portion of apps."
Admittedly, it has been almost two years since X.org released X11R6.6, 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.