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.
|Chemistry on the Desktop||Mar 23, 2017|
|Five HPC Cost Considerations to Maximize ROI||Mar 23, 2017|
|Two Ways GDPR Will Change Your Data Storage Solution||Mar 22, 2017|
|Android Candy: That App Is for the Birds!||Mar 22, 2017|
|Hodge Podge||Mar 21, 2017|
|William Rothwell and Nick Garner's Certified Ethical Hacker Complete Video Course (Pearson IT Certification)||Mar 20, 2017|
- Two Ways GDPR Will Change Your Data Storage Solution
- Chemistry on the Desktop
- Five HPC Cost Considerations to Maximize ROI
- Hodge Podge
- William Rothwell and Nick Garner's Certified Ethical Hacker Complete Video Course (Pearson IT Certification)
- Preseeding Full Disk Encryption
- Returning Values from Bash Functions
- Two Factors Are Better Than One
- GRUB Boot from ISO
- Android Candy: That App Is for the Birds!