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."
Time for Fresco?
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
My question: does stsf use it's own font renderer? I highly doubt they came up with something nicer than freetype without anybody really making a buzz about it.
A deep unwavering belief is a sure sign you're missing something...
I spent a brief time working as a contractor for a Linux distributor (now defunct). During that time, I was given the task of maintaining portions of XFree86's XInput and DRI code. What I saw, I didn't like.
Efforts to extend XFree86 to support modern graphics capabilities (XRender, Xft, R&R) are floundering because the level of skill needed to develop and maintain them is simply too high. The XFree86 codebase reinvents many wheels, is difficult to maintain and really does carry a lot of legacy footwork that makes it difficult to work with.
That said, XFree86 works amazingly well for what it is. I just don't think XFree86 development is sustainable. The same effects can be achieved with a thin layer like DirectFB without the overhead. You get the same functionality, usually better performant and with far less code necessary in the implementation. Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
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?
I don't agree with Havoc Pennington on many things (like usability matters), but I do agree with this. Keep the client-server model, it's virtually free (wrt resource costs). The real performance sink is in the rendering of fonts, opengl, window managing, redrawing et al. X11 just needs to catch up with the capabilities of current graphics hardware. There's really not much wrong with it, besides that it lags behind somewhat.
This fork might be just the kick in the arse XFree86 needs to get it up to speed again. Nothing like a little ruckus amongst the developers to get the creative blood flowing again. Go Keith!
...after reading your long message, and also reading David Wexelblat's message, and reading all the stuff that came before, it's pretty clear to me: the X Core Team doesn't want to talk. They don't want outside input, they've deluded themselves into thinking that other Open Source projects are just as closed as they are, and they really don't see where all these outsiders get the right to have an opinion. They ask why you (Keith) didn't open a discussion with them, but then act hostile to nearly everything that is discussed.
I don't know how to write a driver for X, but I do know people. And you're banging your head against a wall as long as you try to work within their system. Good luck with whatever you decide.
My Greasemonkey scripts for Digg &
- 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
There are other costs. Encoding/Decoding are the big ones. Context switching is another.
The real question is, if you removed these two sources of inefficiency, what would be the actual speedup in terms of graphics performance. For 3D it was lots, therefore the creation of the DRI to provide direct rendering. For 2D? Best guess is almost no improvement at all; the hardware is not capable of going faster. The only exceptions are bandwidth beasts like video that have been solved in other ways.
If somebody wanted to prove the point they could write DRI/X11 as a complement to DRI/MESA.
I was initially skeptical of Keith Packard's fork but after reading his email, I support it. He addressed the issues that I have been complaining about for years.
KeithP is one of the few people who could make a fork work.
I have a hard time with David Wexelblat who doesn't work on XFree86 and doesn't even believe in it, insulting one of the key developers.
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
I worked for years on dumb X terminals. The environment was
a) tremendously reliable
b) very easy to maintain
c) offered users tons of freedom
Contrast this with your typical Windows corporate setup. Anything other than total lockdown makes the system entirely unmaintainable. As a result user / desktop support ratios are very high and users and constantly frustrated by how little they can do. Virtually every corporation should be running dumb X terminals. It really would cut costs and empower employees.
Take a simple example like software installation. On a Unix system I can safely let users install anything. The apps they install can't run with any more privs then they have and they can't hurt the system.
On windows OTOH letting people use any printer in the building means they have to have permission to install drivers. Letting people install drivers is:
a) hard because they are forced to understand details of printer models
b) allows them to completely muck their system up
It's true that this (application) client/server paradigm is tilted heavily toward the idea of centralized servers accessed by smaller clients. And where this topology exists and is necessary, people use X this way and it matters. For average users, it doesn't.
But that's the status quo, and it won't last.
We're going to inevitably move to a distributed computing model, and it only makes sense to do this on a per-application basis as a first step. Almost all the pieces are there. The piece that isn't there is a mechanism that matches slack to need transparently.
In my (years past, not current) daily use of UNIX workstations, I would manually spread my workload around to different boxes just because it made sense to do so. But it was a pain. Imagine if that were automatic and transparent.
In my opinion, X's network transparency will once again become incredibly useful. It's utility just needs to be properly leveraged.
As usual, the people who bitch about X are going to have to find some new reason to bitch about X.
Quite frankly, the whole stink with XFree86 reminds me very much of ICANN. Technological snobs who won't listen to anyone else, have closed off public participation, aren't transparent, and now are defaming someone who rightly criticizes them. Furthermore, they are blundering. Why should Xfree86 drivers not be modularized? I only have one fucking video card. I don't need to download the drivers for every video-card Xfree86 supports. Xfree86 has also done an atrocious job of integrating the latest drivers from graphics chip corporations, like ATI. Their failure to promptly incorporate these drivers has alienated hardware developers. Why should ATI spend millions of dollars to make drivers for XFree86, if it takes them so long to incorporate them?
The actions of XFree86.org convince me that they want to restrict user choice in the GNU/Linux world, and prevent anyone else from running any X11-implementations other than XFree86. Their refusal to modularize drivers is one thing convincing me of this.
I can not think of any major projects which are as poor as XFree86 in regards to including the community and being accountable to the community. Many of the people within that "organization" are in fact figureheads who don't even believe in XFree86, like one of the founders linked to. If you don't use XFree86 at all, and only use Windows, then imo, you have no business being part of an XFree86 team.
Keith is right to fork off XFree86. He has tried to address his concerns from within the organization, and has been unable to do so. Just like Auerbach. There is only so much one crusader within an organization can do when the rest of the organization is bent on corruption.
XFree86 is proof that even a project covered under a license approved by the OSI and the FSF can be corrupt and non-transparent.
social sciences can never use experience to verify their statemen
It seems to me that all parties involved need to cool down and then come back to the table with a reasonable attitude and work out these issues. Keith has some valid points about the sluggish response of XFree86 development in certain areas, although I disagree with his means of protest. A fork would likely only cause chaos and be detrimental to the cause of unified desktop standards and Open Source acceptance. It is my opinion that there are times when standards and compatibility are far more important than performance and eye candy.
Keith, if you are listening, may I suggest that you formally and thoroughly document your objections to current XFree86 development and provide constructive criticism on how it might be improved? If there are technical complaints, such as relating to performance, perhaps you can write code to prove the need for change.
XFree86 team, if you are listening, may I suggest that a patch tracking feature be added to the official web site? For example, if a patch is submitted to support a new XRender feature but not yet committed to CVS, show this and offer the patch for download right there. As a user, it greatly frustrates me to not have any idea when new features and support will be added and you must admit, the XFree86 release cycle is rather slow. As a user/developer, it would be greatly beneficial to me if I could see precisely where the work is being done. And if extra help is needed in some area, advertise this openly. Relating specifically to driver patches, may I suggest that driver changes be added with far less caution than changes to core libraries? I personally believe that if someone like responsible like ATI submits a patch to support their latest hardware, there is absolutely no need to sit on that patch. Get it out there and get it tested ASAP.
Given that so many popular widget sets / window managers / desktop themes do like to stick shading and bitmaps on everything, and that many users think this looks kewl, and that in any case Mac OS X and other systems seem to exploit the video card's hardware to do this stuff quickly, wouldn't it make sense to fix the X protocol so that such eye candy can be displayed without slowing the system down too much?
-- Ed Avis ed@membled.com
I agree. In my previous job my main working machine was a Win2k box with PuTTY and a commercial X server installed. It's actually a very nice environment to work in -- I could use Explorer to administer and manage files on my remote linux server, editing PHP code with my favourite Win text editor (ConTEXT) and at the same time using Outlook (not my fave, but the company standard), and develop Win32 code. Best of both worlds. Plus I got to wow all my surrounding Windoze-only colleagues with impressive looking KDE themes!
Without X's network transparency, I'd be upstairs on the linux box half the time, separated from colleagues, and reducing my efficiency.
The only downside -- having to walk upstairs to change CDs occasionally!
However, I also see the need for a slimmer, leaner, meaner X, with a fast (perhaps even kernel-level?) direct rendering system, with less cruft. I have a lowly PIII 550 256Mb at home, and X is a bit of a pig; whereas Win2K's GUI just whizzes along nicely.
I don't necessarily think that network transparency + a fast GUI are mutually exclusive. Surely it's possible to come up with a high-speed rendering and input API that could be controlled remotely via a swappable
I can envisage something like an OpenGL-like pipeline, with a serialised command input, that could be streamed to a specialised hardware accelerated layer on the local machine, or via network to a remote display server? The remote server could afford to be quite minimal in this scenario - a glorified video driver with support for input devices. Surely most of the code necessary for a prototype of this system is already out there?