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.

What did I JUSTIFIABLY say in the last discussion?

[Anonymous Coward]

Replacment for XFree:

framebuffer + fbdri/dri + picogui + *choice_wm_or_environment

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

Could this be it?

[The Bungi]

The beginning of the end for X? Vindication is at hand?

X is the single biggest obstacle to Linux becoming a usable desktop OS. It's absolutely fantastic at doing what it was designed to do, but it has no place in a desktop environment.

Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.

The recent Slashdot story about kernel tweaking (kernel tweaking!) to make X more responsive underscores this perfectly. First you start tweaking the kernel... and then you realize that you have to move the graphics subsystem closer to ring 0 to make the thing work at sufficient speed. The very thing that Windows has been criticized for since NT 3.51 came out.

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. That's why DirectX is the darling of game developers.

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.

Re:Could this be it?

[mav[LAG]]

X is the single biggest obstacle to Linux becoming a usable desktop OS. It's absolutely fantastic at doing what it was designed to do, but it has no place in a desktop environment.

X does just fine in a desktop environment, despite being designed the way it is. It runs on a wide variety of hardware from Onyxs right down to my iPAQ, provides more than enough flexibility for window manager authors and works transparently over a network.

Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.

Tsk Tsk :) Anecdotal evidence! The very thing that Linux users are always criticised for. What's your hardware? Video card? Kernel version? Distribution? Did you compile X for yourself? You mention "my Linux box" - so is it another box entirely? My anecdotal evidence: X has always outperformed Windows 2000 on the same hardware for me (easy to test since I dual-boot) - an entirely unfair comparison since I've always compiled it from source with lots of optimisations turned on.

The recent Slashdot story about kernel tweaking (kernel tweaking!) to make X more responsive underscores this perfectly. First you start tweaking the kernel... and then you realize that you have to move the graphics subsystem closer to ring 0 to make the thing work at sufficient speed. The very thing that Windows has been criticized for since NT 3.51 came out.

What's so surprising about kernel tweaking? Any large software layer that uses kernel functions is going to be helped by making those functions run faster. Linux treads a middle road by design here - it's impractical and stupid to move a graphics subsystem into the kernel - but graphics apps could use more speed so you use things like the DRI and kernel tweaks.

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. That's why DirectX is the darling of game developers.

Not quite sure what you mean here. X and GL are two different architectures with two vastly different requirements that have evolved independently and only fairly recently have worked nicely together. Not everyone who needs X needs 3d graphics - and the 2D accelerated functions of X are pretty close to the metal anyway. When the performance of GL became an issue that needed to be addressed, a solution was found (the DRI) that didn't need to move graphics into the kernel but still provided an acceptable enough solution for GL users. This is the real world: X is there, it works and it's not going away. GL is there and also immensely popular. Could both be better designed from the ground up to work better and work better together? Of course. But that's entirely impractical. And your comparison with DirectX conveniently forgets that DirectX was a crappy and unusable API for a long time - famously spurned by Carmack in his 1996 .plan as being a "waste of time." It's only recently that it's evolved and improved to what it is now.

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

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

[critter_hunter]

It looks somewhat interesting - I personally think X11 sucks ass, so any alternative looks interesting - but something about the project really bothers me. I can't find their interface guidelines anywhere.

Now see, the thing that annoys me the most with X11 is the disparate behaviors of common widgets and dialogs. Every toolkit and software author seems to have it's personal take on the matter, and it can become pretty confusing at times. And when I read that Fresco intends to be highly configurable, I hope as hell that they're not making the same damn mistake, and are leaving that kind of power solely in the hands of the user.

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

[Anonymous Coward]

FreeBSD is a peripheral enough project that there isn't the kind of politics that leads to people stacking meetings and staging votes.

XFree86 is far bigger. It would be very hard for there not to be major politics, vote stacking, etc., if the core was elected. It's 'the one and only', not one of several freenixes, as is the case with FreeBSD.

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:XFree Obsolete?

[be-fan]

and it has ugly ass fonts
>>>>>>>>>
Check out this and this. The letter shapes, even on the complex Kaufmann font, are incredible. They'll probably look color fringed on a CRT, because I took these with subpixel AA enabled.

hardware through TCP ports
>>>>>>>>>>
Um, XFree86 uses UNIX domain sockets (very fast on Linux) for local connections, not TCP sockets!

Re:XFree Obsolete?

[Anonymous Coward]

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.

Yeah, it's soooo easy to do it too.

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.

You're biased toward X. It is old and needs to be replaced. You're like the last gasps of a dying regime.

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:X design decisions

[LordMyren]

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

Lets see, oh, about 0:100%. Not a hard choice here, considering X is used as a complete multi-user environment for most of my projects. Most Xservers are Xwin32 or other windows servers. They couldnt run something locally if they tried.

Thin clients are awsome. X was right, its the rest of the worlds fault for being too braindead to take advantage of it.

Furthermore, most of the complexity of X is fairly well masked by modern distros. Although xf86config used to be one of the major linux headache/stumbling blocks/barrier to entries, with redhat and mandrake I seem to here a lot less bitching.

I believe the issue is less x is too complicated and more that X was never geared towards n00bs up until recently (ie: redhat).

Myren

Re:Correct URL

[Anonymous Coward]

My Lord, X really needs to die.

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... and X is designed from the ground up for it. In other words, X is designed for the least used case -- other desktops have functioning fast local desktops, and add a few hacks in to allow remoting (in many cases, Windows for example, the hacks are faster and lower bandwidth than X's suck crap ancient attempt). The results is a revolting server/client idea that makes improvement difficult, programming complicated and any desktops running on top of X slow and bloaty.

Please, please, pretty please... put X out of its misery now.

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.

Re:let me add to that...

[g4dget]

X needs to be replaced by a direct-rendered model, on which a backwards-compatible X server can be reasonably trivially implemented."

But that statement doesn't even make any sense. X11 is a protocol: it's nothing more than a well-defined sequence of requests and responses between clients and servers. What does a "direct-rendered" implementation of that mean?

NT has pretty much the same architecture: the display server lives in the kernel and applications live in user space. Requests and responses go through queues between the two. The only difference is that the NT protocol isn't documented and that it is rather ad-hoc.

If you want to implement an X11 server, parts of which live in the same address space as the client, great, go right ahead. It's a SE nightmare and no other window system does that anymore, but, hey, maybe you can make it work. You don't need to change the protocol for that.

And I tend to agree with him. Check out directfb to see a good example of how multiple applications can have "direct" access to the video card (not really "direct frame buffer").

Well, gee, and that is just what XFree86 gives you. In fact, it is often handled completely transparently (read up on how OpenGL is implemented). But XFree86 also happens to give you the option of using non-local transport mechanisms, without imposing an additional cost for local communications.

I envision a lowlevel graphics project that is only interested in bringing high performant graphics to linux.

It's perfectly reasonable to divide an X11 implementation into a low-level graphics layer and a high-level windowing layer. It is also perfectly reasonable to give local applications controlled, direct access to the hardware. And it is perfectly reasonable to let applications communicate via shared memory. And, wouldn't you know it, that's just what XFree86 does. And even more nicely, it will transparently switch between local and remote implementations.

But it is not reasonable to expose the low-level graphics layer to applications through a separate API, because then you lose network transparency. Putting up multiple DirectFB windows on a screen and remoting some of them through the X11 protocol does not give you network transparent windowing. What makes X11 network transparent is that it can manage both local and remote windows transparently through a unified API. That costs you nothing in performance, and it gives you a lot in terms of functionality.

I have often thought that XFree86 project should be broken up into more reasonably sized pieces. I once tried to play around with the source, but it was just too dang large for me to get into on my spare time.

Sure, the XFree86 server code is big and complex. But, so what? It conforms to well-defined standards and APIs and it's very efficient. It won't be any more efficient or featureful if you re-implement it. The reason to re-implement it would be if maintenance of it becomes too much of a problem. That may or may not be the case, but it's something for the maintainers to worry about, and addressing that problem doesn't require changing the protocol.

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:Video-Card-Centric clearing houses

[Devil's Avocado]

"""
It's no different to the Linux kernel. If your driver gets accepted into Linus's tree you don't automatically get BK write access to the tree. You have to submit patches through Linus (or another Core Member).
"""

Many people don't think that the kernel's development model is much better than XFree86's. The kernel has the advantage of a more open process and (in my limited experience) being more vigorously developed, but there's no shortage of dropped patches. People just seem to care more about the kernel and work harder to make sure Linus eventually merges their work.

Even the kernel is moving more and more towards using modules, and there's no reason all modules have to be distributed with the kernel. I sure wish I didn't have to download all of those SCSI RAID drivers every time I want to upgrade the kernel on my laptop.

-DA

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.

Re:Wexelblat is right, network transparency pointl

[Hard_Code]

At which point it would no longer be X, in which case you might as well just start a new project (or fork).

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:Phooey on network transparency

[Anonymous Coward]

X is not a wire protocol that talks to your display. Other than that, all your examples apply equally well to any standardized window system.

1. pluggable implementations? huh? what is that? On windows alone there are a dozen different window systems (ie, shells, ie. explorer replacements). They're interchangable and work seamlessly.

2. security? How does that have anything to do specifically with X, or is an attribute only X possesses?

3. I don't think there is much demand for this remote app capability. It's not particularly tough to do on Windows, termserv and citrix do a good enough job obviously. It's a nice to have feature, especially once you get used to it, but I think with enough demand it would appear in other window systems.

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.

Re:Your logic is flawed.

[Christianfreak]

While I agree with most of your post the idea that we shouldn't care about people who don't use KDE or GNOME because they are a small minority is a very dangerous attitude to hold. Linux and XFree for that matter have always been about configurability, even if there aren't that many people who choose to use something else these days they should still have that choice. I mean by that logic we should all be running Windows because that's what the majority runs, right?

I guess my opinion comes from the fact that I'm very happy with BlackBox, run it at home because I have an old machine and KDE or GNOME is just too much bloat for it. But I like it so much that I run it at work even though I have a decent machine. I do want a unified desktop but I will really rejoice the day that my apps look and act the same no matter what window manager I use!

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

[spectral]

Ok, then try and watch a video in windows without overlays, and see how slow the windows renderer is. Oh, wait a second, it performs like ass too? Damn, I never would have thought that could possibly happen.. using x11 as a method is flawed, they just can't handle thigns like that. xv/overlays/etc. are the only way to get decent performance.

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? ;-)

Re:Myth of X slowness

[J. J. Ramsey]

"I have anti-aliased fonts in Windows. It ain't slow"

Um, Windows does *not* antialias fonts in the normal range of point size because it tends to just look fuzzy. Unless you regularly look at 7-point or 24-point fonts in Windows, you probably have rarely seen font antialiasing at work. What Windows *does* do is use font hinting to make the fonts readable at different point sizes. However, that is not the same as antialiasing.

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:Do you recall Armageddon ?

[po8]

Code like GNOME-XML, pkgconfig, fontconfig, xcursor and xft2 were mainly written by people who're heavily involved into GNOME development.

Heh. Fontconfig, XCursor, and Xft2 were written almost entirely by Keith Packard. My personal experience is that he is quite agnostic on the Gnome/KDE question. Further, there is nothing about the design of any of these three subsystems that favors any particular GUI environment.

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.

Two display methods needed

[Trolling4Dollars]

Before I start this, I have to make sure that people reading it actually "get" what XFree86 is. A lot of people who complain about X (in the generic sense) think that it IS the GUI. They see that X shaped cursor and the 50% gray background and think "ewwww!" But what they don't understand is that the "GUI", as they perceive it, is really an environment like KDE or GNOME. Assuming we are talking KDE... you need X for KDE to run and vice-versa. They are interdependent. I can't tell you how many times I've heard people say "I like KDE better than X Windows". With that said:

After reading some of the comments on the OS News board, it seems to me that there are two needs arising out of the discussions:

-Continuing development of XFree86 and it's robust feature set (many of which are sadly lacking in Windows unfortunately)

-A completely new non-networkable direct rendered system (more like the Windows approach)

First of all, to make my case, I will tell you to think of it in terms of a standard console vs. a framebuffer console. They both have their place for two different types of users. In the same way, a system like XFree86 and some new direct rendered display system will have acceptance with certain kinds of users.

I, personally, love XFree86 and all it has to offer. It performs very well for me on a local workstation as well as over my home network and at my place of employ. Displays are easily exported on a per application or per session basis as needed. And with the LBX proxy, I can use it when VPNed into my workplace.

It's VERY flexible: I typically run 3-4 X servers on my workstation and laptop so that I can dedicate full screens for certain things at different resolutions or run under different users simultaneously on each display. (To those in the know: How's that for fast user switching? XP cough cough... :) Ctl-Alt-F8 and you are one user, Ctrl-Alt-F9 and you are another, etc...)

For example, if I am playing a game (Sierra's Lighthouse for instance) under Wine, I like to do it full screen, with no desktop environment at all. Just the game. What's even nicer is that I can actually make the display large enough the Lighthouse isn't a small window with black space around it, it almost becomes full screen. Same thing with Riven. All this while I still have IRC downloading the latest episode of Enterprise in another session as another user. All I need to do to check on my download progress is the Virtual Console key combo.

Now... I will say that if a project starts up to provide a direct rendered system. This could actually be a good thing. It would probably meet the needs of the generic home user fairly well, and remote desktop services could be provided by something like VNC or an RDP clone. I do admit that Joe Average is probably going to have little use now and in the future for X type capabilities. So, this new system should be packed with other "consumer" features. Specifically, the 3D support for games, DVD and MPEG acceleration where applicable and TV in/out support for cards that have such features. A project like this would do a lot to make Linux more palatable to the average consumer. All a distro would have to do then is break down their distros into categories (RedHat for example):

-RedHat "Lite" - A distro for the average consumer that is rypically pre-installed on new systems. No X, no devel tools, no servers, just a very basic OS that allows them to safely get on the Internet, run some productivity apps and play some games.

-RedHat "WS" - As it exists currently. With X (just the direct rendering system that people are alluding to), devel tools, basic servers and some of the enterprise features that power users crave.

-RedHat "Collection" - Capable of installing every distro from one set of disks. You just choose which distro combo you want.

So... don't bash X because you don't understand it. It's a great system with a great feature set. It would be nice to see 3D acceleration networkable or even clusterable though...

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

[Anonymous Coward]

Well, you obviously don't. Otherwise you'd tell us all
a) What a wire protocol IS
b) Why this is not what the X protocol is
c) What the X protocol actually is

but you didn't. Well done. You've added to the noise without adding to the signal.

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.

You misunderstand point #1

[Anonymous Coward]

Explorer/shell replacements are in no way analogous to an X server. You might call them "window managers" if you like, but that's as far as it can go.

I find it funny...

[WindBourne]

the number of ppl who wish to kill X while MS is struggling to get remote windows and multi user right. If X was such a disaster, then some group would spring up with lots of backing and take over (think KDE/GNOME). This forking is normal in the course of things. I suspect that Keith's work will shake up X and for a time, there will be 2 projects, but they will either merge back or work together.

Re:Whoa there, cowboy

[dh003i]

You have the misconception that just because those layers aren't explicitly stated in other cases that they aren't there. All those layers do is provide a resource for programs to call upon, so that programs don't have to have information coded into them about how to access and manipulate devices, drawing the UI to the screen. Having separate layers allows separate projects to work on optimizing those gritty details, and allows many programmers to ignore them, which is good. If every programmer had to program into his program how to access and manipulate devices, programs would be very large, and take up much more RAM. Hard-drive space would also be wasted. And every programmer would have to reinvent the wheel for no reason.

Think of these separate modular layers as the computational equivalent of the assembly line, which created interchangeable parts, and modularity, and also allowed for the faster creation of products.

Re:Fast GUI vs Network Transparency?

[Fembot]

Why does everyone automaticaly assume that moving stuff into the kernel will result in speed increases??

Re:Phooey on network transparency

[Malc]

Personally I hate the X model. It's just not robust and reliable enough for me. Any connection interruptions cause all the apps to die, losing any state and any unsaved work. I much prefer the remote desktop sharing approach. If I get disconnected, I can re-connect and carry on from where I left off. Even better, I can reconnect to an existing session from a different location.

You pointed out that this approach can be a performance problem. That's true if bitmaps are being sent. VNC is reasonable with a low latency connection (I use it daily on a 140ms connection from the east coast of N. America to the west coast). PCAnywhere works better, but has other problems, and RDP is the best, although apparently restricted to Windows only.

The performance of Windows Terminal Services (and Win XP's remote desktop sharing) is fantastic, and very impressive. This, IMHO, is the alternative to X11 and it's network issues. Personally, I would like to see a hybrid of both: the ability to use high-performance remote desktop sharing over unreliable networks (e.g. the internet), coupled with the ability to seamlessly display UIs from apps running from different machines on the remote LAN (reliable network). This latter feature is more of a "nice to have" feature than a requirement though.