|
|
| Author |
Message |
| 25 new of 105 responses total. |
ajax
|
|
response 75 of 105:
| 
Feb 1 20:37 UTC 1995 |
Good point about environment modification John. One possible solution would
be, while modifying login, to have it run a script whenever guest logs in,
that reinitializes .login and other guest files. (I.e. copy them to
/home/guest from some protected area). I'll take a stab at a functional spec
to batter around.
|
ajax
|
|
response 76 of 105:
|
Feb 2 04:58 UTC 1995 |
I put together my ideas for a guest account in
/home/ajax/guest_acct_description. It's about 110 lines.
|
remmers
|
|
response 77 of 105:
|
Feb 2 13:37 UTC 1995 |
I thought of that approach to re-initializing the environment too. Not
sure how to handle the case of simultaneous 'guest' logins though.
I'll have a look at your description when I have a bigger chunk of time,
probably later today.
|
ajax
|
|
response 78 of 105:
|
Feb 3 07:08 UTC 1995 |
My approach to simultaneous logins was to mention in the intro that I don't
know the best way to handle them :-). My two main contenders:
(1) Do nothing, and hope that the effects of simultaneous guest logins are
rare, and not too serious anyway (depends on how apps like pico are written).
(2) When "guest" logs in, the login program could log them in as one of five
guest login-id's, guest1 through guest5, using whichever login id is found
to be not in use. If all five guest accounts are in use, tell the new guest
"sorry, try later." (Five being an arbitrary number, of course). This is
more work, but would solve any simultaneity problems.
|
popcorn
|
|
response 79 of 105:
|
Feb 4 00:09 UTC 1995 |
I just read Rob's functional spec. It looks good!
|
remmers
|
|
response 80 of 105:
|
Feb 4 21:03 UTC 1995 |
I basically like it too. One thing I'd add -- not sure just where --
would be some additional info on the variety of software available,
i.e. the various shells, mail programs, text editors, etc.
Having two or more people logged into the same account may cause odd
behavior in Picospan -- e.g. two processes trying to update the same
participation file. And also in mail programs -- elm refuses to run
if it detects another elm session on the same account. So I think
*something* needs to be done to handle simultaneous logins; approach
(2) in #78 seems reasonable.
|
orinoco
|
|
response 81 of 105:
|
Feb 7 02:32 UTC 1995 |
The only problem *I* can see with an anonymous account is somebody loging on
as anonymous, saying something nasty, and then somebody *else* who logs on
later as anonymous getting pestered about it
|
remmers
|
|
response 82 of 105:
|
Feb 8 12:20 UTC 1995 |
That's a possibility, but whether it would be a problem in practice
remains to be seen.
Is the source to login easily available?
|
popcorn
|
|
response 83 of 105:
|
Feb 8 13:22 UTC 1995 |
Yup, Marcus has it.
|
ajax
|
|
response 84 of 105:
|
Feb 8 17:22 UTC 1995 |
Re 81, that is a possibility. It also got me thinking, should "mesg n"
be the default on a guest account? Write requests seems to confuse
some new users who are already more than adequately confused by Grex.
|
remmers
|
|
response 85 of 105:
|
Feb 9 11:57 UTC 1995 |
"mesg n" should probably be the default, but the help messages that
the guest account displays could tell the guest how to change it (and
also tell the guest how to cut off an unwanted "write").
Something else that login should probably do with a guest account is
zero out any mail, so that a person doesn't have to deal with mail
left over from a previous login by a different person.
|
ajax
|
|
response 86 of 105:
|
Feb 10 02:09 UTC 1995 |
That's a good idea, zeroing mail. This discussion is slowing down a
bit, which I assume means much of what people want to say is said.
To move the idea forward, should I write a motion for board vote?
If approved, I assume that it would then be up to staff to decide
its priority/who/how/when/what. My offer to set it up (given access
to login) still holds, though even if trusted to do that, I realize
it would take staff time to check login changes *very* carefully! :)
|
mdw
|
|
response 87 of 105:
|
Feb 10 05:14 UTC 1995 |
I, for one, would not care to get a "write" from an anonymous user.
Actually, I can't really say I'm at all in favour of institutionalizing
the concept of anonymous users: it seems to me that's not a good way to
support and nurture the idea of "community" .. Actually, I think things
are just fine they way they *are* today; people who want to experiment
with anonymity already ahve the perfect ability to create themselves a
pseudo that is very nearly as anonymous as they want; I see no reason to
create generic green plastic dummies that nobody will feel any loyalty
for, and that are likely to acquire the worst of reputations.
|
steve
|
|
response 88 of 105:
|
Feb 10 05:38 UTC 1995 |
But Marcus, you probably have gotten anonymous writes from people
already. Since we don't verify before granting accounts, just about
all accounts here can count as "anonymous" these days. Look at the
number of people who depermit their .plan files; its really high.
Looking at it from the pragmatic point of view, a limited anon
account might make us have to clean up a few less accounts.
|
rcurl
|
|
response 89 of 105:
|
Feb 10 06:32 UTC 1995 |
Having heard all the arguments pro and con - I oppose a specific anon
account.
|
srw
|
|
response 90 of 105:
|
Feb 10 06:58 UTC 1995 |
Keep in mind that a lot of public systems do offer guest logins
specifically so that people can find out what the system is like
without going to the trouble of creating an account.
I think that this would be a good thing, and I am in favor of it, but only
if a guest account would not be able to respond in picospan, write mail,
or use unix commands.
|
mdw
|
|
response 91 of 105:
|
Feb 10 08:35 UTC 1995 |
I'm already relatively unthrilled by writes from people with depermitted
.plan's, or even writes from anybody I don't know - it's kind of like
being stopped by a stranger and panhandled. But even so, I still know
relatively more about that person - they often have a real name; I can
often tell where they come from, and I know that I can also send mail to
them later. There is still more personality there, and more potential
continuity than would exist with a truely anonymous ID. I'd like to see
those people come back & decide to become regulars; and I don't see a
anonymous account as helping, particularly.
I also wouldn't care to go through the efforts of "bullet-proofing"
everything to make them Unix-command proof.
|
ajax
|
|
response 92 of 105:
|
Feb 10 10:47 UTC 1995 |
I see your point. A guest account would benefit new users, not us existing
users. I also agree that bullet-proofing isn't worth the extensive effort.
|
remmers
|
|
response 93 of 105:
|
Feb 12 12:44 UTC 1995 |
I've been conferencing for over 10 years on Unix/Picospan-based systems,
first on M-Net and now here. The current discussion is at least the
half-dozenth go-around I've seen of the "can we set up a guest account
so folks can try things out?" question. Despite all previous discussions,
it's never been done.
|
chelsea
|
|
response 94 of 105:
|
Feb 12 13:10 UTC 1995 |
Seven's the charm?
|
gregc
|
|
response 95 of 105:
|
Feb 13 18:31 UTC 1995 |
I *think* his point was: Since it wasn't done all those other times, there
was probably a good *reason* it wasn't done.
I agree. There isn't a good enough reason for a single anon guest account
when *anybody* can create as *many* anon accounts *whenever* they want.
|
ajax
|
|
response 96 of 105:
|
Feb 13 19:38 UTC 1995 |
One thing that's changed since earlier times is that a lot more users
system-surf on the net, and a guest account is a nice convenience for them.
Having checked out a lot of BBSes and MUDs and such myself over the years,
I really like guest accounts. Especially when bouncing around the net, or
with a new local BBS list, I'd sometimes try 10 different systems in a night,
and it's very handy not to have to enter your name, hobbies, etc., to see if
you'll ever want to come back. For example, if you're searching for a
system with IRC, you might check out a lot of freenets before finding one.
I think suggesting a guest acct in the "Anonymous" item may have been a
mistake; a guest account is anonymous, but the main reason I like it is that
it's a help to prospective new users.
Anyway, I think enough board members have voiced non-support that the streak
John has observed will remain intact :). But I'd kind of like to see a quick
board vote to give this item some closure. Can an informal motion be made
in absentia for a vote, like "go ahead with a guest account along the lines
of ajax's coop #86 description, subject to final spec approval?" I wouldn't
want to take up board time with further discussion, since I think it's been
amply discussed here, but I would kind of like a vote.
|
rcurl
|
|
response 97 of 105:
|
Feb 13 23:12 UTC 1995 |
You mean, you want the board members to *commit* themselves?!
|
carson
|
|
response 98 of 105:
|
Feb 14 03:28 UTC 1995 |
hey, why don't we commit *all* the voters!
|
srw
|
|
response 99 of 105:
|
Feb 14 04:41 UTC 1995 |
Well, I like the idea, for the reasons Rob states in 96. Users are
turned away at the requirement of filling out a questionnaire just to see
what the system is about. Also, we get tons of new accounts that don't
pan out. We'd get a lot fewer if we had this.
|