"Linux Gazette...making Linux just a little more fun!"

Getting the most from multiple X servers - in the office and at home

I wonder how many people know how to get the most from the power of X - it really sets Unix apart from simple windowing PC's. Here is a tip that I've been using for years - maybe it will be news to others as it's not really documented anywhere for the average user, it's rather buried in the man pages.

To set the scene, poor old dad often has to stand aside to let the rest of the family read their email, do their homework etc. This is a bit of a fag on certain well known proprietary windowing systems as you would have to

save your work exit all applications, log out, let them play through, log them out, log back in restore all applications

Rather than do all this, I simply create a new X session with the following command:

X :1 -query raita &

where 'raita' is the name of my computer. A new X server starts up and the visitor can log in and do their stuff. We can flip between their session and my own with Ctrl-Alt-F8 and -F7. When they are finished, they simply hit Ctrl-Alt-BackSpace or log out and I warp back to my own workspace with Ctrl-Alt-F7.

No loss of data, no messy loging in and out.

You need to be running an XDMCP session manager (e.g. xdm, gm or kdm) for this to work. You are using XDMCP if you get a graphical logon at bootup. If you have a text-mode logon and run X with startx then you might need to modify this approach.

I also use this neat feature of X at work - we have many Unix systems that I need to log into from time to time - Linux, Solaris and UnixWare. I could use rlogin, rsh or xrsh but for some jobs nothing beats a full X session.

I can flip from one system to another by creating new X sessions on my Linux workstation. Normally at work I use a slightly modified command:

X :1 -indirect dun &

... where dun is runnning an XDMCP server (like xdm, gdm or kdm). It then gives me a chooser that I can use to pick which system to log into.

I often have many such sessions at once - just increment the display number for each and they map to different 'hotkeys':

X :1 -indirect dun .... Ctrl-Atl-F8 X :2 -indirect dun .... Ctrl-Atl-F9 X :3 -indirect dun .... Ctrl-Atl-F10

with Ctrl-Alt-F7 being the default X display :0

Another ploy is to use Xnest in a similar way. Instead of getting an extra X server, Xnest runs a new X session in a window. I use this:

Xnest :1 -indirect dun &

or, if I want to use a full-sized screen I use:

Xnest -geometry 1280x1024+0+0 :1 -indirect dun &

There are some minor issues with font sizes when using a smaller window but generally not too bad.

Starting and stopping daemons

If you get tired of typing "/etc/init.d/apache reload" every time you change your Apache configuration, or if you frequently start and stop squid (e.g., to free up memory for extensive image editing), use shell functions to take the tedium out of typing.

The following functions allow you to type "start daemon", "stop daemon", "restart daemon", and "reload daemon" to accomplish the same thing. They should work on Debian or a similar system which has a script for each daemon in /etc/init.d/, where each script accepts start, stop, restart and reload as a command-line argument.

I used zsh, so I put the following in my /root/.zshrc:

function start stop restart reload {  /etc/init.d/$1 $0  }

The equivalent functions in bash look like this:

function start { /etc/init.d/$1 start; }
function stop { /etc/init.d/$1 stop; }
function restart { /etc/init.d/$1 restart; }
function reload { /etc/init.d/$1 reload; }

Debian actually puts the name of the package in /etc/init.d/; this may be different than the name of the daemon. For instance, the lpd daemon comes from a package called lprng. An enhancement to the functions would be to recognize lpd, lpr and lp as synonyms for the easily-forgotten lprng.

Disabling the console screensaver

Shane Kennedy <skenn@indigo.ie> asked the Answer Guy:

How do I switch off the shell screensaver?

setterm -blank 0

It's a feature of the Linux console driver, not the shell.

Tips in the following section are answers to questions printed in the Mail Bag column of previous issues. These tips were compiled with help from Michael Williams (Alex).

Linux Kernel Split

Thu, 04 May 2000 08:34:09 -0500
From: Christopher Browne <cbbrowne@hex.net>


This can refer to to things:

a) The fact that Linux kernel releases are split into "stable" and "experimental" releases.

Thus, versions numbered like 1.1.n, 1.3.n, 2.1.n, 2.3.n represent "experimental" versions, where addition of new functionality is solicited, whilst those numbered 1.0.n, 1.2.n, 1.4.n, 2.0.n, 2.2.n, 2.4.n represent "stable" versions, where changes are intended to only be made to fix problems.

Occasionally, "experimental" functionality gets backported to the "stable" releases, but this is not the norm.

b) There is a theory that, at some point, development of Linux could "split" to multiple independent groups.

For instance, there are some people working on functionality intended to support big servers (e.g. - SMP, various filesystem efforts). And there are others building functionality supportive of tiny embedded systems (Lineo, Embeddix, ...)

The theory essentially goes that since their purposes are different, there may be some point at which the needs may diverge sufficiently that it will not make sense for there to be a single point of contact (e.g. Linus Torvalds) to decide the direction of development of _THE_ official
Linux kernel.

What might happen is that a group would take a particular version of the Linux kernel source code, and start developing that quite independently of another.

For instance, there might be a "split" where the embedded developers start developing the kernel in a way attuned to their needs.

This is _essentially_ what happened when OpenBSD "split" off of the NetBSD project; the developers concluded that they could not work together, and so a new BSD variant came into being.

The use of the GNU General Public License on the Linux kernel does mean that it would be legally permissible for a person or a group to perform such a "split."

It would, however, be quite _costly_, in that it would mean that the new group of developers would no longer have much benefit from the efforts of people on the other side of the split. It is a costly enterprise (whether assessed in terms of money, or, better, time and effort) to keep independent sets of source code "in sync" once they are purposefully taken out of sync.

Hope this helps provide some answers to the question...

Incorrect Tip....

Date: Sat, 13 May 2000 15:57:49 -0400
From: Tony Arnett <lkp@bluemarble.net>

Tip given on Linux systems that do not recognize the total almount of available ram.

The tip given was to insert the following param into "lilo.conf"

append="ram=128M"

I had no such luck with this param. I think the proper param to use is:

append="mem=128M"

This worked for me on my Gentus Lunux 1.0 System.

Here is my entire lilo.conf


boot = /dev/hda
timeout = 50
prompt
default = linux
vga = normal
read-only
map=/boot/map
install=/boot/boot.b
image = /boot/vmlinuz-2.2.13-13abit
label = linux
initrd = /boot/initrd-2.2.13-13abit.img
root = /dev/hda5
append="hdc=ide-scsi hdd=ide-scsi mem=128M"
other = /dev/hda1
label = win


I hope this will help someone.

Lost Kingdom Productions
Tony Arnett

[It is definitely append="mem=128M" as you say. I use it myself. The only instance of "ram=" I could find was in http://www.linuxgazette.com/issue44/tag/46.html, and it is quoted in part of the question, not as the answer. If there are any other places where it says "ram=128M", please let me know where and I'll fix them immediately.

I looked in the Bootprompt-HOWTO http://www.ssc.com/mirrors/LDP/HOWTO/BootPrompt-HOWTO.html and did not see a "ram=" parameter. There are some "ramdisk_*=" parameters, though, but that's a different issue. -Ed.]

Re: Command line editing

Wed, 17 May 2000 08:38:09 +0200
From: Sebastian Schleussner Sebastian.Schleussner@gmx.de

I have been trying to set command line editing (vi mode) as part of
my bash shell environment and have been unsuccessful so far. You might
think this is trivial - well so did I.
I am using Red Hat Linux 6.1 and wanted to use "set -o vi" in my
start up scripts. I have tried all possible combinations but it JUST DOES
NOT WORK. I inserted the line in /etc/profile , in my .bash_profile, in
my .bashrc etc but I cannot get it to work. How can I get this done? This
used to be a breeze in the korn shell. Where am I going wrong?

Hi!
I recently learned from the SuSE help that you have to put the line
set keymap vi
into your /etc/inputrc or ~/.inputrc file, in addition to what you did
('set -o vi' in ~/.bashrc or /etc/profile)!
I hope that will do the trick for you.

Cheers,
Sebastian Schleussner

This page written and maintained by the Editor of the Linux Gazette. Copyright © 2000, gazette@ssc.com
Published in Issue 54 of Linux Gazette, June 2000