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 can't help myself...
;^)
"The saga continues..."
"Use the fork() David"
(BTW, expect to bring about introduction of new post-rating: +5 Lame!
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
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.
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
Whatever happened to choice in this debate?
We can choose between various window managers, various linux flavors, and even office suites. 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?
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
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
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...
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
Mechanism, not policy. Interface guidelines are the domain of toolkits and environments ala KDE, GNOME, not the domain of the low-level graphics subsystem like X or Fresco.
STOP . AMERICA . NOW
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.
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.
- 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
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 was optimizing my mandrake system for audio use, which meant installing a pre-emptible and low-latency patched kernel source package and recompiling it for my specific cpu / architecture
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!
Jag pratar lite svenska.
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.
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.
Just because YOU don't, that doesn't mean that OTHER PEOPLE don't.
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
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.
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.
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."
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.
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.
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.
Poul-Henning Kamp -- FreeBSD since before it was called that...
I use it extensively almost every day I sit down in front of a computer to do anything more than check my e-mail. I think most anyone who has to do a fair amount of work on multiple UNIX machines also uses it frequently.
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.