The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Why doesn't anybody like X?

Just wondering: why did the world jump onto Paul Graham's bandwagon of using HTTP to serve applications? There's another way to do it: X. Right now I'm at a windows machine running apps on a remote Linux box through Xming. The apps don't even know that I'm not there. What's wrong with it? Isn't it simpler than the current kludgy mess of HTML pages glued together with Javascripts and XML and God knows what else?
Sum Dum Guy
Thursday, June 14, 2007
 
 
X? Why doesn't anybody like Java applets or Flash or activeX? (Well, some people do.) The problem with all of the above, to varying degrees is:

1. They don't always work.
2. They fail mysteriously.
3. They are much more version-dependent that html/javascript.
4. They (Especially java applets) take a long time to kick on, and freeze up system resources.
5. They don't fit the browser/web paradigm.
6. They aren't a natural outgrowth of junior-grade web page design abilities.
mynameishere
Thursday, June 14, 2007
 
 
A protocol is widely used *because* it's widely used. What I mean is that, regardless of purely technical comparisons, once a protocol reaches a critcal mass of adoption, everyone tends to use it because it's widely used and therefore more likely to be supported by a wide range of platforms, applications, etc.  X never quite reached that threshold of adoption.
Mike Stockdale Send private email
Thursday, June 14, 2007
 
 
X is old 80's technology, slow, and takes far too much bandwidth.
Bill
Thursday, June 14, 2007
 
 
"What's wrong with it?"

It sucks horribly over high-latency connections (e.g. much of the internet). The richer the UI gets, the more true that is.

The other issue is security. X wasn't really designed with the idea of displaying untrusted programs in mind. Individual X clients are not sandboxed. That's fine for the usual X scenario where you're running programs you're familiar with off of a box whose administrator you trust, but we use untrusted web applications all the time. X would not be a particularly good choice for that.
clcr
Thursday, June 14, 2007
 
 
An X application runs on the remote machine, only the screen is displayed locally. In this respect it is safer than a web browser.
Of course a bug in your local X display could allow attacks but that is equally true of just about anything you run.

The latency and bandwidth are a problem if you are planning to do 3dCad over airport wireless but on a lan they aren't a problem. Much better than my local IT depts plan to replace outlook with logging onto the remote mail server using citrix to read mail locally. It 'makes for easier management' apparently they haven't heard of IMAP.
Martin Send private email
Thursday, June 14, 2007
 
 
The main security hole is that you give the remote server permission to draw on your screen - rather than a particular application or user.
Martin Send private email
Thursday, June 14, 2007
 
 
By "X", do you mean "X-Windows", aka X11R6?  Usually with "Motif Widgets" layered on top?

If so, the reason people don't like it is that in general, it is a speed slug.  It is also one of the first attempts at implementing a platform independent (relatively) GUI toolkit.

Thus it is the platform from which many lessons were learned.  It's very "chatty" with its server, lots and lots of messages fly in both directions just to read a button click.  It uses a very odd definition of "client" and "server" (your PC is actually running an X-Windows "Server" on it, while the application that is providing the GUI Widget updates is the "Client" program, which is running on the "Server" computer.)

Also, after all this time, and three or four attempts, the most popular GUI drawing program for X is Builder Xcessory, which costs $15,000 per seat to buy, and $5,000 per year "maintenance fees".  Per seat.

That may be why.
AllanL5
Thursday, June 14, 2007
 
 
I don't really know, but it occurs to me that a malicious X client (or, as Martin points out, any malicious program on the same host as the X client) might be able to do things like log keystrokes. It seems at least possible for an X client to react to keyboard/mouse events not directed at it, judging by the existence of things like xscreensaver.
clcr
Thursday, June 14, 2007
 
 
The client/server makes perfect sense in X.  The server provides a service = a window to draw on and the client uses it. Just because the client is running on the big computer downstairs and the server is on your laptop doesn't mean anything, my print 'server' is a tiny box hanging off the back of my printer.

The main disadvantage of using X instead of http for online apps is that it keeps a connection. Http doesn't which results in the horrible url-rewrites, cookies, hidden fields and other devious means to add some statefullness.
Martin Send private email
Thursday, June 14, 2007
 
 
There are good reasons to dislike X:

1) the X protocol is a gigantic, unwieldy monster that is difficult, if not impossible, to implement completely and correctly.

2) the X protocol doesn't include a security layer, so, by default, all traffic is passed as clear text.

3) X doesn't define a standard set of UI elements or behaviors. This was fine for the intended purpose of X -- an academic research system -- but is not what most users in the real world want.

4) X is something of a resource and bandwidth hog. There have been some attempts to remedy this (e.g. LBX, low-bandwidth X) but nothing really caught on. This is somewhat less of a concern today than it was a decade ago, but it still affects many applications.

5) X splits the client-server processing at the wrong point for modern systems. The only thing X does is rendering, where modern systems would like to move a fair amount of application logic closer to the human user.

6) Writing an X application is HARD. The X APIs are at least as difficult to use as Win32 or MacOS APIs. Most people can't handle this level of complexity.

By contrast:

1) HTTP/HTML is a fairly small protocol that is realtively easy to implement, at least in a useful subset.

2) HTTP includes a security layer (SSL/HTTPS).

3) HTTP defines a reasonable set of standard UI elements, although it leaves the actual behavior of those elements up to the implementation.

4) HTTP/HTML is much less of a resource hog than X: it restricts communication between client and server to page load and submits. HTTP/HTML, by contrast with X performed quite well on modem connections.

5) HTTP/HTML allows client-side processing to be easily layered on top of the basic protocol (e.g. Flash, Javascript, etc.) which lets the individual application decide how much processing to have on the server and the client.

6) Writing HTML applications is very easy. Any idiot can throw together a web page. It only takes a marginally functional moron to build an application using HTML forms.
Jeffrey Dutky Send private email
Thursday, June 14, 2007
 
 
1) So is the intel instruction set but only compiler (or X server) writers need to worry about it.

2) Thats the point of layers = need security tunnel over SSH

3) HTTP doesn't define how a page looks. Thats the separation between transport and GUI. If the gui had been defined in 1985 it might look a bit out of date now.
 
4) Not some much a bandwidth as a number of messages hog.

5) By not doing any processing on the local machine you have genuine write-once-run-anywhere and real sandboxing and security.

6) Nobody writes X API, you write wx/GTK/Motif etc.


1) Then why is almost no browser ACID compliant.

2) It shouldn't, security layers should be separate.

3) But has no way of expanding those elements.

4) But then you have to do lots of Ajax magic to make it feel like an app instead of a print preview.

5) This is an advantage?

6) Writing an html page is trivial as is mocking up a gui screen in paint. Making it work on multiple browsers and have any decent level of complexity support even the back button isn't

Something between X and Ajax would be an interesting approach to web apps. But would probably end up sending so much XML and SOAP back and forth it would make X look lightweight!
 

ps Jeff. Not trolling, it's just that I really really don't want to start the next bit of work ;-)
Martin Send private email
Thursday, June 14, 2007
 
 
Martin, in re-response (and also not wanting to start the next bit of work):

1) a useful browser only needs to support less than 5% of the HTML spec and has no need of ACID compliance, while a useful X server (like a useful implementation of the x86 instruction set) needs to implement something like 80% of the spec. This makes it MUCH more difficult to have many competent X server implementations, which seriously limits market penetration.

2) Separate security generally means NO security (which is EXACTLY what has happened with X11).

3) so the UI elements can't be expanded: what's your point?

4) true, but most applications don't need the full Ajax treatment. HTTP/HTML is a good fit for more than 50% of the applications out there. As for bandwidth vs. number of messages: lots of messages even at low bandwidth doesn't help matters any, latency is real killer.

5) given that HTTP/HTML has managed to push a lot of processing onto the client and X11 is stuck doing everything on the remote machine, yes it is an advantage. Even straight static HTML 1.0 does more purely local processing than the simplest X app, and there is no danger of local security violations.

6) But HTML pages are FUNCTIONAL, while the mockup in a paint program is nothing but a pretty picture. In order to get even a minimal application in ANY of the common X APIs (something that just shows a bit of text in a window) you need to write AT LEAST 20 lines of code (GTK or Qt), while a similar application (that does NOTHING) would only take three lines of HTML.

Sure, it would be nice to have something with which we could write remotable applications that would be as simple to use as HTML but which would allow as much control as Win32, Carbon, Cocoa or Xlib, but X11 isn't it, even with abstraction layers like GTK or Qt. Even WinForms, which is clearly meant to imitate HTML for application UI construction, isn't it.

I've been programming since the early eighties and we have been looking for this silver-bullet at least as long as I have been in the game. Lots of products have claimed to fit the bill, but only HTTP/HTML has really come close (and even it has serious limitations). I'd still kill for something better than HTML, but I'm not holding my breath.
Jeffrey Dutky Send private email
Friday, June 15, 2007
 
 
Yep me too, perhaps WPF will fit the bill?
I have written desktop apps where each dialog box was an IE control with HTML, certainly makes customsing easy!
 
But I still think it's cool that you can sit in front of an x term and have an aplication running on a different machine being managed by a window manager running on a third - useless but cool!
Martin Send private email
Friday, June 15, 2007
 
 
"Separate security generally means NO security (which is EXACTLY what has happened with X11)."

Um, what?  Standard modern practice is to tunnel X11 over SSH.
Iago
Friday, June 15, 2007
 
 
>Standard modern practice is to tunnel X11 over SSH.
But if adding security involves any extra work setting up the service it won't happen in reality.

That's the nice thing about HTTPS you don't notice it's there, otherwise you could just tunnel HTTP over ssh.
Martin Send private email
Friday, June 15, 2007
 
 
Iago wrote:

""Separate security generally means NO security (which is EXACTLY what has happened with X11)."

Um, what?  Standard modern practice is to tunnel X11 over SSH."

That's all well and fine, assuming that both ends of your X connections support SSH. Unfortunately, there are common situations where this isn't the case: if your company invested in X-Terminals then you won't have SSH on the server. If you run your X applications on a minority OS (such as OpenVMS) you can't get SSH on the client.

Leaving secure connections out of the X protocol was a mistake and should have been remedied as soon as escaped from the academy, but it wasn't. Maybe it was an excusable omission back in the mid-eighties, but only ten years later, in the first years of the internet revolution, it would have been a hanging offense.
Jeffrey Dutky Send private email
Friday, June 15, 2007
 
 
Great feedback, all. I am an embedded hacker (not as web hacker) so forgive me the following 30,000 foot view.

It looks to me like the world gave up on the X approach too easily. X may be bad, but I think the basic idea was good. Every GUI app is a stack of layers that looks something like this:
  Application
  API (class wrappers)
  Window manager
  Graphics primitive toolbox
  Display driver
  Screen

All you have to do is figure out where in this stack to stick your knife & abstract that part across a socket connection. Then you'd have a clean, sensible solution that doesn't care where the application is and where the screen is. And the app programmer doesn't need to know or care how it works. It shouldn't be that hard.

Why instead have we standardized on what looks like an inappropriate hypertext protocol glued together with kludgy technologies? It seems bizarre. It seems like a framework designed for running applications from the ground up would make a lot of headaches disappear.

Then again, I'm an embedded guy so I may be talking out my @$$ here, I don't really know much about either X or HTML. You be the judge.
Sum Dum Guy
Tuesday, June 19, 2007
 
 
Actually, that's one of the strengths of HTML -- it 'sticks the knife' in at the right place to reduce the 'chatty-ness' of applications between the display (browser) and the application server.

And by not requireing a 'maintained connection', it allows LOTS of browsers to connect and be served.
AllanL5
Tuesday, June 19, 2007
 
 
X is an interesting idea - in some ways well ahead of it's time.
Remember in those days you used a green screen terminal and the graphical displays were separate peripherals that your program wrote to as an output. So having multiple people on different computers writing to a display server felt more normal than today.
When you are running almost all programs on the local machine it doesn't make as much sense although the number of remote desktop tools suggests there is still a need.

Similairly http/html was intended as a text display with simple interactions - it has grown into a platform for running applications, a sort of smart version of a 3270 terminal.

There are 2 main problems to solve.
1, Do you keep a connection open, as in X, which costs a lot of resources on the server but makes session maanagement easier or do you have totally stateless like http which means extra work with cookies/url rewrites etc to maintain state.

2, How much work do you offlead to the client, basically none as in X or raw html or most of it with activeX/Java/ plugins.

I suspect some richer version of HTML (possible WPF) will win just because of the installed base - but people developing Ajax style apps can learn a lot from what X was intended to do.
Martin Send private email
Wednesday, June 20, 2007
 
 
Sum Dum Guy wrote:

"Every GUI app is a stack of layers that looks something like this:
  Application
  API (class wrappers)
  Window manager
  Graphics primitive toolbox
  Display driver
  Screen

All you have to do is figure out where in this stack to stick your knife & abstract that part across a socket connection."

There are two problems here: first, where you would optimally like to 'stick your knife' depends upon the application, so where X Windows decided to slice the stack is not, necessarily, where you want to slice it.

Second, even the contents and ordering of the stack is up for debate. What you have shown is how X Windows did it, which is part of what people don't like: the complete lack of a UI toolbox. Other systems have done the stack like this:

  Appliction
  UI Toolbox
  Graphics Primitives
  Window Management
  Input Events
  Display Driver
  Hardware

Many applications would like to offload the handling of the UI elements, all the way down to input validation and inter-element communications, to the remote, user-facing system, but you can't do this with X Windows. You can, however, do this with HTTP/HTML.

There was no good reason that X Windows didn't support these sorts of things, it was just an executive decision on the part of the MIT folks that they weren't interested in providing things like a user interface toolbox, secure connections or user-interface side execution. Lots of other folks, however, seem to think that those things are pretty important.

While we are at it we could complain that X Windows doesn't provide any way to generate audio feedback, or access user-side storage media, or deal with video data. These are the sorts of things a full commercial product would have had to deal with, but a research project could safely neglect.
Jeffrey Dutky Send private email
Wednesday, June 20, 2007
 
 
An early alternative that might have handled these issues better if it had taken off was NeWS, the "Network extensible Window System", see
http://programming.reddit.com/info/4z53/comments
Colin Macleod Send private email
Thursday, June 21, 2007
 
 
Thanks for the explanations, guys. That makes a great deal of sense. So designing a really good remote GUI platform is not as simple as it seems at 30,000 feet. (Of course EVERYTHING seems simple at 30,000 feet, eh?) I am now a wiser man.
Sum Dum Guy
Thursday, June 21, 2007
 
 
There are a couple of other historical reasons for the way X was done.
Often the X-server (the box on your desk) was a dumb terminal - it had the X protocol in a graphics chip but had no storeage or OS itself. Like todays thin clients these were great because you had no admin and they were silent = no fans or drives! 

In the unix world most interprocess communication is done with network calls, the system knows you are connecting locally and internally skips a lot of the layers - so network calls to yourself are very cheap. This means that extending a local app to work over the network is simple. It is also common in unix to network enable everything, especially at Sun motto = "the network is the computer". Although as Jeff said that means you don't think about real world things like security because you don't think of the network as something "out there" it's part of your machine.
Martin Send private email
Thursday, June 21, 2007
 
 
If the gui had been defined in 1985 it might look a bit out of date now.

well, Windows 1.0 is from 1985 and its behaviour has been consistent not look.
woong Send private email
Sunday, June 24, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz