[FreeNX-kNX] Looking for NX and FreeNX success stories

[Bruce Stephens]

Kurt Pfeifle <k1pfeifle at gmx.net> writes:

[...]

> So if there is nothing else you can do to keep these industrious NX 
> and FreeNX developers motivated, please provide more testimonials 
> about how you use (Free)NX, and what your experience with it is.

I'm not sure I have a testimonial as such.  The basic technology is
great, a very definite performance improvement on VNC (I can run a
1280x1024 display over an ordinary ADSL connection (on the same
connection VNC struggled with 640x800) and it's usable---not great,
but usable---and I'm sure a lower resolution could approach snappy).
However, the lack of a good OSS client has so far hindered me in
getting the freenx bit working (I'd like an OSS client so I can see
what it's trying to do).

And initially I found the available information about everything to be
not as clear as it might be, so I was misunderstanding all sorts of
things and generally flailing.

Anyway, I found nxtunnel and nxtunnel-server scripts somewhere and
hacked them so they work appropriately for me, and I'm just using
iptables and ssh port forwarding to get the two ports that they
require through (they use :80, so I need 4080 and 6080).  

Many of the problems I was having before was not really realising that
NX requires these two additional ports (whose number can vary a bit
depending on exactly what you do), and both ends of my connection are
behind NAT routers and things which just chop off extra connections
(ssh is OK, but anything else requires a bit of work).

I think once the base libraries and programs hit distributions this
stuff ought to be popular among many people who currently use VNC.  

My guess is that a good approach would be to play on exactly that:
assume your audience is familiar with VNC, and show how NX is kind of
like that: nxagent is kind of like vncserver, nxproxy (with whatever
flag it needs) is kind of like vncviewer.  

And in general look at cleaning up scripts or programs to provide
something that works more or less like VNC: so it only requires one
port (and say what that is), and in general is as easy as VNC to set
up.  (Neal Walfield's nxtunnel has the right idea (forwarding both
ports through the one produced by the X part of an ssh -X connection),
but for some reason failed to work for me, however much I hacked at
it.  I *think* it's because it requires bash too much, and my login
shell is zsh (which doesn't set HOSTNAME), but I confess the scripting
is too subtle for me to follow well enough to really have a chance at
fixing it.)

Oh, another thing that I didn't come across when looking at the bits
and pieces of documentation: vncserver requires a password when one
connects with vncviewer.  So how does the NX protocol authenticate?  I
presume it uses the X authentication stuff, and that's what these
scripts are doing when they go to all this trouble to set up cookies
and set them up at both ends.  I don't remember reading that anywhere,
though.

I've no particular issue with knx/nxclient and freenx: that seems neat
too.  I just found it too complex to get working initially, and it
just doesn't seem that useful for what I want (basically a faster
VNC).  If suspending worked, then that would be a significant bonus;
even then I think I'd probably want to do things differently (maybe
run things in vnc and use nxviewer).