Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop) [LWN.net]

A group of developers from both the GNOME and KDE projects comment on the future of the X Window System. "We acknowledge the dedication of the XFree86 project in providing us a free and innovative implementation of the X11 industry standard, something we benefit from on a daily basis. Therefore, we want to share our joint point of view with the community."

to post comments

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 24, 2003 19:44 UTC (Mon) by proski (guest, #104) [Link] (8 responses)

From the document:

Within the development organization responsible for defining and crafting new features to be adopted as standards, innovation should happen in the open, with all affected parties able to participate early in the process.

Well said, but not enough. I think that GNOME and KDE developers should demand the right to be heard early at the design stage. They should demand to be represented in the XFree86 governing body. Both GNOME and KDE would win if XFree86 implements the new extensions in the form usable for major desktop envirments. If XFree86 team refuses, KDE and GNOME should help Keith Packard with his fork.

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 25, 2003 2:27 UTC (Tue) by dcarrera (guest, #9087) [Link] (7 responses)

If XFree86 team refuses, KDE and GNOME should help Keith Packard with his fork.

Forks are bad, and they should only be a last resource. GNOME and KDE should make every effort to encourage the correction of the thins that are wrong with XFree86 before a fork is considered. Sending a joint message was a very good idea.

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 25, 2003 8:52 UTC (Tue) by beejaybee (guest, #1581) [Link] (6 responses)

Indeed. The very idea of XFree86 forking is probably enough to cause waves of jollity at Redmond.

As I understand this "issue" (well, IMO it's a non-issue) the conflict is about either persisting with the client-server model, which _some_ people consider to be too complex for _single_ desktop systems, or breaking X's built-in network independence by going for a streamlined model. My personal view on this is that the X standard was way ahead of its time; we are just arriving at the point where multiple networked systems are the norm _even in a domestic environment_ - to me it seems wholly perverse that there should even be discussion about breaking the client-server model at this time.

I suppose the counter-argument is that games could be speeded up a bit by streamlining the path between application code & video bit-map. Fair enough, but do games really belong in a multitasking environment?

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 25, 2003 9:00 UTC (Tue) by libra (guest, #2515) [Link] (3 responses)

I would mostly agree with that argument.

I always feel sad when I have to use vnc (which for me is a heavy solution) when I want to administer remotely a Linux PC, just because I do this administration from a Windows computer and having a X on windows is too much complicated (heavy) in my opinion.
So the point for me is that X client/server model is in fact very good and make sense. The point should be to make it more user friendly now when it comes to remote connection.

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 25, 2003 10:29 UTC (Tue) by beejaybee (guest, #1581) [Link]

"I always feel sad when I have to use vnc (which for me is a heavy solution) when I want to administer remotely a Linux PC, just because I do this administration from a Windows computer and having a X on windows is too much complicated (heavy) in my opinion."

Whenever I find myself in this position, I tend to use putty to get a SSH terminal session. Plain administration of systems needn't depend on a GUI.

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 25, 2003 16:14 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

Why not cygwin? Or is that too heavy in your opinion?

I've got a linux box next to me, and use cygwin to access it from my W2K workstation all the time. Although admittedly I've got one of the latest/fastest computers in the office ... :-) (But I don't really care, and usually moan when they want to replace so this is unusual - I usually hang on to what I've got until it's the oldest/slowest, and I've even been know to downgrade ...)

Cheers,
Wol

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 25, 2003 16:57 UTC (Tue) by libra (guest, #2515) [Link]

Yes cygwin is too heavy.
Yes SSH is very good, and most of the server I use do not have an X that's true, but for the ones which have an X there is a good reason, and for these ones I have to use vnc because I don't know of a BARE X client like vnc to administer them remotely.
My point was mostly to say that it is sad not to make things easier for simple minded people like me. I could adopt X more if the tools on client side where simpler, and I think so because in my opinion the design of X with client and server is a good one. VNC is slower than X but I use it because it is more user friendly, it is bad publicity for X, but as this can be solved I thought I could give this opinion.
So to make things short : make an easy client for X like VNC and you will see that many people will :
- better understand the point of having a client and server side
- like X more
- use it more instead of VNC (which may just die in the process)

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 28, 2003 5:17 UTC (Fri) by Peter (guest, #1127) [Link]

As I understand this "issue" (well, IMO it's a non-issue) the conflict is about either persisting with the client-server model, which _some_ people consider to be too complex for _single_ desktop systems, or breaking X's built-in network independence by going for a streamlined model.

One should also note that this "issue" is only being heard from the peanut gallery. I haven't heard one word about this from any actual X developers, or for that matter from anyone who seems willing to "put up". Oh, except for those comments from Havoc and others, to the effect of "not gonna happen" or "have you even profiled it?"

The opposing viewpoint..

Posted Mar 28, 2003 10:21 UTC (Fri) by Duncan (guest, #6647) [Link]

> The very idea of XFree86 forking is probably
> enough to cause waves of jollity at Redmond.

I'm of that opinion as well, unfortunately.

> As I understand this "issue"[,] the conflict is about either persisting with the
> client-server model, which _some_ people consider to be too complex for
> _single_ desktop systems, or breaking X's built-in network independence by
> going for a streamlined model. My personal view on this is that the X standard
> was way ahead of its time; to me it seems wholly perverse that there should
> even be discussion about breaking the client-server model at this time.

I agreed with you originally, but then read something that at least caused me to
seriously consider the alternative viewpoint. From my reading, the reality isn't
quite as simple as you make out, or rather, most, including you, it would seem, fail
to realize just how much that complexity point you raise, means.

The issue has to do with XFree's Render.. as laid out against OpenGL, or
perhaps a new, later generation alternative (that point remains to be debated).
Both OpenGL and Render, according to the explanation I read, do essentially the
same thing -- they are both vector drawing APIs -- only while OpenGL is designed
for both 2 and 3D, Render only handle 2D. Since they both do about the same
thing (in 2D space anyway), there's a large degree of needless duplication of
functionality, though of course the implementation differs.

Thus, the initial question becomes one of "Well, going forward, doesn't it make
sense to emphasize OpenGL and eventually depreciate Render?" However,
that's only the initial question, because it in turn brings up a host of others.

Level two then becomes "If X is going to simply rely on calling its own OpenGL
implementation to do the drawing anyway, and we have 3D apps in particular
calling OpenGL on top of X, then X going back and calling its own OpenGL to do
the actual rendering, doesn't it make more sense to expose the OpenGL
implementation directly, eliminating a level of redundancy and (at least in theory)
increasing performance dramatically?"

Which then of course brings us back to the original debate, as we would then be
implementing and exposing OpenGL directly, with current client/server model X
being layered on top of it.

IOW, it all comes down to a question of why have two levels of redundant
functionality doing essentially the same thing, with all the extra code and
performance inefficiency that implies? Why not implement the more advanced
one, OpenGL, directly, then expose both it, and the current client/server X model,
including its current Render functionality, as a layer on top of the direct OpenGL
implementation.

That's the basis of the proposal. There are a few loose ends to wrap up,
however. One is simply politics. Doing it this way will (and obviously does) look
to some like deserting the original client/server model, when that isn't being
proposed at all, only a re-ordering of the functionality stack to eliminate
functionality duplicated at two levels, with subsequent exposure of the 3D aspects
of OpenGL directly at the lower level where it would replace 2D only X-Render.

Second, there's the repeated "Well, have you profiled it?" "Can you show us the
actually improved performance?" Of course, these are legitimate questions. The
problem is that the level of worked required to do this is non-trivial to say the
least, and it's still very early in the process -- we are still debating it. It's a major
rewrite, substituting one API for another as it does, and eliminating an entire level
of duplicated functionality. OF COURSE it hasn't been profiled yet -- the task is
going to take some serious time to complete. The question is do we start now,
keeping XF86 unified as it heads towards that goal, fork it, with all the undesirable
consequences, with one branch maintaining the current course, and the other
undertaking the rewrite, or put it off another several years, until the job is even
MORE difficult, X even MORE encrusted with hokey and slow work-arounds, and
even LESS satisfactory a solution as a modern 2D
AND 3D visual rendering environment.

Now, I don't want to pick sides, here. Obviously both forking and putting it off are
less than desirable solutions, but it appears one or the other will happen, due to
the politics of the situation. I've explained the techical side. I've read some pretty
serious allegations on the political side about possibly selling out XFree to a
proprietary solution. I haven't the foggiest if they are true, but even if they were
THOUGHT to be true, I can see how that might be grounds for kicking someone
off the team. OTOH, XFree isn't as open as many other open source projects in
the first place, it would seem, according to several sources I've read, which might
be part of the problem.

Finally, the legitimate question has been raised, "OK, if we are looking at a major
re-architecturing and rewriting anyway, isn't this a good time to examine whether
OpenGL is actually the best solution either, or whether a new solution might be
better?" Remember, a number of the OpenGL patents originating with SGI are
now in MS's hands, and serious questions have been raised as to the continuing
viability of the protocol's openness, or even existence, given MS' history in the
area of open standards, and the fact that altho it has *NOT* announced any legal
pressure on OpenGL per se, it HAS resigned from the commitee spearheading it,
and says it intends to focus exclusively on DirectX, on MS platforms. While it's
possible any potential intellectual property concerns could eventually be coded
around anyway, if necessary, if we are already considering doing a major re-write
of XFree, now the major player in the X consortium, now would be a VERY good
time to re-examine whether OpenGL is the absolute best possible solution in light
of those IP concerns in the first place.

[Meta: Wow! Long comment, but I believe it does address the issues as I
haven't seen them addressed in any response to this story so far. I can't say I'm
fully convinced of the rightness of the entire viewpoint I've presented here, but I
*DO* believe the issues ought to be examined from all sides, and it seemed only
one side had been presented, so far, and that not in any real depth.]