|
Grex > Coop6 > #97: software suggestion: the telegram program | |
|
| Author |
Message |
| 14 new of 63 responses total. |
popcorn
|
|
response 50 of 63:
| 
Mar 2 18:18 UTC 1995 |
It's turned off because of a past history of people dumping things
like the password file to other people's screens. Newbies have *no*
idea how to reject a write session midstream.
|
popcorn
|
|
response 51 of 63:
|
Mar 2 18:18 UTC 1995 |
(Incidentally, it was discussed someplace else in this conference about
a month or two ago. If I could think of a good keyword from the
discussion, I'd find it and point you to it.)
|
steve
|
|
response 52 of 63:
|
Mar 2 20:30 UTC 1995 |
Hmm. I didn't know about &cat either. The issue of twits sending
/etc/passwd to someone else with it remains, however.
As a compromise, how about making a limit of say, 1K that could be
sent via this manner? I can readily see the use in helping someone by
showing them a file and talking about it. If we can come up with a reasonable
limit for what helpers would normally encounter, then that would satisify
the need and the concern.
|
nephi
|
|
response 53 of 63:
|
Mar 2 21:57 UTC 1995 |
Is this a workable solution? I would really like to see this done.
|
ajax
|
|
response 54 of 63:
|
Mar 2 22:03 UTC 1995 |
Sounds reasonable to me. But according to TS's description in #46, if
a twit sends a bawamba-sized file to someone's screen, it will be sent to
their own screen too. Wouldn't that in itself discourage such bozosity?
|
carson
|
|
response 55 of 63:
|
Mar 3 02:58 UTC 1995 |
if you run "screen" (or a similar program), you can have it dumped to
a screen you're not looking at, which is no big deal, really.
|
nephi
|
|
response 56 of 63:
|
Mar 3 05:18 UTC 1995 |
Really? How does that work? Do we have it here?
|
tsty
|
|
response 57 of 63:
|
Mar 3 08:50 UTC 1995 |
type !man screen , yes, it's here.
Thankxx for the support getting the right tool returned for the
right reasons, Unix is like that. It is also (with enoough
learning and insufficnet ethics/values/morals/socialization) a
group of tools that can be horridly misused.
But the risk is worth it, imo.
|
srw
|
|
response 58 of 63:
|
Mar 3 18:43 UTC 1995 |
I agree with TS on this one. We are throwing out the baby with the bathwater.
|
popcorn
|
|
response 59 of 63:
|
Mar 3 19:40 UTC 1995 |
Re 52: Are you volunteering to do the programming?
(It sounds like a pretty quick change).
|
tsty
|
|
response 60 of 63:
|
Mar 7 23:49 UTC 1995 |
adding the restriction of "only xxx lines permitted" is a bit
motherly/fatherly/paternalistic wouldn't you agree?
|
ajax
|
|
response 61 of 63:
|
Mar 8 03:38 UTC 1995 |
I don't think it's more restrictive than any other limitations Grex imposes
on users (e.g., limited party noises). On the one hand, a devoted jerk can
just do ascii uploads of worthless text with a comm prog, so it's not like
they can't work around the lack of "&". On the other hand, if experience has
shown that jerks *do* abuse the & command a lot, then I can see why some
people want a limit.
My personal feeling is that if it just slows a hacker down a bit, don't
bother, so theoretically I'd add an unlimited &. However, I don't deal with
the complaints it would generate on Grex, and it seems consistent with other
"make it just a bit less convenient" restrictions Grex imposes, which I think
are pragmatic compromises.
|
sidhe
|
|
response 62 of 63:
|
Mar 9 19:19 UTC 1995 |
nevermind. Sorry.
|
tsty
|
|
response 63 of 63:
|
Mar 10 08:00 UTC 1995 |
As I understand it, (correction requested as needed) the change is
simple in either direction. Adding "stuff" instead of just changing
a "switch" back delays the benefits.
|