For a long time I have been frustrated by VNC's putting all of the application windows in a big window for the X root. It always seemed to me that you could have an X server that kept all of the windows separate - perhaps by having an infinitely resizable root - which then allows the windows to be forwarded to the user's display (I think of that as a client, but in X terms it is a display server), and treated independently there.
I'm not the only one. Googling finds many people looking for "screen for X". I guess I betray my age when I admit that my desire for this predates GNU screen and VNC. I remember being happy when I encountered GNU screen's terminal multiplexer, since I had used similar tools elsewhere. (By the way, while I am at it: I recently started trying to use GNU screen, after a long lapse. One of my complaints is that GNU screen seems to be screen. I vaguely remember a terminal multiplexer that handled dumb terminals well enough, allowing you to connect separate terminal emulators, as well as other stuff.)
Anyway: screen for X...
I have looked at NX, xmove, etc., at various times, all with differing degrees of clunkiness. Nothing made mwe happy until...
---+ xpra
Hurrah for xpra! http://xpra.org/
xpra allows you to send applications from one display to another. On an application by application basis. (Hmm, I wonder what happens to a multi-window application.)
I am happy that IT finally has a system on which they were willing to install xpra.
---+ Winswitch? not yet, maybe not ever
I am considering winswitch, http://winswitch.org/, which is layered on top of xpra or VNC or RDP or ssh -X or NX or ...
But I am not jumping at winswitch the way I am jumping at xpra, since (a) I don't want yet another insecure password system, and (b) it seems to depend on all sides running winswitch.
---+ xpra does NOT need to be installed on both sides
Typically xpra usage examples say
http://xpra.org/:
On the machine which will export the application (xterm in this example):
xpra start :100
DISPLAY=:100 xterm
xpra attach :100
xpra attach ssh:serverhostname:100https://help.ubuntu.com/community/Xpra:
- Start an xpra server using display number :7.
- Start firefox running inside the xpra server. No window will appear.
- Show a list of xpra servers you have running on the current host.
- Attach to the xpra server that is using local display number :7. Any apps running on that server will appear on your screen.
- Use ssh to attach to the xpra server that is running on machine frodo and using display :7. Any apps running on that server will appear on your local screen.
- Start an xpra server and a screen(1) session. If any of the applications inside screen attempt to use X, they will be directed to the xpra server.
- Stop the xpra server on display number :7.
xpra start :7
DISPLAY=:7 firefox
xpra list
xpra attach :7
xpra attach ssh:frodo:7
xpra start :7 && DISPLAY=:7 screen
xpra stop :7
I.e. they assume that xpra is installed both on the server and on the client.
(Urg, confusing terminology. There are 3 important systems here: (1) the system where the xpra proxy server runs, (2) the system where the application software runs, and (3) the system where the display runs.)
This was a worry, since I often want to move applications to a system that may have X, but which may not have xpra on. E.g. Cygwin/X on my Windows PC. (I considered Winswitch for this, but it requires itself to be installed in too many places.)
I am happy to say that you do NOT need to have xpra installed on the display system. E.g.
14 comments:
xpra seems to be a proxy server. OK, but... if the xpra server is on a machine different than the application or the display, then if the xpra machihne goes down...
It would be nice if the X application could be redirected, without a proxy.
I have never heard of a protocol or application that could rewire itself to connect to a different target. But it would be nice.
It would be bad if all applications had to have code for this. A proxy like xpra makes the facility available to all applications. To avoid the proxy and make it retargettable pee, would have to have it in the protocol. Which amounts to saying that the application would do it - but one would hope that the library would do it for all.
xpra uses display numbers like :100.
This sucks. Namespaces!!!!
(Ports and displays. Bad. Moreover, lead to security holes.)
xpra works okay with multiple applications going through the same xpra session. they open as separate windows.
on the other hand, it might be nice to have the option of switched between a rooted box of windows, and rootless.
anyway, xpra is a great step forward.
Although "ssh -X machine1 xpra attach :8" works, it is unbearably slow. Not surprising, since it goes through two X proxies.
Surprisingly, faster to run xpra inside vnc than via ssh -X. But still pretty slow.
"ssh -X system xpra attach :display" on a Cygwin/X system, followed by "xpra attach" somewhere else, leaves orphaned windows behind on the Cygwin/X display. I,e. the application moves to a new window on a new display, but the old window is not removed.
Unfortunately, I guess I need a proxy, since my laptop PC is typically behind NAT.
Unless... the X display server (on my laptop, behind NAT) and the X client (outside the NAT) could somehow rendezvous in the typical NAT traversal.
Tried...
xpra via xming on windows. no great luck. xming seems to work, starts up, e.g. xterm windows, but nothing seen. (Maybe font issues.)
xpra distro for Windows. XLaunch. No luck yet.
Too many ways to try to get to work - faster than "cygwin> ssh -X host xpra attach :N"
xpra crash (runing into VNC):
[1]+ Stopped xpra attach :8
glew@sys:~/bin$ bg
[1]+ xpra attach :8 &
glew@sys:~/bin$ export DISPLAY=:8
glew@sys:~/bin$ emacs &
[2] 15491
glew@sys:~/bin$ ~Next emacs on path after /home/glew/bin /home/glew/bin/emacs is /usr/bin/emacs
bash: /home/glew: is a directory
glew@sys:~/bin$ Connection lost to X server `:8.0'
(emacs:15491): GLib-WARNING **: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
(emacs:15491): GLib-WARNING **: g_main_context_check() called recursively from within a source's check() or prepare() member.
Error reading from socket
Connection lost
[1]- Done xpra attach :8
[2]+ Aborted emacs
glew@sys:~/bin$ emacs
Next emacs on path after /home/glew/bin /home/glew/bin/emacs is /usr/bin/emacs
Display :8 unavailable, simulating -nw
glew@sys:~/bin$
Bad things happen when xpra's DISPLAY is itself.
Experiment: xpra start :8 and :9.
Started an emacs in :8, and make-frame-on-display :9 => same emacs spread across two xpra. Same shell buffer visited in both frame. :8 attached to VNC (on Windows), :9 attached to Cygwin/X server via ssh -X. Type "ls" on PC X window. 1 second to see results in other, VNC, emacs (via xpra, ...). 10 seconds before I see the result in the window I types ls into.
xpra slowness a big issue. Even though xpra in vnc is faster than xpra via ssh -X to cygwin/X, still too slow to want to work here if I really have to.
(Possibly partly because I am working over 4G LTE mifi today. May be better back when wired - but I need stuff to work when mobile.)
But, here is a way that seems to work well enough:
(1) I have 2 or more vnc4viewers, with multiple display sizes that can be changed using xrandr -s n.
Different sizes to adapt to the different resolutions and orientations of monitors.
(2) I am still mainly an emacs user, so I run I run emacs normally with output to these vnc servers. Using make-frame-on-otherdisplay the single emacs can be used on multiple vncs, and also other X servers.
(2.1) I also have the emacs use or (or more) of my xpra sessions. So if the vncs go away or are naccessible or unusable for some reason, I can still connect to the xpra session and get the same emacs.
(3) I can run other stuff - xterms, etc - in xpra as appropriate. Typically want the xpra to be used for things like a console window, or an xterm in which I access lab hardware. In so doing, I can migrate these lab thingees.
xpra is 6/half-dozen wrt cnc for accessing lab hardwar4e:
a) xpra does allow using whatefver monitor I have - it is a pain when a shared lab machine vnc does not have the right resolution for where you are.
b) but xpra cannot be shared. Yet?
c) and xpra is slower.
So, not clear if xpra is the way to go.
spreading emacs across multiple displays, VNCs and xpras, (a) gives emacs more persistence - if a display goes away, I can still use it (unless the display going away is associated with killing the emacs process itself). (b) givesd you the ability to "call" emacs to where you are, rather than having to send it to where you next want to use it.
Hi. Just wanted to clarify. Running xpra through -X or -Y is obviously slow because the X channel is run through SSH as-is.
One neat feature of xpra is in fact in using the client : everything is sent compressed which improves performances by a whole lot.
As a point of reference, i tried to watch videos in firefox over a double ssh tunnel and got almost 3 IPS through xpra on a weaky broadband connection. And then it would only spend about 60 kB/s bandwith if i recall correctly.
In contrast, simply running a few xterms over -Y in the same setup is enough to eat all my bandwith and make QoS deny everything else... Ooops..
Xpra is really magic.
Post a Comment