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."

Comments

Here it is!

[Gortbusters.org]

Now, that was an interesting reading in the XFree86 forum mailing list. We get individuals, companies like Sun, SciTechSoft, Red Hat etc. 'fighting' for issues varying from what XFree86 really needs, down to replacing fontconfig with Sun's stsf, XFree86 co-founder David Wexelblat saying that XFree is today obsolete and that needs to be replaced with a direct-rendered model (by retaining backwards compatibility), Keith Packard replying as to why a new organization to handle X is needed, and more.

Our Take: One thing is clear after reading all these messages: a lot of people are not happy with what's happening with the development of XFree86. It is obvious that more discussion is needed to decide what's going to be implemented and what not, and from these emails there, it seems that there was no real/common direction discussed between the interested parties until yesterday. No real communication seemed to exist!

Let's hope that this open forum list will show what people want and need and will 'open' the XFree86 organization in a way that will allow more CVS commits, as the project seems kind of stagnant and doesn't move as fast as it should have, as some Red Hat employees also noted (for example, direct changing of resolution was introduced just a few months ago with RandR extension, while Windows 95 could do that in 1995).

The XFree86 project always looked a bit conservative to me while more development and openess is needed. There is no need for a "new XFree", but there is a need for more development and 'fixing' on the existing codebase.

fork() power

[blitzoid]

If this leaves the XFree86 project as a more flexable, open, and more modular project, then so be it. I'm all for anything that can improve performance for *NIX GUIs.

From everything I see, it's too late in the game to make a new graphical interface - unless it has a compatability layer to work with X apps. But even then, we'd need to develop it FAST to make sure *NIX doesn't fall behind in the OS game.

Hmm. That's not right...

[TheRaven64]

Quoth David Wexelblat:

The concept of the community voting for membership in the leadership of the project is an almost, if not totally, non-existant concept in the Open Source world (feel free to show me examples). I'm not talking about advocacy groups, like Linux International. I'm talking about development projects. XFree86 has no interest in this, as far as I can tell.

I can think of one right now. So can he, since he mentions it a few paraghraphs later. The FreeBSD Core team is elected. To be core on FreeBSD you have to be an active developer, and have not pissed too many other developers off recently (or at least pissed them off less than most other people). Sounds like a good idea to me...

Oh. Wait. Sorry, I forgot. FreeBSD is dead. I really should stop using it sometimes soon. Can't be using a dead OS on my desktop...

Choice?

[Fedhax]

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?

Re:Choice?

[Elentar]

At some point, creating choice for it's own sake becomes ludicrous. For example, you have a choice in the auto dealer you purchase from, the make of car you buy, what kind of fuel it uses, and so on. But you don't usually see two highways that follow the same route - you don't need a choice there, just one that can handle the traffic. Let the smaller roads get people where they want to be.

A windowing subsystem needs to provide enough framework to make application development easy and enough flexibility to allow developers to do what they want to do. Windows software is not mainstream today because the developers had a choice of subsystems - it is mainstream because they wrote for the one that was biggest and trusted Microsoft to provide compatibility in future versions. Brilliant move, that.

Unix has long been plagued with vendor-specific code that hinders broad development efforts. The **only** reason Linux is so popular today is because of the single windowing system. Average users don't care about how fast it can fork() or whether it's virtual memory management is superior - they want lots of apps, they want them to be pretty and they want them to all run on top of each other.

Forking X is a terrible idea. Perhaps if they go for it, they'll choose an appropriate name... Y?

-Elentar

Re:Choice?

[Hard_Code]

"The **only** reason Linux is so popular today is because of the single windowing system."

Actually that's way wrong, and if you notice Linux is so NOT popular today on the desktop. (it is popular on the server where graphics largely don't matter, or at *least* were not a convincing feature)

Re:All I can say is.....

[TheRaven64]

No. Not time for Fresco. Time for Fresco is when Fresco is completed (or almost completed). Time for X now. Time for Fresco later. You'll never get anywhere if you release buggy incomplete software before it's ready for use. (Insert cheap shot at MS here).

Re:All I can say is.....

[aussersterne]

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.

Re:Could this be it?

[be-fan]

you put the graphics close to the metal and then abstract that instead. That's why DirectX is the darling of game developers.
>>>>>>>>>
That's hilarious. Graphics hardware has gotten so advanced, that direct access actually *hinders* performance because it prevents the graphics card from optimizing things as well (a developer for the BeOS Radeon driver once told me this). DirectDraw has been getting significantly more abstracted, to the point where it was put on top of Direct3D which, like OpenGL, is a quite high-level abstraction. Look at the way current graphics cards are designed to run:

Making individual calls to the graphics hardware (over the AGP bus) to draw each element is hideously slow. Instead, graphics hardware is designed to take a pointer to a memory region containing a big batch of drawing commands. The CPU fills the command buffer, sets up a DMA on the graphics card, and waits for an interrupt for the GPU to finish processing. As a result of this, OpenGL implementations work the following way: the OpenGL library (in userspace) creates a command buffer from the OpenGL calls the application makes. When the command buffer is large enough (or the application does a flush), it makes a (expensive) call into the kernel driver, which sets up the DMA and drawing operation and returns control back to the app. Notice, that because of the batch-orientation, the performance bottleneck is not in the communication between the application and the hardware. Even if having a client server model makes the flush stage 10 times slower (it's more like 2x or 3x in reality) there won't be a significant performance difference. Given that OpenGL libraries live entirely in userspace, with a small kernel driver responsible for setting up DMA operations and responding to interrupts, there is no reason to believe that putting things "close to the metal" will make things appreciably faster.

The key issue

[steveha]

The key issue here, as far as I can tell, is whether the XFree86 guys were correct to kick Keith Packard out.

On the one hand, David Wexelblat has strong words about Keith Packard's actions:

What Keith has done is among the most low-class, unprofessional, and tactless things I have ever experienced in my professional career.

For Keith to blatantly lie to the Core Team about what he was doing is utterly unacceptable.

But what Keith is doing, at least how he's handled it, is just flat out wrong. It's literally dishonest, and morally repugnant. Doesn't mean that there aren't some valid issues to work, or that there is no need for branching, but (a) it remains to be proven, and (b) I'll be damned if I'll quietly accept it being done by someone who is lying to my face.

Whew. On the other hand, here's what Keith Packard has to say:

Some have suggested that this was a secret attempt to undermine the XFree86 project: this was not my intent. I have tried as hard as I can to work within the existing XFree86 structure.

It's hard to think that this is some kind of misunderstanding. Either Keith has been lying, or else he hasn't. It's impossible for us to really decide for ourselves, since the emails containing the alleged lying are not public.

David Wexelblat said:

There is an email thread documenting this. Some members of the BOD wanted to post the email, or quotes therefrom, with the announcement. I and some of the others were utterly uncomfortable doing that. I don't think anyone on the BOD or Core Team would have any issues with an independent audit of this email thread, if there are concerns about the veracity of what I say, but airing that in public isn't appropriate, IMHO.

I'd like to see someone I trust given the job of auditing those emails, and judging whether Keith Packard has in fact been lying.

P.S. A fork might be a good thing, in the end. Keith Packard says he believes his fork can attract more developers and improve more quickly than the status quo. If he can pull that off, we will all be better off. But unless he can clear his name, he may have trouble attracting developers.

steveha

Re:The key issue

[RedWizzard]

One thing that struck me was the implication from the core team that they didn't know about the issues that Keith Packard is concerned about and that Keith never said anything. There are piles of people on the list and elsewhere with the same concerns, particularly the difficulty in getting code into the official tree. That leads me to conclude that the core team are hopelessly out of touch with the majority of their community, and the fact that no one has been added to core since 1999 (or perhaps this is out of date?) supports that conclusion.It's also interesting that the mailing list that these discussions are now happening on has been in existance since the 19th of March, some 3 days.

Unfortunately we don't, and probably never will, know the exact circumstances behind this split in developer ranks. It mirrors Matt Dillon's recent dismissal from the FreeBSD project.

Re:Do you recall Armageddon ?

[dvdeug]

Please know that with the next coming XFree86 version you get a lot of GNOME components without even knowing it. code like, GNOME-XML, pkgconfig, fontconfig, xcursor and xft2 were mainly written by people who're heavily involved into GNOME development

Oh, dear God! People who know what a modern desktop system needs are making XFree86 a better platform for such! They're even going so far as making it possible to use the X font system for something besides western European and east Asian languages!

If KDE people want to work on XFree86, they should go for it. But don't bitch because desperately needed new features get implemented by Gnome people if you don't.

X design decisions

[camusatan]

In regards to all of the 'X is obsolete' arguing -

There was a design decision made when creating X that displaying windows on a local workstation should be as easy as displaying windows on a remote workstation. This decision affected several things about X, and made the X API's extremely difficult to learn (pick up an X book, you'll see), but extremely powerful.

Basically, what some people are saying is that that decision was wrong - that it's not correct to design an entire graphics API around the concept of displaying windows locally and remotely.

Really, the most objective way to analyze that claim is to look at how many windows users open on their own workstation, versus how many remoted X applications they run. Compare that percentage. Then take a look at how much more complex X was made to handle the eventuality of having to handle remote windows, etc, etc. Is it worth it?

Me personally, I don't think so. The only real use I've had for remote X applications was in terms of systems administration - but this is stuff I could have done as easily with something like ssh, or, if I needed some kind of graphics, PC Anywhere, or Timbuktu. And for applications to be faster, better behaved, and less bloatey, I'd be willing to install some PC anywhere-style application on the occasional remotely-controlled server. For the most part, people would be able to leave it out.

That being said, I've never used X in a thin-client environment - it's possible that it could perform quite well - and I've heard that the X protocols are very good at keeping network use down. It still strikes me as not the right distribution of power between server and client, but what the hell do I know?

Re:You know what?

[Master Bait]

I just think the architecture of the project is what's a mess. I compiled the new 4.3 on a Mac yesterday, and I find the project is stuck in an Imake Spin Cycle. Oh sure, somewhere in all that mess is a document that tells you how to compile 'just the servers' or maybe tells you how to build it without the fonts, or maybe even how to build it without those pathetic utilities, fonts and never-updated docs.

If I was King of XFree86, I'd first open it up to more people, then I'd tear out the utilities and put them separate, put the fonts separate, throw away the /xc/config monstrousity and replace that with configure --prefix= etc. etc. Separate pswrap, mkshadow, xau, xnest, xext, all the gl's, xt, xv, xi, pex, speedo. The list is wildly bloated. Sure, maybe all that junk can be separate projects on the same Sourceforge page, but as it stands now, it is a whale.

I've also downloaded and compiled Packard's stuff, and I think his is pretty messy, too.

let me add to that...

[g4dget]

Let me add to that Windows has had to add function calls that return "promises" in order to continue the illusion of being a frame buffer library when in reality, it's just a very messy and less functional implementation of an X11-like client-server architecture.

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.

Hmm

[Hard_Code]

Something that David Wexelblat posted bothers me. I'm sort of confused by his stance, because while he admittedly does not use X, he is at the same time airing his criticisms of it, yet refusing to let Keith Packard fork gracefully. Anyway the bit that bothers me:

"- There is no reason for Core Team matters to be public. This is the
leadership forum, not a public forum."

What is the difference between Core Team members keeping their plans secret and not allowing the public to participate, and Keith Packard keeping *his* plans secret and not letting the Core Team know about them, which he is getting lambasted for? Sort of hypocritical. If the X license is an Open Source license, the Core Team doesn't have any special rights with regard to modification and distribution than Joe Hacker who wants to fork it does. X (X11R6) hasn't changed in a hell of a lot of time (relative to most opens source projects), so what is the purpose of shielding XFree from the public? Some panties need to be untied.

Re:Hmm

[sigwinch]

The difference is professionalism. The core team here is an organisation which Keith was a part of. It isn't professional to try to fork, solicit people to join and go behind your team's back, whilst still being a member of the team.

I call bullshit. Utter total horseshit. Professionals *almost never* go straight to the big audience with their ideas. You go privately and discretely to various interested parties and see what they think. If they think the idea stinks, then you let it die quietly and no one is the worse for wear. If they come up with angles you missed or things that aren't optimal, you revise your ideas and go back for round two. Lather, rinse, repeat. The idea either dies, or becomes suitable for mass consumption. In addition, the process polishes the idea, and forces you to get all your ducks in a row so you can answer objections with facts.

If Keith found his dissatisfactions with the core team irreconcilable, that's fine - it happens. He should resign from the team, and then fork and ask others if they'd like to join.

Again, I call bullshit. It's way too easy to delude yourself into believing that your Wonderful New Idea is The Greatest Thing Since Sliced Bread and will Definitely Bring World Peace. It's an occupational hazard for engineers. The solution is to discretely bounce the Wonderful New Idea off other people, who should ideally be jaded, bitter, and hard-nosed. (When I was doing this once, a colleague responded "Are you smoking crack? Or do you take it rectally?" That's the kind of person you want.)

If you don't take this approach, you run a terrible risk of proposing an awful idea to a large audience. The more audacious the idea, the more credibility you lose. Hell, even really good ideas are often hard to swallow if somebody just does a brain dump of their first draft.

Either you're a member of the team or you want to strike out on your own.

Again, bullshit. It is often impossible to know whether you want to strike out on your own without quietly discussing it with other people.

You are essentially arguing that it is unprofessional to explore the job market without first quitting your job. Dumb, dumb, dumb.

As far as I can tell, XFree86 Core are hugely insecure and neurotic. People with self confidence and competence would have simply made Keith a counteroffer. Happens all the time in the real world, which apparently is not where XFree86 lives. E.g., Senior Engineer at Small Turbine Corp. interviews at Pratt and Whitney. What STC execs should do when they find out is to shit themselves, clean up, and make a counter-offer. What they should not do (but alas sometimes do anyway) is fire Senior Engineer on the spot.

The fact that XFree86 Core went apeshit demonstrates (1) they know what Keith was saying is true, and (2) they have a pretty fucking big chip of their collective shoulder. The fact that they went into a frenzy of mailing-list creation, Bugzilla installation, and project reorganization proves #1 beyond any doubt. Other evidence covered extensively elsewhere strongly supports #2.

Re:Hmm. That's not right...

[Anonymous Coward]

Hmmm. Someone should clue in the Debian project that they're somehow doing a nonexistent thing by holding regular elections for their leaders.

hmm

[krilli]

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!

Re:Maintaining XFree86

[rsidd]

- Separate the frame buffer from the window system. Graphics drivers would be "mini" drivers that abstract the hardware just enough and no more.

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.

Re:Dear Keith...

[xybe]

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.

Re:Correct URL

[dougmc]

claiming that the network transparancy is a great feature. Dudes, hardly anyone uses that...

Dude, all kinds of people use that.

Just because YOU don't, that doesn't mean that OTHER PEOPLE don't.

The future of X

[Netmonger]

Well - one thing for sure I think after reading the article..

'Wexelblat shouldnt have anything to do with XFree86 or X anymore..

He very obviously doesnt believe in it anymore - if he ever really did.

This isnt the kind of attitude you want having ANY control over XFree86 or X.

Ex:

"client-server display systems are utterly irrelvent to the majority of real-world computer users.."

are you kidding me?!?

what a dick!

Perhaps Keith Packard wasnt trying to 'subvert' anything..

Perhaps he was trying to start a revolution - that looks like it might be needed.

Re:Correct URL

[Beowabbit]

Every time its suckiness comes up, someone always tries to defend it by claiming that the network transparancy is a great feature. Dudes, hardly anyone uses that...

That's utterly silly. I use X11's network transparency all the time, every day. Probably more than half the windows I type and click at are local, but not much more than half. And lots of the users I support use network transparency as well. Of course, the ones I actually hear from are disproportionately likely to be power-users, so maybe they're not a representative sample, but still, A lot of people use this feature a lot, and some people really depend on it.

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.

Re:Correct URL

[mobiGeek]

other desktops have functioning fast local desktops

As Alan Cox points out, I'd rather see someone prove that the wire protocol is the bottleneck in the desktop before we go off and rip it out (or start from scratch again).

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."

Re:Could this be it?

[Sentry21]

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.

I don't think the original poster is talking necessarily about moving the whole of X11 into kernel space. I think rather what s/he is talking about is moving the graphic sybsystem into kernel space and letting whatever else draw to that.

Example that I like to use: Darwin/OS X. The kernel contains the framebuffer driver, and provides a CoreGraphics API to applications. XFree86 has even been modified to use this interface on Darwin, with the benefit that it doesn't have to maintain its own drivers, it doesn't have to run as a privileged user, and, quite frankly, it won't blow shit up like it tends to on Linux.

I think this makes a lot of sense. Put the low-level stuff like video *drivers* into the kernel, then export a standard API that people can use. Let Berlin or XFree or an SVGALib wrapper or whatever use those calls on different virtual terminals, and switch between them. Have the kernel keep track of who's doing what, and ignore whoever isn't front and centre.

It would certainly remove the mess, but it wouldn't help the 'other' distros that weren't the ones that got the driver support (i.e. someone writes Radeon driver for Linux kernel, under GPL, someone else has to write one for *BSD).

--Dan

Re:Whoa there, cowboy

[dh003i]

Misconceptions. Flexibility and modularity do not imply performance costs. In fact, they imply the possibility to optimize performance. If something is inflexible, you get what you get, even if you don't need all of it's superflous features. That's an unnecessary performance hit. If something is modular, you're free to mix and match parts to choose the best performing ones.

I think alot of people have the misconception that having more layers between applications and the hardware slows things down. That is not the case. Those formal layers (as introduced by the X11 protocol) are just abstractions of what would have to be there anyway. They end up reducing bloat and memory consumption, as well as saving programmers time, so that every programmer who wants to make a 3D visualization program doesn't have to reinvent the wheel by recoding into his application how to access and manipulate the graphics-card/monitor.

Myth of X slowness

[crucini]

It's wrong to blame X for slowness. The real problem is the incredibly bloated and slow GUI apps and window managers, and possibly the modern GUI toolkits. Blackbox/Fluxbox/IceWM are very fast. Properly made X applications like xfig are very fast. The Mozilla family of apps has something pathologically wrong with it - nothing should be that slow. The Gnome/KDE stuff seems to me just barely acceptable on a fast machine, but clearly it's bloated and inefficient.

Quit blaming X. That's not where the speed problem is. As for difficult and complicated - your right. But mature technologies that properly handle a wide variety of cases tend to be that way.

Re:Myth of X slowness

[guzzloid]

It's wrong to blame X for slowness.

Rubbish. On my home machine, Win2K is fast, X is slow. I'll address your points individually: 1 .Slow anti-aliased fonts.

I have anti-aliased fonts in Windows. It ain't slow. If X provided a decent standardised AA fonts interface that was correctly integrated into it's core functionality, then this wouldn't be a problem. AA font rendering should not be that CPU or GPU intensive. It's been around for years -- it's not THAT hard a problem. If a PDA can do sub-pixel font rendering, then a Pentium III shouldn't have much of a problem.

2. Some video card drivers are slow.

Agreed, but most of the intensive rendering on my machine is using the same driver (nvidia). If pixmaps didn't have to be uploaded to the server, then perhaps there wouldn't be a problem. If uploading to remote servers was transparent, and handled by the windowing system itself, then it shouldn't be a problem.

4. Window managers do dumb things, like excessively redrawing apps when you switch virtual terminals.

Yes this does happen. But have you ever compared the number of redraws under X, compared to the number of redraws under Windows by running on a slow PC? Windows does much more redrawing (how many times does it really need to draw my desktop icons every time I press Win-M, for example?!) yet manages to run its display faster than X on most systems. Again, eye candy is fast on Windows, slow on X, on the same machine with the same drivers and the same video card.

5. Poorly implemented eye candy. If X had decent alpha-channel support, decent pixmap caching and hardware accelerated shading or speedy direct rendering, then we wouldn't need poorly-implemented eye candy hacks.

C'mon, I like X, and it's got a lot going for it; but I can't pretend it's not a slow resource hog. X can't even blit a window around the screen at full speed. And that isn't my video card slowing it down(my card can do this in it's sleep), or my drivers(because I can do it blazingly fast using GGI, DirectFB, or SDL): it's X itself.

In short, I think all of these concerns could (and should) be addressed by improving the underlying X architecture. The app layer needs to be brought closer to the hardware display layer.

And while we're on the subject, can't somebody come up with a decent accelerated video display architecture that works on the console and under X. Sure, it can be done: but do you use GGI, KGI, SDL, DGA, X11, DirectFB, plain framebuffer, svgalib, ... ?? Surely somebody sees the need for a unified linux display architecture? Would save a hell of a lot of heartache writing video drivers..., not to mention choosing APIs...!

Don't ask for much, do I? ;-)

DirectFB

[vandan]

I'd like to see DirectFB take off.
It looks pretty cool and is quite fast.
Don't know how practical it is or what issues are involved, but anyway if the X ship is sinking, I'm voting for DirectFB.
Of course the X boat is not sinking though.
All those who are sick of X can just stop using X, and see how you go ... ha! I don't know what most people are whinging about. X is incredibly fast on my computer. I run Enlightenment-0.16.5 and Enlightenment-0.17. And yeah I use network transparency a little. That's cool too. And my games run swift as lightning. Direct Rendering is sure working. Is X really that bad that people need to dump it and start again? I'm not convinced.

Re:STSF Looks Pretty Cool

[pamri]

While the politics that is happening in the XFree86 team is somewhat disgusting, I am extremely happy that STST is integrated into the XFree86 core.

Here's why:
STSF has OpenType Font Support, which is accepted as a standard for rendering indic and other complex asian texts(arabic, urdu, etc) by the developer community. By having OTF support at the X-server level instead of the toolkit level(like pango for gtk), almost all GUI's if internationalized would render in all Asian Languages. This is a great step forward for spreading linux into asian countries, but it's unfortunate this politics has to happen. BTW, some of the STSF development was done here in Sun's Bangalore centre.

Anyway, some related links:

More about Opentype fonts:
http://sourceforge.net/mailarchive/forum.php?thr ead_id=1856380&forum_id=12019

Building OTF
http://www.microsoft.com/typography/otfntdev/int ro.htm

Unicode FAQ about Indic:
http://www.unicode.org/faq/indic.html

Links about fonts, otf,xserver,etc:
http://indlinux.org/links.php

The indic_computing mailing list - expect to see a lot of heat generated because of this announcement:
http://sourceforge.net/mailarchive/forum.php?for um_id=2967

Re:All I can say is.....

[bonch]

I would like a low-level graphics subsystem that IS the toolkit/environment. I want things integrated, though customizable (i.e., skin it if you want, whatever).

I'm just tired of all the layers, libraries, conflicting interfaces, and general slowness because of all the cruft that is supported for those few power users who always chime in on /. articles like this about how incredibly friggin' useful network transparency is to them. Fine, stick with X, but the standard desktop users, who comprise a MUCH MUCH LARGER majority, need something different.

There was a reason for the shakeup in FreeBSD

[phkamp]

All I can say is that there were a lot of similar reasons why the FreeBSD project went from a self-elected core team to a core team elected by the committers.

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.

Re:Correct URL

[Bastian]

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.

Re:Obsolete?

[sigwinch]

I've said it before and I'll say it again... I've never once seen an X program that couldn't copy with a left click and drag, then subsequently paste with a middle click.

Here's how it usually goes:
1. Find URL and highlight it.
2. Find a handy browser. Realize it has a URL already. Highlight the URL and whack delete.
3. Damn.
4. Find the original app with the URL (hope the window wasn't closed!).
5. Fucking highlight it again.
6. Switch back to the fucking web browser.
7. Finally paste in the fucking URL.

The use of profanity in this algorithm is mandatory.

Let me get this straight:

[10Ghz]

David Wexelblat is in the Xfree BoD. He's also a core-developer. He flamed Keith Packard because of what he has done. What has Keith Packard done for Xfree recently? Among others:

a) Fontconfig
b) RENDER-extension
c) Xft
d) Work on transparency

What has Wexelblat done recently? According to his owns words:

a) He hasn't hacked Xfree in years
b) He uses Windows these days
c) If he will code something (unlikely), it will be for Windows
d) Only thing he does related to Xfree is to lurk in the core-devel mailing-list

And here we have Wexelblat flaming Packard! Hello!?! Of the two, it seems that Packard cares ALOT more about Xfree than Wexelblat does! He actually works on it and improves Xfree, while Wexelblat plays Myst on Windows! Looking at their recent activities, Wexelblat should just shut the hell up. He hasn't done a thing, who the hell is he criticizing Packard!?

Wexelblat should be kicked out of the BoD and Core and replaced by someone who wants to work on the project and improve it! It's no wonder Xfree has stagnated if there are core-members like Wexelblat who haven't contributed to the project in years! Ironically, it was he (if I remember correctly, could have been someone else as well) who kept reminding that "Xfree is a meritocracy". If it's a meritocracy, why are there useless deadbeats like Wexelblat in Core? Because of their past accomplishments? Maybe Wexelblat was an uber-hacker 10 years ago, but TODAY, he contributes nothing to the project.

Re:Maintaining XFree86

[bgarcia]

- 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.

No, X accepts input from your terminal (keyboard, mouse, etc.), and produces output to your terminal (video, and yes, audio *should* be included too). Why should audio be treated any differently? It's another common output mechanism for modern terminals. The fact that audio is not controlled just means that the current X server is really showing its age.

Re:Could this be it?

[nathanh]

Something like DRI (which is 3D-specific), would be extremely impractical for 2D.

You're talking out your arse. The DRI is a direct rendering infrastructure. It applies just as well to 2D as 3D. For example, from the DRI website

"The term direct rendering infrastructure does not only imply 3D graphics support. From the beginning, the DRI was designed with flexibility such that it may also be used in other areas such as video I/O. That's a potential future project." [http://dri.sourceforge.net/doc/DRIintro.html]

The DRI provides a direct rendering path. It's a mistake to think that the only library that could use that path is Mesa. Xlib (aka 2D) currently goes through a slow path; encode to socket to decode to DIX to XAA to DDX to hardware. A DRI/Xlib implementation could go straight from the client to the hardware. Practically you'd only use DRI/Xlib for bandwidth intensive requests. For everything else there's no real value in bypassing XAA.

Your misunderstanding actually highlights a deeper problem. So many people are calling for XFree86 to be scrapped in favour of a direct rendering windowing system. That windowing system already exists and it's called XFree86.