From Dirk Janssen <dirkj_AT_u.arizona.edu>: Here are several good ways of working on your laptop from your desktop machine. If you have a separate desktop machine at work, you might want to use that as a terminal server to your laptop. This means you get the larger screen and the better keyboard, without having to worry about syncing files. The easiest way to do this is to install ssh on both sides, and ssh from your desktop (running X) to the laptop. Ssh will provide a secure connection and, crucially, a secure X connection between the two machines. If you type, for example, emacs & in the ssh shell, emacs will start a window on your desktop machine while running on your laptop.

There are various ways in which you can make this situation more productive/complicated. Emacs, for one thing, can open windows (called frames by emacs) on separate displays by using make-frame-on-display. This way, you can have the same emacs displaying on your desktop and your laptop: A dual headed system is born.

For other programs, you usually have to decide at startup time on which screen you want them. To run them on the laptop screen, start them as usual. To run them on the desktop screen, start them from the ssh shell on the desktop or redirect their screens using the DISPLAY variable. Some programs also accept a -display option. Read the documentation on xauth on how to set this up. An easy way out is to find out which pseudo display ssh has created for you by typing echo $DISPLAY in the ssh shell. Assuming your desktop is called olli and your laptop stan, this will usually produce something like stan:10. This means that processes on stan (the laptop) display on what they think is the 10th screen of stan, which by some ssh magic is actually relayed (in a secure way) to the screen of olli.

There are some ways in which you can dynamically move windows from one machine to another. A very interesting approach is taken by xmove, but this program lacks a good user interface (any volunteers?). Xmove creates a pseudo screen (similar to the stan:10 that ssh creates) and windows that have their DISPLAY set to this pseudo screen can be moved back and forth between real screens (provided all screens use the same color depth).

Alternatively, you can run an one of the several programs that open a virtual root window: A window on your desktop that contains other windows. It looks a lot like running an emulator. With these programs, you can start your processes on stan, then move all their windows to olli, then work for a while, and then move them back so you can continue working on stan. Hibernate your laptop and repeat ad infinitum. Check out xmx and VNC for this.

If this is all too complicated for you, but you like to use the two screens at the same time, consider at least installing x2x. This little tool makes it possible to move your mouse from one screen to the other, and the keyboard focus goes with it. To run it, you need another ssh going from stan (the laptop) to olli (the desktop): ie. type ssh olli in a stan xterm. Keep this shell running and find out which pseudo screen was created with echo $DISPLAY. This will return something like olli:10 (see above for explanation). Now, type this in any shell on olli: x2x -west -to olli:10 (and I mean, in a shell that runs on olli and displays on olli, not an ssh shell) This creates a little black band to on the left (west) side of your desktop's screen. Whenever you move the mouse over this, the mouse on screen olli:10 will move. Because olli:10 is just an ssh-created alias for the screen of stan, the mouse on your laptop will move and you can type there by only moving your head, not your hands.

A note on X-security: Playing around with various screen programs is much easier if you issue an xhost + on either computer. But this is extremely unsafe. Do this only when you are not connected to any larger network. If you have everything working, spend some time on getting xauth to work. If you use xdm, it is usually easy. Otherwise, consider starting your Xserver with the same magic cookie all the time. This is less safe, but still pretty safe, and it means that you have to copy the cookies only once. Check the startup scripts (.xserverrc, .xinitrc, .xsession, etc) for something like cookie="MIT-MAGIC-COOKIE-1 `keygen`" and change that into (invent your own cookie here): cookie="MIT-MAGIC-COOKIE-1 12345678901234567890abcdefabcdef"