|
Grex > Coop8 > #95: Is it OK for one person to use several connections to Grex? | |
|
| Author |
Message |
| 25 new of 135 responses total. |
rcurl
|
|
response 100 of 135:
| 
Jul 31 18:06 UTC 1996 |
I got zapped by the idle-zapper....20 minutes isn't long when someone comes
by with something you have to attend to. But then, a strange thing happened.
I seem to be disconnected, but while starting to do things to reconnect,
I found I was still connected after all. It was very mysterious.
|
janc
|
|
response 101 of 135:
|
Jul 31 18:35 UTC 1996 |
I thought the reason we weren't talking about the
idle-zapper/multilogin-zapper was that we had pretty much agreed on it. The
idle-zapper is hardly controversial. Staff has been manually zapping idle
users for months. There has been a timeout on some of the dialin lines for
at least a year. With the difficulty of getting into Grex on either dialins
or telnet, knocking people off who've been idle 20 minutes is pretty much a
no-brainer.
The multilogin zapper is off, and there seems to be no strong desire to turn
it on. The policy most people seem happy with is to discourage but no
disallow multiple logins.
|
remmers
|
|
response 102 of 135:
|
Jul 31 19:42 UTC 1996 |
The timeout on the highspeed dialin lines has been in place for
more like two years. I think that one may actually be 15 minutes.
It was instituted only after STeve had entered a discussion item
about it in Coop asking if people thought it was a good idea and
if so, what the timeout length should be. After some days of
discussion, a "rough concensus" was reached that a timeout would
be a good idea and how long it should be (I think it's 15 minutes,
but maybe not -- somebody correct me if I'm wrong).
Anyway, Jan's right -- the principle and details had been agreed
to after public discussion right here; it's not much of a stretch
to say that implicitly we agreed to extend it to the telnet lines
too when it became technically feasible, especially since we were
having the same problem on the telnet lines as we had before on
the dialins -- lots of idle jobs that were shutting out other
people from logging in.
I'd point out too that it was a board and staff member at a board
meeting who noted that logging off multiple logins wasn't a
procedure that had ever been discussed or agreed to in Coop; there
was immediate agreement that an item was needed here to discuss
it.
Personally, I think that the accusations that the staff is
negligent in discussing common concerns openly, and is not
listening to user input, is something of a bum rap. No system is
perfect, and there are slip-ups, but when they are pointed out,
they're corrected.
|
pfv
|
|
response 103 of 135:
|
Jul 31 21:43 UTC 1996 |
I agree.... Common sense 'fixes' do not need to be debated.. Yeah, if the
'fix' turns out buggy or takes enough flak, it's possible it was not a
real concern, but - so far (knock on wood) - this staff has more common
sense than I've seen in the previous two years elsewhere..
Debate team or Congress, this ain't...
|
brighn
|
|
response 104 of 135:
|
Jul 31 23:58 UTC 1996 |
(I didn't mean to imply that Scott was saying "cough up or shut up"...
I guess I'm just defensive because I *do* wish I had the money...)
|
srw
|
|
response 105 of 135:
|
Aug 1 04:47 UTC 1996 |
We know there are a number of folks who can't afford to help Grex out, and
the consensus of members has always been that it's OK. We know that if
the situation changes, you'll be there with support. In the meantime - enjoy,
and don't fret about it.
For those who really like Grex and *can* afford to help by becoming a member,
well, you know what you *should* do. So do it.
|
tsty
|
|
response 106 of 135:
|
Aug 1 06:51 UTC 1996 |
thank you 101/102/103/104/105 ... open drift is now a FineThing (tm).
|
scott
|
|
response 107 of 135:
|
Aug 1 10:58 UTC 1996 |
(It's the PBS thing... I'm not afraid to hit people about donating, esp. if
they've just been talking about how long they've been on Grex and how much
they like it. No personal offense meant, but I *will* target people on
occasion...)
|
brighn
|
|
response 108 of 135:
|
Aug 1 20:17 UTC 1996 |
no problem, so long as y'all don't take to calling people at home =}
|
popcorn
|
|
response 109 of 135:
|
Aug 6 04:36 UTC 1996 |
Re 101: Hm. Actually, I thought we weren't entirely at a consensus yet, but
that it was tending toward having a "multiple login warner" instead of a
"multiple login zapper". The idea would be to warn people that the system
is full and they have multiple logins, but not to zap them.
What do people think about that?
|
tsty
|
|
response 110 of 135:
|
Aug 6 05:35 UTC 1996 |
nice idea, nice compromise - and possibly a valuable reminder in case
some dual-login has finished the work onthe other pty.
|
pfv
|
|
response 111 of 135:
|
Aug 6 06:34 UTC 1996 |
I like it.. Especially if it can be run at.. Say one minute or 2 minute
intervals..?
Can the program also prompt for deleting the inactive ports?
|
remmers
|
|
response 112 of 135:
|
Aug 6 10:15 UTC 1996 |
Not easily. To do that, the warning program would have to grab
control of the keyboard away from whatever the user was running,
and later give it back. Hard to do in a Unix environment. It
could, however, display instructions for deleting them.
|
pfv
|
|
response 113 of 135:
|
Aug 6 16:24 UTC 1996 |
Hmm...
So, the 'observer' can alert the user to the abuse, and perhaps
list the !kill sequence to kill the older/unused ports, but it can't
accept a y/n response?
Pretty strange.. I can accept that limitation, but - if the
'observer' has already written.. Oh. Nevermind.. Yeah, I can see it now:
the write to the tty works, but the input is already exclusive to whatever
program is running.
OK, can the killer-prompt create a small tempfile that embodies
the appropriate !kill so that the user can simply hit !comply or
something?
|
kerouac
|
|
response 114 of 135:
|
Aug 6 16:43 UTC 1996 |
I like the multiple login warner idea...a fair solution
|
mdw
|
|
response 115 of 135:
|
Aug 7 00:40 UTC 1996 |
Actually, it's worse, input *isn't* exclusive to whatever program is
running. Instead, it's essentially *random* which program gets the
input, and things get *really* messy if something like vi, less, more,
or lynx is running.
You can say "!stty 0" to kill a login session; this works both on
dial-in's, and telnet sessions. It does mean that your participation
files won't be saved (if you do this from PicoSpan), but in the case of
multiple logins, things are already hopeless.
|
popcorn
|
|
response 116 of 135:
|
Aug 7 04:25 UTC 1996 |
I think the idea is to have the zapper tell the user how to kill all their
*other* sessions and leave the current one connected. The "!stty 0" command
would do the opposite.
|
chelsea
|
|
response 117 of 135:
|
Aug 7 13:03 UTC 1996 |
I too like giving more information and asking for courtesy.
Nice plan.
|
janc
|
|
response 118 of 135:
|
Aug 7 16:09 UTC 1996 |
If more than one program writes to the same tty at the same time, the text
can get a little mixed up, not necessarily appearing on separate lines. This
isn't great, but it's OK for write banners and watch alerts. If more than
one program reads from the same tty at the same time, individual characters
may be grabbed by different programs, so tht varius carcters wuld stl b grbd
by gate, whlethe others get grabbed by the other program. For this to work,
the program would have to find all processes running on your terminal, and
figure out how to halt them all temporarility, while it does its read. It's
probably possible, but it's very tricky. No Unix program I've heard of does
this.
|
mdw
|
|
response 119 of 135:
|
Aug 7 22:26 UTC 1996 |
You can say "!stty 0 >/dev/ttyXXX" to kill session on tty XXX from
another tty. That is, you can if it's "you" on both lines. (It would
obviously be a bad thing if strangers could do this to you...)
|
popcorn
|
|
response 120 of 135:
|
Aug 9 10:04 UTC 1996 |
That worked on the Sun 3 and the Sun 2, but when I've tried it on the Sun 4
it's disconnected my current session every time.
|
davel
|
|
response 121 of 135:
|
Aug 9 14:41 UTC 1996 |
Just a wild guess (based on slightly different function in somewhat different
environment), but just maybe you need "<" instead of ">"? This is a guess,
& I'm really not in a postition to try it out.
|
janc
|
|
response 122 of 135:
|
Aug 9 21:35 UTC 1996 |
Different implementations of stty require different redirections. Writing
it so ">" worked was a bad idea in the days when other people's tty's were
generally writable, so most of the stty commands I've seen operate on standard
input instead of standard output. Some use standard error. I have no idea
which Grex uses.
|
mdw
|
|
response 123 of 135:
|
Aug 10 00:43 UTC 1996 |
We are blessed with THREE implementations of "stty" here; /bin/stty
(which is presuambly the standard 4.1.3 version of stty), /usr/5bin/stty
(which is nearly, but not exactly the same as /bin/stty), and
/usr/local/bin/stty (which appears to be a gnu version). The /bin and
gnu versions both set/change settings on stdout, and report settings to
stderr. The 5bin version sets stdin, and reports to stdout.
So, for *most* people, "stty 0 >/dev/ttyXX" should work. For people who
have 5bin first on their path, "stty 0 </dev/ttyXX" would be the right
usage.
|
davel
|
|
response 124 of 135:
|
Aug 10 16:46 UTC 1996 |
Well, I've got the following path:
/usr/local/bin:/usr/ucb:/bin:/usr/bin:/usr/games
And when I tried it yesterday, using "stty 0 < /dev/ttyXX" it worked just
exactly right - my session on ttyXX was logged out.
|