response 51 of 103:

May 16 22:26 UTC 1995

Back up the system. Try the accounts. See what happens. Spare
the examples. Evaluate and adjust. Remember adbarr's holiday 
gifts. This is a plan. Work the plan.

response 53 of 103:

May 17 03:43 UTC 1995

        Yes, but because each person learn differently, this also means
that if you limit it to "informational" you'll be denying a lot of
people who require a more "hands-on" kinda thing the chance to really
appreciate here. The non-participatory nature of guest-but-can't-do-
anything accounts has turned me off from many freenets. This allows
the user to get a real feel for what we are like.. everyone learns differently,
like you said. If you strip it down to a "no-touch", you'll be denying
people the kind of flexibilty we need to allow them, so they can grow
comfortable, and choose their own pace, instead of us telling them
what they can and can't do.

response 55 of 103:

May 17 12:21 UTC 1995

Just a few examples that spring to mind:

In the way beginning it was suggested we could never simply allow folks to
login and choose whatever login ID they wanted because folks from M-net
would flood over, select another's ID, and we'd have a Holy War.  It was
decided over much protest to try it without porting any ID's over.  The
users behaved themselves.  There were few, if any, problems. 

M-net was experiencing anarchy over the staff and Board's attempt
to control conference creation.  It moved over here when someone
requested the Vomit Conference be created.  We too had to encourage
folks to take a deep breath, trust the users, and continue with our
free-wheeling ask-and-it-shall-be-done-style.  There were few, if any
problems.

The shadow password file was going to be big trouble.  Last I knew
it was working quite well, or at least was our best effort toward
thwarting those who find cracking password files good sport.

And, oh my, the mesg program was going to be very disruptive?  Over
much protest it was decided to give it a try.  How's it going?

At one point staff was dealing with twits by going into the twits
files and changing things like the individual's login scripts in order
to harass them into seeing how wrong they were.  Over a whole lot
of protest it was decided to not do a tit-for-tat but treat offenders
like adults *first*, and only get ugly *when* it's proven *nothing else*
works.  Has staff had to get ugly and use the same dirty tricks lately?

Anyone remember the discussions regarding what would happen when 
Usenet was opened up to non-members?  The outcome is still pending
on this one but do we still have reason to think members will stop
being members because of the incredible Usenet service we'll offer?

Then there was the discussion on cabals so that Grex wouldn't
be lacking in complexity, a Bill of Rights so that Grex could promise
users a quality experience, and Robert's Rules to make us all look
like we knew what we were doing.  All of these were suggested and 
rejected 'cause they we are sledgehammer approach for itsy-bitsy
or non-existent problems.

So here we are, again looking at a new service, and trying
to find a way to cripple it before we know what it can do.

And some of us are still saying, give it a try, find out what the guest
login account can comfortably do and not do, then make adjustments. Let's
not consistently react by assuming the worst from our users. 

response 57 of 103:

May 17 15:12 UTC 1995

Some of those predate my involvement (or I don't recognize them), but some
appear to be good examples of the principle of trying it out - and finding
there is really no problem. Somehow or other, though, that principle was
not accepted for other things, like private conferences, or using Roberts
Protocols (from my experience). It seems to be a principle that is applied
selectively, depending on whether one likes the proposal or not. I
therefore think that "lets try it and we can decide if we like it or not"
has certainly not been consistently applied, nor can it be, as one must
consider the consequences of the proposal not working, and the effort to
undo the "damage" - if any is possible. 

response 59 of 103:

May 18 01:44 UTC 1995

It's soooo easy to blurt, "I'm afraid" and fail to try. Grex is
supoosed to be different from that, and, now and then, it is different.

response 61 of 103:

May 19 16:56 UTC 1995

  Most most of the examples Mary cited are from a while back.  As recently as
coop item 19, you can reread the fear that adding a few high-speed or
error-correcting modems without a terminal server would slow Grex down too
much, or that putting 9600s on the same trunk as the 2400s would cause big
problems for 2400 bps users, or about the nightmare of having two different
modem models on a single system.  None of those fears seem to have
materialized.  Nobody was sure they wouldn't, but there was the familiar
split between the experimental "let's try it and see" and the pessimistic
"let's not" camps.  "Let's try it and see" is not a sufficient reason to try
something (as Rane says, you need to consider consequences), but if a change
can be easily backed out, it certainly limits its downside consequences.
The proposal here is not a commitment like buying equipment or moving Grex.
 
  Marcus said (#52) "the only argument I've seen offered here to try it is
'because it's different.'"  Nobody gave "because it's different" as a reason
to try it.  And I haven't been arguing *why* to try it here, because it was
pretty hashed out in the oldcoop's item 86.  But if we gotta rehash it:
 
  * It gives net-surfers/bbs cruisers a way to more quickly and easily figure
    out what Grex is, try it out, and see if they want an account here
 
  * It reduces the number of once-used accounts (which has various benefits,
    including keeping the passwd file smaller, which speeds up many programs)
 
  * It will alter people's first impressions of Grex, hopefully favorably
 
  * It allows existing users to do some things somewhat anonymously (like
    enter responses) without the need to create second accounts
 
>I haven't seen anybody willing to address the problems jerks might pose
>with this change.
 
  Address in what sort of way?  What are you looking for here?  The guest
account is open to the same problems jerks cause with other accounts.  If
lots of problems occur, the guest account gets shut down.  Addressed enough?
 
>I assume the original reason this solution was offered to us was "to
>make it easier for more people to use grex".  Unfortunately I think
>that's neither especially true nor especially desirable.
 
  My impression is that most people *do* want to make Grex easier for more
people, so this probably isn't a compelling argument for most. And if
anyone's forgotten them, the real original reasons can be read in oldcoop 86.
 
  One more question...Marcus, you said earlier that the board shouldn't "be
just deciding without consulting with the users."  Does that mean you want to
see a membership vote on the matter, more discussion like this followed by
board decision, or something else?

response 63 of 103:

May 21 03:42 UTC 1995

The shadow password code works well only because of a lot of work by
several people - at one point, nearly half of all the entries in the
passwd database were "damaged" in some sense.  I don't think anyone
involved with the effort would describe it is anything other than a lot
of trouble, although, given the popularity of "crack" programs, there's
no question to its value.  The part that is most valuable is probably
not the "shadow" aspect however, but the dbm support & password quality
check.

Mary's recollection of login selection is also misleading.  There was
never any proposal not to let people select their own loginids.  What
was proposed was to "reserve" the loginids of people then on m-net, for
their use first, for a limited period of time (they would have had to
supply their m-net password once, to claim the same loginid here.)  This
would have been done purely as a curtesy to m-net users.  The decision
not to do this was not ours, but m-net's; they turned us down on this.
Fortunately, we didn't have any problems, but that does not mean login
selection is without problems.  Sometimes people do get confused between
loginids on different systems, and we've also had problems with people
grabbing a loginid immediately after it was freed.  There would, in
fact, be value to running a system something like the UofM's "uniqname"
to allow the sharing of a single login space on a first-come first-serve
basis; but I don't think there's nearly enough trust, at this point, to
allow such a system.

response 65 of 103:

Aug 29 05:36 UTC 1995

It wouldn't even be impossible to implement bothe proposals; have "novice"
(or whatever) lead to the tutorial with no 'real' access to party, mail, 
conferences, etc, and have "guest" be fore one-shot uses with NEARLY full
user-but-not-a-member access.

response 67 of 103:

Aug 31 17:51 UTC 1995

   I'm really far behind on reading this item, but I too would
like to see this go forward.  It's a test: maybe it turns out
to be a bad idea; if it is, I think we'll see it and be able
to pull the plug on it rather easily.

response 69 of 103:

Sep 5 11:42 UTC 1995

When I entered that response, I threatened to just go ahead with my
best guess at how to blank out a password without messing up the shadow
password system.  Nobody freaked, but nobody said my suggestion would
work, either.  I don't quite have the guts to risk trashing the password
system to blank out guest's password.  Maybe we can pester Marcus into
helping?

response 71 of 103:

Sep 5 20:24 UTC 1995

That's all I actually wanted for the moment (a guest-changable, blank
password), to test the login algorithm.

response 73 of 103:

Sep 5 20:50 UTC 1995

   Well, thats one way to do it, but that isn't as good as teaching
/bin/passwd about the guest account.