response 1 of 64:

Apr 9 21:27 UTC 1996

   The problem with watch, as its currently written, is that it isn't
smart enough to know when it should go away and die.  Since it doesn't
it sits there in the background, not doing much.  Then something like
the kill_orphans program would have to come along and zap it.
   The best fix would be for watch to know when its controlling
terminal has died and die along with it.

response 3 of 64:

Apr 9 22:06 UTC 1996

   I never checked, but it shouldn't be a drain.  Its the not going
away part that makes it a pain.

response 5 of 64:

Apr 9 23:08 UTC 1996

I wrote the original version of watch used on M-Net.  It would watch the
originating user along with other users, and exit if it's originator logged
off.  It was one of the first programs I did on M-Net and wasn't very
portable.  I think a different version came into use after they moved to BSDI.

Watch does not do a "who" every few minutes.  It starts up by doing one "who"
and then it watch the end of the wtmp file, the one printed out by the "last"
command.  Thus it does rather little work and should not be a big system load.
It tended to be rather slow though, since it would only check the wtmp file
every two minutes or so, so sometimes a person would already be joining you
in party before "watch" told you he was there.  Increasing its polling rate
would increase is load on the system.

After M-Net moved to BSDI, I implemented a different version of watch.  In
this, the "watch" command just added (or removed) users from a global
who-is-watching-who database.  The actual message would be generated by the
login program.  When a person logs in, it checks if anyone was watching for
him, and sends notifications to those people.  This puts quite a bit less load
on the system, and means there are not 50 "watch" processes hanging around
on the system, doing the same thing for different users.  The messages would
also be very timely, appearing immediately as the user logs on.  The
disadvantage is that you don't get any "joe is logging off" messages when your
friends leave.  This version never got installed on M-Net.  Mostly, I didn't
have access to login source and nobody who did felt like installing this.

Another alternative would be to have a single global watch deamon.  It would
use a database similar to the one I implemented for the login-watch program,
but like the old watch it would watch the wtmp file.  Each time a user logged
on or off, it would notify all the users who were watching him.

response 7 of 64:

Apr 10 00:14 UTC 1996

  If "watch" is on, it would make an idle user appear to be active, which
would seem to cause problems.  But if the Sun04 has more space, I guess
the idle user problem isnt that critical as it used to be?

response 9 of 64:

Apr 10 01:36 UTC 1996

Again, this is a technical question.  There are two proposed methods that
would avoid this problem.  Also, do background procs contribute to lack of
idle time?

response 11 of 64:

Apr 10 04:37 UTC 1996

Well, any program that regularly sends text to a user's terminal might make
them appear not-idle.  This is no particular reason not to have a watch.

response 13 of 64:

Apr 10 13:33 UTC 1996

Personally I like the idea of having a watch file, I use it quite
extensively on m-net.  It looks like it's not a significant drain
on resources- is the whole idea of it not going away when the 'owner'
of the watch file goes away the only problem?

response 15 of 64:

Apr 11 11:21 UTC 1996

I agree with Kevin.  I don't really object to having something like watch
around, but it seems unnecessary.  And I remember how weird it felt, on a
certain other system, the first few times I logged in, when within seconds
I was receiving what seemed to me rather rude personal chat messages from
people I'd never heard of.  That kind of thing is easy enough without
watch, of course, but it seems rather like providing cans of spray paint
conveniently by the walls where you have graffiti problems.

response 17 of 64:

Apr 11 18:50 UTC 1996

  I think watch is fine but in case some people have objections, couldnt
something be put in so that if they dont want watch to note them
logging in, they could block it?

response 19 of 64:

Apr 12 02:09 UTC 1996

  I look at a watch program the same way I look at caller id...someone
can have a caller id box and can see the number I'm calling from.  But
if I want anonymity I call 1167 or *67, and I can block my number
from being revealed.  This is what should be offered in conjunction with
watch.

response 21 of 64:

Apr 12 03:59 UTC 1996

  Yep, that's the point I was trying to make.  Richard, since it's
something people can do manually, like by running finger and looking
for people, then there's nothing preventing anyone from writing a
script or program to do the same thing automatically.  I think the
closest you'll get to a *67 feature is to create a separate account!  :-)

response 23 of 64:

Apr 12 16:53 UTC 1996

(Actually, any such solutions are horrible.  I think the reason I originally
wrote an official "watch" program for M-Net, long, long ago, was that various
people had started running hideous scripts to do that which wasted CPU and
often didn't exit correctly on logout.  Installing an official version that
behaved reasonably well was a deterrent for all the the lousy versions.