LWN: Comments on "The X Window System, past and future"

it's got to go (but we could keep toolkit compatibility for the transition, breaking very little...)

meep — Tue, 18 Nov 2003 03:38:34 +0000

I wouldn't say Fresco is the main one.

Possibly the most promising
http://picogui.org

Aimed at embedded only?
http://www.microwindows.org

Y: A Successor to the X Window System - not sure about that, but the pdf certainly analyses the problem and points out a lot more of what is wrong with X than above artcile.
http://www.doc.ic.ac.uk/~mbt99/Y/

another
http://www.tutok.sk/fastgl/

what Linus had to say. (although old still valid)
http://www.ggi-project.org/mailinglist/may99/320.html

more
http://lists.canonical.org/pipermail/kragen-discuss/2000-March/000552.html

I've experienced X for myself on older systems and I've got to say it's not a fun experience. Win is much faster. I think this is a very sad thing - the whole underlying OS is about efficiency and freedom, not being locked into paying for fast(er) hardware/software to keep up.
To put a slow GUI on top of this (and the GUI *is* the OS for many people; after all, it's the final layer between them and computer) is like throwing that all away.

Linux is proven in the server market and we're now seeing its huge potential in the embedded world. The only way to maintain sanity here would be a GUI flexible enough to suite either (just like Linux itself can scale to such extremes). We're currently seeing projects like www.directfb.org aimed for individual needs, and it's really fragmenting things, making stuff less flexible, less portable.. which is really what our OS is all about.
A standard and scalable GUI could also help out the desktop world which is moving very slowly due to reasons outlined in the "Y window system" PDF.

What's bad about tiling window managers?

kaig — Thu, 03 Apr 2003 14:36:07 +0000

I know two of them, Ion and larswm, and I've used Ion for an extended period of time. I liked it. (What kept me away from larswm was that it didn't allow me to customize the key bindings to my liking. Hardly something that means that tiling is fundamentally bad.) I agree that Ion still needs some way to deal with applications that don't play ball with the tiling, but once that's added, what's wrong with it?

The X Window System, past and future

obi — Thu, 03 Apr 2003 14:27:13 +0000

> > user interface policy will be wired into the window system itself;

> And I won't like it, and then I'm screwed. :-(

Not at all!

One of the major advantages of Fresco is to centralize policy at the server side, but that doesn't mean you're stuck with one policy. You can switch the look and feel and behaviour at runtime, by plugging in different kits (widgetkit for instance). And _all_ your apps behave the same - consistency.

Fresco is really trying to do everything the right way, to a fault. It's a project that deserves to be checked out, and understood. (one of the few examples where open source truly is innovating instead of copying.)

The X Window System, past and future

obi — Thu, 03 Apr 2003 14:21:17 +0000

I agree with you.

Trouble is, the Xfree86 developers feel only Xfree86 "deserves" their drivers. There have been numerous attempts to leverage the XAA drivers without X, but it seems it's usually easier to rewrite them. Same thing with DRI, it's theoretically possible to use DRI without X (see fbdri.sf.net for instance), but it's a very low priority for the DRI developers.

I'd really like to see a system where the hardware layer is properly abstracted from the window and network layer. So that we'd be able to use the same drivers for graphic 2D/3D console programs, and X at the same time. That would allow other windowing environments to compete on a level playing field, and allow a lot of projects to bypass X completely when it's not needed (games come to mind, or something like blender).

KGI/GGI/XGGI tried to do just that, but when KGI didn't manage to get into the kernel, they threw the baby out with the bathwater. Instead of improving GGI to make the interfaces more acceptable, alot of the interest in it waned, to the point it was comatose for quite a while. Recently, there's been activity (kgi-wip.sf.net) again, and I do hope that they'll make it eventually. (BTW: they also have a very nice input layer, GII)

I think the beef with X isn't that it's so terribly bad, but that it's the only choice, and holds everyone hostage because it controls the video drivers (not by design, I'm sure - they just have no interest in anything else)

If nothing else, I hope the fork, or the reorganisation or whatever, will bring more modularization in the code base. So other projects can atleast share drivers with it, and improve the drivers for all.

The X Window System, past and future

stock — Mon, 31 Mar 2003 13:49:16 +0000

Hehehe, the funny part is, that the real motivation for me to
try Linux was that X11R5 came with it (SLS 1.03 distribution by Peter
McDonald) . In those days (early 1993) getting an X11 environment for your
UNIX(tm) was either impossible or costing you another mortgage on the house.

Linux with SLS installed easily on your 386 and if you had a $ 35,- Tjenglabs
ET4000 VGA card you were running your favorate OpenLook window
environment out of the box after adjusting a single Modeline in your
XFConfig file.

Robert

The X Window System, past and future

ptr — Sat, 29 Mar 2003 17:36:50 +0000

I think that slightly misses the point. The criticism of efficiency applies to the protocol which
serializes display updates into a data stream. This protocol is used no matter whether a
remote network connection or a local unix socket is used. This protocol is claimed to be
inefficient, because the supported drawing primitives are too low-level (as mentioned earlier in
this thread).

Another fundamental question is, if there are better approaches for inter process
communication than serialization which scale up better in the case that the applications run on
the same system. Of course, also security issues are of concern...

The X Window System, past and future

iabervon — Fri, 28 Mar 2003 01:16:41 +0000

The X protocol used to be fast, because those drawing primitives were what people used to make the interfaces of the day. Now it's slow, because many modern interfaces need more complicated operations. But the operations they need still don't have to involve policy or determine how things look. X ought to have splines, (more) anti-aliasing, blending of lines, etc; essentially, the set of primitives in SVG. Then applications would be able to use the primitives that their interfaces are composed of and wouldn't have to resort to the messy use of the inadaquate primitives they currently use.

The X Window System, past and future

iabervon — Fri, 28 Mar 2003 01:10:37 +0000

Of course there are performance penalties resulting from network transparency. But you don't see them if you are doing productive things with a computer (i.e. not gaming).

Or if you connect to :0.0, which uses a UNIX socket, not the network. X is sufficiently clever to *not* be network transparent if there happens not to be a network.

The X Window System, past and future

Baylink — Fri, 28 Mar 2003 00:49:12 +0000

> user interface policy will be wired into the window system itself;

And I won't like it, and then I'm screwed. :-(

As far as performance and responsiveness, I find that X is actually *more* responsive on my Linux boxen than Windows is on it's, mostly because few things which ought not to block others, do.

The X Window System, past and future

josh_stern — Fri, 28 Mar 2003 00:23:00 +0000

Agree with slamb as far as it goes, but further analysis argues that the *real* problem with X is the social/organizational one of getting new extensions to become standard. The universal design of the protocol communicating primitives works great for its intended application - non graphics intensive applications in a LAN environment - in a programmer transparent way. But as you imply, extensions are needed for graphic intensive and internet use. In fact, a general purpose, suitable, substitute already exists: display lists with GLX. But usage is only possible for particular combinations of client libraries and X servers, which are still not common enough (and bug free enough) to make it a viable, general purpose, application programming strategy. So here is an example where we can see how a larger programming team (more horses for implementation) and a more aggressive approach to promoting change and new standards could help! So the current debate is key, *because* the issues are not fundamentally ones of technical design.

The X Window System, past and future

slamb — Thu, 27 Mar 2003 22:20:14 +0000

Of course there are performance penalties resulting from network transparency.

I think you're confusing two arguments here: (1) X is slow because it supports network transparency, which is unnecessary and (2) X's network protocol is inefficient. I agree with #2 but not #1.

Its network protocol is slow because it talks at such a low level: draw these shapes here, the mouse moved, etc. Basic operations like moving the mouse and adjusting a scrollbar seem unusably slow over the Internet to me, and I have broadband. If the server did buttons, scroll bars, and other primitive widgets, this would not be a problem. Fresco does this. In other words, it moves much of the toolkit to the server side. Events only need to be sent from the server to the client if your code is interested in them, and it's not that often people register a mouse movement listener.

That approach isn't perfect either, but you have to admit that it's dramatically more efficient. Like the difference between applications feeling unusable over the Internet to me and feeling responsive. Less time waiting for a response = more goodness.

Disagree about no alternatives

jlnance — Thu, 27 Mar 2003 15:36:45 +0000

The article states that X has no competitors. I do not think that statement does justice to the situation. X11 is basically a communications protocol. You could make analogies to TCP/IP or HTTP. X11 may be the protocol that all Unix workstations use, but that does not mean they are all running the same software. There are different X Servers for Linux, and in that sense you do have a choice.

X Windows alternatives on Unix

subhasroy — Thu, 27 Mar 2003 13:15:50 +0000

I like X. Wrote 1000's lines of Xlib code a decade ago. As user,
I am using it for 13 years. There are other possibilities
on Unix however - Mac OS X does not use X Windows.
I have no experience with it but read that it uses
some sort of "Display PDF" instead. I don't know if it
supports network transparency like X Windows.

There are some things that are hard or cumbersome with X.
Font configuration is one.

Windows does not have application level network transparency
like X. But Windows's remote desktop connection does work
nicely.

The client-server stuff

eru — Thu, 27 Mar 2003 11:43:29 +0000

I always find it sad when many people accuse the client-server
paradigm of being the resource hog (not this article, but it alludes
to the belief), and propose cutting it out as a way to supposedly improve X.
In the distant past, I have used X11 on Sun systems that would be considered pocket
calculators (regarding CPU power) today, and also Sun's proprietary
"monolithic" window system on the same boxes. No difference in responsiveness.

Removing client-server features would eliminate many uses of X11.
I can tell that in the large company I work in, there would be almost
NO usage of X11 apps, if it could not be used remotely. You guessed it:
most desktops are Windows-based, and the commonest way to use graphical
Unix or Linux applications is logging in via X11 emulator running on
Windows. Also note that the requirement for remote GUI use in enterprises is
so strong that it actually forced Microsoft to re-invent the feature in
Windows terminal services.

The X Window System, past and future

dmantione — Thu, 27 Mar 2003 11:42:11 +0000

X is an excellent piece of engineering. For a desktop environment it does all
that's needed, efficient, and network transparent. Nothing beats it and I have
seen nothing better.

But there are a few situations where X is not the right choice. One of these are
for example embedded situations, where you really want Window systems in
as few K as possible.

Another problem is that people use X for something it's not designed for:
games. People, games should *not* run under X. Why? Because they need a
framebuffer and other *low level* access to graphics hardware. X is a *high
level* network transparent windowing system.

Why are games written for X? Well, the only reason is that for every video
card, there is an X driver. There is no other reason.

On what interface should games run then? A low level one and the most
suitable one is: FBDEV! But as of yet that's not possible; there's no 3D for
example. I would be very nice to see more projects to give the Fbdev interface
the drivers and tools it needs. Instead of bashing on X, people would better
spend there time on this.

Trying to adapt X to games is nonsense. Conflicting interrests. It doesn't work.
But for a window system, it's the best there is.

The X Window System, past and future

rwmj — Thu, 27 Mar 2003 10:48:09 +0000

I feel like I'm in a minority here, but I like X. It works really well for me. On the rare occasions I use Windows I've never noticed that platform to be any faster. I love the network transparency (I use it daily for development, you'll take it from my cold lifeless hands). I can play games really fast. Since I ditched my old Voodoo 2 and got a real graphics card, 3D stuff just works & fast. I can run OpenOffice on my big server upstairs and view it on my Sun box downstairs. In the many many years I've been using it, I've only once found a graphics card which it didn't support - and all I had to do then was upgrade the server RPM. What's the problem?

Rich.

The X Window System, past and future

paulsheer — Thu, 27 Mar 2003 09:51:11 +0000

Each and every one of the criticisms about X is either completely unfounded, or applies to any other piece of software anyway. Myself I have been programming under XLib for many years.

In the first place, X is not bloated. It is in fact the minimal piece of software for what it needs to do. Considering the range of types of raster devices out there, X conanicalizes their differences perfectly. Its protocol needs to be exactly as it is to facility interclient communication.

One cannot think of a better way of coping with the problem of creating a hardware independent network transparent Windowing system. Try and see.

Let us compare X to MFC (microsoft foundation classes). MFC is the most chaotic mess a developer could ever wake up screaaming to in the middle of the night.

The capacity to transparently use other machines on the network has never been so successfully achieved as by The X Window System. It is an essential cornerstone of Unix computing in the world today. Most people who critisize X do so from a single home machine that is used mostly to play games.

Such people want to strip the computing world of network transparency (to break their network card in half) just to get a few more FPS out of their first person shooter.

Of course there are performance penalties resulting from network transparency. But you don't see them if you are doing productive things with a computer (i.e. not gaming).

X is also extremely light on resources - consider that X runs on a 2 floppy Linux distribution. Really no one could ever critisize X for that.