response 1 of 135:

Jul 24 03:24 UTC 1996

I made a list of all the people who have had multiple telnet sessions to Grex
and had at least one of them logged out by the idle zapper.  I sent them
e-mail pointing them to this item.

response 3 of 135:

Jul 24 05:00 UTC 1996

I think, for the moment, this is the right policy.   Zap them.

Sometimes we have policy before we have a way to implement it.  Sometimes we
have a way to implement it before we have a policy.  So let's just say we are
currently testing the software, igure out the policy, and not worry too much
over which came first.

response 5 of 135:

Jul 24 07:43 UTC 1996

I'm glad to see that the discussion of whether a new policy is desirable
has been introduced only a *little* after the policy was put into practice.
Maybe, if we keep working at it, we can reverse the order?

I not infrequently get knocked off by a glitch in grex or the net, and
come back in on a dialin. I always kill my old process if it is still
around, but if I didn't know how, it would be the one that the zapper
should zap, not the new one. Even better, the zapper could ask which one
the user would be willing to relinquish (if the policy should have enough
support to be put into practice). Another aspect of this is fairness to
those that established multiple connections while the system was not
"overloaded" (presuming that a majority think this matters). They should
at least have a good period of time to complete what they needed multiple
logins for. Overall, though, with due consideration for issues such as
these, I do think it is reasonable to suppress multiple logins when the
system is overcrowded. Reasonable people can live with that, I think.

response 7 of 135:

Jul 24 10:02 UTC 1996

"it's not apolicy, we just have the software in place as if it
were a policy." 

response 9 of 135:

Jul 24 12:11 UTC 1996

        First of all, I will note a huge problem with the program that
kicked me out when I did have multiple sessions.  I was in the Co-op
conference when this message was displayed on my screen that i was taking
up more than one pty and it would kill the window in 10 minutes.  But to
my surprise, it killed my window 10 SECONDS after it showed that message.
If it continues to do this, I do not think it would be good.  Say somebody
is editing an important file with vi.  You receive a message on your
screen and a beep, but the message gets scrambled with the text you are
editing so you take  a while to figure out what it says.  And as soon as
you figure out what the message says, but before you have time to Save it,
BOOM your session is killed and you lose your modifications.

        Another point: you said it would close multiple windows if there
were 64 users on Grex.  Did you mean having all 64 ptys in use? Because if
there are 64 people on Grex, but some ptys still free, then I do not
believe it should kill your window.

        Now the Main issue:  I don't think we should get rid of people who
log onto Grex more than once.  I agree with brighn on this one; many
people will find out you can get around this by creating another account.
What would happen if everybody created a second account?  First of all, a
lot more disk space would be taken up for all the directories, and second
the login program would take twice as long to verify your
username/password.  The main reason why I think multiple login sessions
are acceptable is because of the new pty queue.  For many users (not
including me :(  ) the pty queue makes Grex a lot more accessible during
peak hours.

        In my opinion, we do not need a program like this until the
privilege is abused by several users after told again and again by staff to
not hog up ptys.

response 11 of 135:

Jul 24 14:27 UTC 1996

I believe so, Mary.  Some staffers have mentioned that they try to ask people
to keep down the logins when they see multiples.  Most users seem to comply
with polite requests, and IMHO most users (more users) would comply to polite
requests than to "GREX does not allow multiple logins.  Disconnect one
immediately or it will be disconnected for you".
  
ISCA BBS and Monolith BBS, for two, both disallow multiple logins.  But they
also disallow multiple handles by the same user, which requires validation
in the form of a valid email account at another site.  We've discussed the
issue of validation, and decided (or so I thought) that validation of the sort
necessary would be inimical to GREX's purposes.
  
Multiple logins seem to be two sorts of users:  users who are doing
constructive things in all but at most one of the windows, and users who are
screwing around in most of their windows.  The ones who are doing constructive
things tend to be, IMHO, mature enough to understand a polite request as much
if not more than a forced boot.  Ryan's said before that he tries to avoid
multiples during peak, as have Nestene and Arthurp.  The ones who are doing
non-constructive things (and, yes, that *is* a value judgment -- by
"non-constructive", I generally mean "being in Party") tend to be not so
mature in the first place, and if a polite request doesn't get them to log
off their multiples, then being forced to log off certainly won't -- they'll
come back with more pseudoes, and in some cases sit on Party for even more
time, badmouthing GREX and saying how facsist it is.

Unless, of course, we want to bar Party usage during peak time?  Oooo,
wouldn't THAT be a popular decision?  (That is *not* a serious decision.)
As much as there are multiples, there are also users (myself included) who
rudely hog ttys by sitting in party and pressing spacebar every few minutes,
because it's so hard to get a tty during peak.  Limited resources encourage
hoarding, which makes the resource even more limited.

I've complained about multiple logins. I've tried to cut down the amount of
time I sit on party to hog a tty, because I know it's rude.  But when we start
forcing politeness, well, what does come after zapping multiples?
  
And the last time people tried to force politeness, the detractors called it
Political Correctness and managed to so distort it that it became a social
monster.

response 13 of 135:

Jul 24 16:17 UTC 1996

It's *really* hard for staff to keep an eye out, whenever the system is full,
for people who have multiple connections to Grex, and to send mail each time
this happens.  There's an endless supply of new people who don't know that
Grex has a limited number of connections, and that their multiple connections
are keeping other people out.  Just asking is nice in theory, but almost
impossible to put into practice in any consistent and non-time-consuming way.

>> Until we decide if we want it, I've turned off the option in the idle
>> zapper that disconnects people who have multiple connections.

From replies to the mail I sent to people who were zapped because of
multiple connections, a few said they had gotten disconnected from Grex
and had been trying to reconnect when the idle zapper zapped their newer
session.  It would be an easy change to have it zap all but the newest
connection, instead of the oldest.

Ryan - It would take a bunch of coding to change the idle zapper so that it
only bumps multiple connections when all 64 ptys are in use.

response 15 of 135:

Jul 24 16:59 UTC 1996

re: #13...

If it is the right decision to turn off the disconnect option in the idle zaper
program until a formal decision has been on reached on whether to have it, (and
I think it is), then wouldnt it also be right to turn off the countdown que
until some formal decision has been made on whether to switch to it?  Both are
symptomatic of well meaning staff effecting policy before said policy has been
adopted.  This is simply not the right way to go about these things.

And Janc's response about using the "excuse" of testing to get around this
issue doesnt do anything to solve the problem either.

response 17 of 135:

Jul 24 18:11 UTC 1996

Because we've already decided that we want the telnet queue, and
we've had more people complimenting us on it than complaining.

response 19 of 135:

Jul 24 18:42 UTC 1996

Hmmm...  I tend agre with #3 (?) that it's OK to check out the program even
before a policy is defined.  If the zapper does this in 10 secs instead of
10 mins, that's a bug that should be fixed.

If the problem is that staff cann't efficiently keep an eye on multiple
sessions when the system is busy, it is apparent the idle zapper can. 
Perhaps, it can be configured to send a form-letter signed by staff or the
BoD?  Also, copy it to a staff account or file so you can keep a log of all
the folks who get the warnings, and when.  That info might make it easier to
formulate a more general policy in the future, or determine that one is
un-needed.

response 21 of 135:

Jul 24 19:16 UTC 1996

Rickyb makes an interesting suggestion in #19: Have the idle-zapper
send mail instead of actually zapping. That would have the effect
of sending requests without requiring a human being to keep an eye
on things. But I don't know if the idle-zapper can easily be made
to do that.

response 23 of 135:

Jul 24 20:32 UTC 1996

<watches the number of sendmail processes climb ... >