More X11 discoveries

[idupree]

I'm still trying to treat my old laptop as a secondary display, for more screen real-estate.

Main laptop: Linux
Old laptop: OS X, currently

Miscellaneous discoveries:

• There are a few proxy X server implementations that allow switching a X client program between actual X servers! (Albeit by command line not click-and-drag.) Xmove is still being shipped in distros, though the code is old enough that it allegedly doesn't support 24-bit color.
  
  Xpra seems to be a modern variant with efficient network protocols and binaries for all major platforms. Unfortunately, (A) xpra has to run on both sides of a remote xpra connection; (B) my secondary display is running OS X; and (C) the Xpra OS X binary only supports[1] client mode in xpra–xpra connections (we need server mode there). Almost useful!



• There is at least one program that can deal with multiple X displays: Emacs. I think it might be helpful to put my org-mode notes on my secondary screen, so that's cool.



• It could be okay to let some programs be fixed to a certain display. Downside: if I take my main laptop on a day trip, those programs would quit.



• What if I don't want to let my secondary computer ssh to my primary computer?[2] Just as ssh -R is the reverse of ssh -L, what is the reverse of ssh -X that lets you launch a local X application on a remote display? I couldn't find one. I didn't work out how to hack it myself using xauth et al (aside from insecure non-ssh-tunneled methods).
  
  Here is my current state of the art in, at least, preventing my secondary laptop from having a permanent or stored-on-disk capability to log into my primary laptop:
  
  ssh-agent sh -c 'ssh-add local/id_rsa; ssh -AC -R 4321:localhost:22 -i dest/id_rsa d@dest -- /usr/bin/env DISPLAY=:0 /usr/bin/ssh -p 4321 -Y l@localhost emacs'
  
  I'm curious whether the return ssh could ssh to a low-privilege unix account, perhaps one with even a restricted shell. I think it's likely that I could then wrangle the X session to be usable by my main user using xauth. It probably isn't worth the complexity, considering that it won't create a security boundary anyway (see "foolhardy errand" note [2]).
  
  While experimenting with ssh, I discovered that ssh fails peculiarly when given `-i /dev/stdin`. SSH also reads any passwords from the TTY and has no way to read them from a pipe or file. Maybe I could work around the latter. I still haven't discovered how to make fake Unix TTYs that send programmatic input rather than user input. I know it must be possible because it's how xterms ultimately work.



• I experimentally rigged up a scheme that uses VNC. For remoting Emacs, it was laggier than X forwarding and lost the connection after about 15 seconds. (Bear in mind I was lazily forwarding over WiFi, not fast ethernet. I suspect it works fine over Ethernet.) VNC is a fairly dumb bitmap-based remoting protocol; smart bitmap-based remoting protocols like SPICE (wikipedia) have decent compression and diffing, though I couldn't try SPICE here because only Linux and Windows seem to be implemented at the moment.
  

  Xvfb :1 +extension Composite -screen 0 800x600x24+32 \
    -nolisten tcp -noreset -auth $XAUTHORITY &
  x11vnc -display :1 -localhost -passwdfile my/vnc/pass/file

  OS X is weak on the command line: I found no way to launch its VNC client over SSH and did it with manual GUI actions. On Linux/X11, by comparison, I can run `cat my/vnc/pass/file | vncviewer localhost:5900 -autopass`.
  
  I gather that tightvnc's `vncserver` can do in one step what I did with Xvfb and x11vnc. That sounds nice, but the network bandwidth and manual-every-time setup still make me less interested (unless someone points me to solutions).



• Synergy is not the same thing, but works shockingly well. (That is, provided you pay attention to security and, say, tunnel it through SSH rather than let network attackers pwn you. The days of my LANs being simple enough are over. Today all that mutual trust increases our attack surface.)
  
  Synergy is convenient to run at the same time as one of the X remoting mechanisms.



• Privilege check (a meta note about talking about this subject): I have two computers. Most people have zero, and among Americans it's quite common to share one amongst a household (these citations are iffy — feel free to dispute). Of course, one of my computers is 5.5 years old, and computers are my profession. Still, another person might have sold the older computer; it's a MacBook so it might get a few hundred dollars still, despite its iffy down-arrow key and disintegrating case and maximum 3 GB RAM.
  
  Another person might not be able to purchase a $1000 laptop every five years. Complicating that: for people who don't push their software limits as much as I tend to, there is no need for my newer laptop's RAM and CPU power.
  
  Furthermore in privilege, I have time to spend tinkering with X11. Besides privilege, this tinkering says something about my psychology and about the ways to be effective at my profession.
  
  Here come the footnotes!—

[1]

$ /Applications/Xpra.app/Contents/MacOS/xpra --version
xpra v0.7.0
$ /Applications/Xpra.app/Contents/MacOS/xpra --help   
Usage: 
        xpra attach [DISPLAY]
        xpra detach [DISPLAY]
        xpra screenshot filename [DISPLAY]
        xpra info [DISPLAY]
        xpra version [DISPLAY]
(This xpra installation does not support starting local servers.)
[...]

[2]
I acknowledge that this is a foolhardy errand: my secondary computer could manipulate a window such as Vim or Emacs. It could get a shell by just a few well-placed keypresses.

I kind of wanted display-video-only remoted, but all of the solutions I've found, unsurprisingly, remote the mouse/keyboard input as well. It looks like Xvfb + vlc (scroll to "Shared memory") might be able to do that; however, I'd have to do something else (any ideas?) to be able to locally point my input devices at that X vs. my main one, to easily switch which one is receiving input.