Tech Tips

—Nicholas Petreley

On most PCs, you can start more than one X session and switch between them with Ctrl-Alt-F7 and Ctrl-Alt-F8, for example. Why would you do this? Well, some X applications don't really need a full-blown window manager gobbling up your precious RAM and CPU. For example, VMware Workstation and Stellarium are two applications that I use (rarely simultaneously, by the way) that don't need anything but a display. I don't need cut and paste with Stellarium, and VMware is basically a display manager in itself. In addition, just playing with X in this way makes you understand the interrelationships between X, your window manager and your applications.

Start your X engine (aka implicit xinit). You probably just use startx, and it reads your .xinitrc file and, doing what it's told, thereby launches X on the first available console, complete with window manager. This is probably display :0.

Start your X2 engine (aka explicit xinit). From a terminal, you can launch another X server on your machine:

xinit /opt/vmware/workstation/bin/vmware
 ↪-display :1 -- :1 &

The first argument taken by xinit is the path for the client that will be launched. It must be an absolute path starting at /. Everything after the -- is passed to the X server. Read the xinit(1) man page a bit for more fine examples.

—Bill Longman

It's often extremely frustrating or time consuming to run an xterm on a remote host just to fork your programs from that remote machine. Why not simply run your window manager there, even though you're not on its console? The window manager is just another X application after all, isn't it?

Fire off your local X server:

xinit /usr/bin/xterm -- :1 &

This yields a vanilla X session with merely an xterm running—no window manager. Now, you need to add permissions to this window session for the remote host. You can tunnel the connection through SSH if your network is insecure, but there's a distinct performance hit. If your network is secure, you can simply do xhost +remotehost and spray directly to your X server.

For tunneled SSH:

ssh -fY remotehost /usr/bin/wmaker

For spray directly:

xhost +remotehost
ssh -f remotehost /usr/bin/wmaker
 ↪-display localmachine:1

The first option, if your remote SSH server supports it, uses a locally defined DISPLAY that then gets tunneled to your local side over SSH. The second option allows remotehost to send X data directly to your local display, then runs Window Maker there but displays it locally. Now, all your desktop actions are done on the remote machine, not locally.

—Bill Longman