frustrations with X

Kragen Sitaker kragen@pobox.com
Sun, 17 Feb 2002 22:10:22 -0500 (EST)


So in X11R6.3, the X consortium added this really nifty thing called
"LBX" to X.  "LBX" is supposed to make X fast enough to be usable over
serial connections, such as modem lines.  It stands for "low bandwidth
X", and it lets you run unmodified X applications in a low-bandwidth
mode by means of a compressing and round-trip-eliminating proxy called
"lbxproxy".

This is really great, because X is kinda slow over slow connections.
And actually, once I got LBX working, it works pretty amazingly well.
XEmacs over LBX over ssh is about as responsive as XEmacs over ssh,
while XEmacs over ssh without LBX is painfully slow.  It's actually
reasonable to run XEmacs as a web browser in this mode (although
w3-mode is still not a very good browser.)

(The lbxproxy was actually part of a larger project of making an X
server that was a web browser plug-in so that, instead of running Java
applets in your browser, you could just run X applications.  This
project actually produced usable software, but I don't think anyone
ever used it.)

But getting lbxproxy to actually work is incredibly painful.

In Debian, it lives in the package "xproxy", which you must install on
the machine with the X applications you want to run.  So I installed
the xproxy package and ran the command 'lbxproxy &'.  It didn't
produce any output, but inspection with lsof told me that it was
listening on port 6063.  So I tried running xemacs.

xemacs worked, but it was incredibly slow.  Why?  Well, because it
wasn't using lbxproxy; it was just connecting to ssh's forwarded X
port.  So I ran "DISPLAY=:63 xemacs".  (Somewhere in here, I restarted
lbxproxy in case not telling it the display number I wanted it to
listen on was the problem; it bitched and moaned because it couldn't
create the directory /tmp/.X11-unix, which was because it had created
it the last time around.  I had to remove it by hand to get lbxproxy
to start again.)

It failed:
Xlib: connection to ":63.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key

Initialization error: X server not responding
: ":63.0"

Why?  Well, I suspected that my X authority file, which holds
MIT-MAGIC-COOKIE-1 keys, told it about keys for display 12 (that is,
the port ssh was listening on), but not display 63.  So I ran xauth.

xauth is, as always, a nightmare.  It has a 'help' command that isn't
much help, an 'extract' command which extracts a key and saves it in a
file in an undocumented, difficult-to-edit binary format so you can
use a 'merge' command to load it back in to another X authority file,
possibly on another machine.  Neither of these commands are documented
in the help, not even to the point of telling how many arguments they
take, and the error messages just tell me I have bad syntax without
telling me what good syntax would be, but the man page for xauth does
document them.

There are also 'nmerge' and 'nextract' commands for extracting the
same data in a "numeric" format "suitable for non-binary transmission
(such as secure electronic mail)".  Which looks like this:

0000 0004 d173483d 0002 3132 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b5c56b029374ab79811abb0e51244468

You will notice that this isn't exactly transparent either.  However,
it's obviously hexadecimal, and one of the small groups of digits
"3132" would be, in ASCII, the decimal number "12".  So I changed that
to "3633" and loaded the result back in with "nmerge", and lo and
behold, I now had the same MIT magic cookie listed for display 63 as
for display 12.

So I started up XEmacs on display 63 again; the result:
Xlib: connection to ":63.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key

Initialization error: X server not responding
: ":63.0"

Well, hell.  I gave up and resorted to running "xhost localhost" on my
laptop to temporarily allow any connection from the local machine to
succeed.  And XEmacs ran, and runs.  (Once it started, I ran xhost
-localhost to re-enable MIT-MAGIC-COOKIE-1 access control.)

Conclusion?  There is no conclusion.  Unix sucks.  X sucks.  User
interface design is a lost art.  Bit rot fills my world.  lbxproxy and
Emacs are nevertheless cool.  And one of these days I'll figure out xauth

Running the GIMP (a program like PhotoShop) over lbxproxy and ssh over
my 56K modem is a little slow; it's a little faster than loading web
pages.  I wouldn't want to edit images that way, but I could if I had
to.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
This is exactly how the World Wide Web works: the HTML files are the pithy 
description on the paper tape, and your Web browser is Ronald Reagan. 
  -- Neal Stephenson, at http://www.cryptonomicon.com/beginning_print.html