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.
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.
Nicholas Petreley is Editor in Chief of Linux Journal.
Bill Longman is NIS Manager at Sharp Laboratories of America.
Linux Journal pays $100 for reader-contributed tech tips we publish. Send your tips and contact information to email@example.com.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- Vigilante Malware
- Non-Linux FOSS: Code Your Way To Victory!
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Vagrant Simplified
- Libreboot on an X60, Part I: the Setup
- Dealing with Boundary Issues
- System Status as SMS Text Messages
- Bluetooth Hacks
- October 2015 Issue of Linux Journal: Raspberry Pi
- New Products