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.
Win an iPhone 6
Enter to Win
|Geek Hide-away in Guatemala - Stay for Free!||Nov 26, 2015|
|Microsoft and Linux: True Romance or Toxic Love?||Nov 25, 2015|
|Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.||Nov 24, 2015|
|Cipher Security: How to harden TLS and SSH||Nov 23, 2015|
|Web Stores Held Hostage||Nov 19, 2015|
|diff -u: What's New in Kernel Development||Nov 17, 2015|
- Cipher Security: How to harden TLS and SSH
- Microsoft and Linux: True Romance or Toxic Love?
- Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.
- Web Stores Held Hostage
- Firefox's New Feature for Tighter Security
- Geek Hide-away in Guatemala - Stay for Free!
- diff -u: What's New in Kernel Development
- PuppetLabs Introduces Application Orchestration
- It's a Bird. It's Another Bird!
- IBM LinuxONE Provides New Options for Linux Deployment