
When reporting a bug, please do your best to describe *everything* about
your setup -- how are you spawning remote processes, what OSes, what 
version of the seti@home client are you using, what you were doing at the 
time the bug occurred, etc..  It will be very appreciated.

Known bugs/issues:

 - child termination problems
   - parent terminal can get funky with weird client exits; needing 'reset'
   - start remote client via ssh w/o -t.  Kill it, it keeps running.
     start another one, get "Another instance" message.  1) setiherder
     fails to mark it as inactive.  Manually kill the daemon one, try
     and 'stop' the non-running one in herder (it forces you to since it
     thinks it's running) and *boom* X dies.  yeek.

 - process spwaning error conditions need work.  
   - if the child fails to execvp() a local command, and 'return' we get Xlib
     async reply errors.  If we exit()  instead, we get a broken pipe.  If
     ssh remotehost badcommand fails and exits, it's all fine.  What is weird
     about our directly forked child vs an exec'ed command?

 - need another, higher-level call to spawn a client.  There's too much
   inline error-checking going on with the current method and it's
   repeated 3 times in the code.

 - the client->died business is goofy.  Too much globalishness.  Fix.

 - When used with GTK 1.2.0 or 1.2.1, the expanded dialog causes a lot of
   strange GtkBlahBlah messages to appear on stdout.  This is a known problem,
   as these two versions of gtk wouldn't let you create a label with a NULL
   string.  They've fixed it in the most up-to-date versions, so I'm calling
   it an old Gtk bug and do not plan to work around it.

