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]
Article... (Score:3, Informative)
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: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
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: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.
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:Hmm. That's not right... (Score:1, Informative)
The FreeBSD Core Team is elected by the Committers.
Hardly democracy - just a more formalized way that people can work their way into the meritocracy.
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.]
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: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.
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/XConsortium X11R6.6 [x.org] server.
If you want a windowing system that's not based on X11, your options are a bit more slender, but they're there. The Fresco [fresco.org] project (formerly "Berlin") looks promising, as does PicoGui [picogui.org].
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 not having the right font sets.
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..
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:
Optimize your system... (Score:2, Informative)
ok, it's an athlon xp 1800+, but it is way smoother that windows XP running on the same machine, and i would describe the "feeled" improvements as follows:
XFree 4.2: can't recognize any speed differences
nvkernel: opengl support, no differences for ui
preempt: avoids glitches on heavy load, a must
2.5.65 kernel: ui stays responsive even on heavy load, very cool.
liquid style engine: incredible performance boost.
the whole kde ui gets rocket fast and responsive after switching to it. just try it!
sure, it's bleeding edge system, but i have no stability problems atm and kernel 2.5/2.6 will be in distributions soon, too...
Re:Correct URL (Score:3, Informative)
Re:XFree Obsolete? (Score:2, Informative)
As I'm posting this from a Syllable box with ABrowse, I can only really say that it feels much faster and more responsive than X. I am subjective and heavily biased however, so please take that with as many sacks of salt as you require
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:Direct changing of resolution just intoduced? (Score:1, Informative)
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.