avoid them getting bound up...

fix the robotrack link.

	gated comes from RHL7.3 RPM,
	pathrate installed in /usr/local/bin

Orange+elabinelab is still the same.

page zapping you to that node's shownode page.

positions as you tell it to do so...

mezzanine will let those clients' pids hang around in the pid table (basis
for notifying the clients of new frame data).  Eventually, the pid table
gets too full and would-be clients can't connect.  This is now fixed...

Differentiate RHL9 and use a different build of ns.

Several other fixes to table handling.

Change the pipe webpage to use the timestamps that are now in the
location_info page, to cut down on the amount of data we spit at
the applet, which when things are not moving, is useless data.
This is still not quite correct; I have more changes coming.

* Pass pixels_per_meter to the applet so that it can convert coords
  to meters.

* Use a float formatter thingy to format numbers as X.XX

grabwebcams startup since it is no longer needed.

The new version of the webcam page connects directly to the cameras
using a URL stored in the DB (webcams table). The URL includes the
user (elabman) and the password, which is fine; not likely to leak
out the password and even if we did, no biggie since its on the private
network and no one can get to it anyway.

I have reduced the frame rate to 5fps (compression 50%) as specified
in the URL, and even thats a lot of bandwidth.

I will work on providing mpeg feeds later!

the "exec" function.  A list arg to exec used to be considered untained,
but no more.  So run all the args through a hokey ".*" pattern match to
untaint them.

This was preventing linktest from working on RHL9 (and presumably FBSD5).

users.  These messages were appearing in linktest output to users because
the linktest proxy runs on ops as root with a "full" tty ("-t -t") which
apparently makes it look like a logged in user.

Since no one logs in as root on ops, there was no legit recipient for these
messages anyway.  Since the messasge all go to log files, I don't think we
are losing anything.

but not put any actual robots on; that happens later when the tracker
applet runs and connects to the web server pipe.

Note that the java compiler on boss is too old to compile this applet
(not that I am using anything special) so I am committing a compiled
version. Use the jar target in the robots/tracker build directory if
you happen to have a modern version of java on your machine.

sizes at the same starting block

number of PCs being used by the experiment.

Missed Tim's change to tbuisp that already addresses this.