response 25 of 66:

Oct 4 08:53 UTC 1996

That's the problem with a system anyone can use.  There are a lot of
"anyone"s out there.

There are really only about 3 ways to deal with it.  (1) Invent new
restrictions that users have to pass before they can use the system.
The most common restriction, of course, is $.  But there are plenty of
other "members only" kinds of organizations.  (2) stay the same size,
and become pot bound.  (3) try to grow the system, yet keep the same
feeling.  I think (3) is the most sensible and fair approach.  It
actually preserves the original feeling on grex much better than trying
to stay the same size, and I believe most of the characteristics we all
value on grex are much more scale independent than otherwise.

If we did want to restrict growth in a way that would leave more
capacity for old fashioned plain conferencing, then there are two
changes we could make that would accomplish this most simply: (1)
restrict e-mail to members only.  (2) restrict web pages to members
only.  Hm, and (3) restrict ftp access to members only.  Ok, so it's
three changes.  Still, these three activites consume the most resources
in terms of CPU and net bandwidth on grex, and would result in some
pretty serious paradigm shifting for grex.  Whether that's a desirable
result, of course, is another matter.  It is certainly likely to be more
effective than becoming pot-bound however.

response 27 of 66:

Oct 4 22:50 UTC 1996

Since we are drifiting:  I have this vague concept that grex should 
try somehow to focus its e-mail service to users in its home 
geographical community.  Most of the people who are telnetting here 
from far away are coming from places where they already have e-mail 
access.  And if they are inbound telnet users, then their mail 
jams up our pathetic 28.8K link twice, once when it is delivered to 
Grex and once when they read it.
 
My idea is that users outside of Grex's "local service area," 
however we define that, should have a pretty tight mail quota -- 
tight enough to discourage any mailing list activity.
 
The problem is, how do you handle local telnet users -- say, someone telnetting
from a public access terminal at the library?  Essentially you 
would be saying that "verified" users from the local service area
could be released from the tight mail quota.  Ew.

response 29 of 66:

Oct 5 01:30 UTC 1996

Catriona, you are both right and wrong:  It can be claimed that only those
paying for the privilige should have access to services outside the basic
service grex was created for, which you indicated above was conferencing. 
However, grex was created for another purpose as well, and that was to bring
the internet to those who otherwise could not get/afford it.  The board and
staff of grex have always seen it as part of the main purpose of grex to
provide these services, of which email is one.  So, ethically, anyone can use
email for personal use, because that's part of the purpose of grex.

response 31 of 66:

Oct 5 15:19 UTC 1996

(agreed, but then it was access to unix utilities.  Now, it also access to
internet.)

response 33 of 66:

Oct 5 21:39 UTC 1996

(I didn't know that.  That was before my time. :)  )

response 35 of 66:

Oct 6 14:18 UTC 1996

  A mass-emailing to frequent Grex users is being discussed in the
membership conference.  I agree that it could bring in some cash.
 
  I don't think Grex is all that bad off right now - our income has
close to our expenditures lately.  More money is always nice, but
I wouldn't characterize our current fund-raising as "not producing
the funds needed."
 
  The stamp idea for international users is an interesting idea,
although it holds the same risk as sending cash through the mail -
if it gets lost, the sender is out whatever they sent.  It has an
added risk of getting wet or crumpled, diminishing the value.  If
someone wants to risk sending cash, that's fine, but I'd be
reluctant to actively encourage the practice.

response 37 of 66:

Oct 7 21:07 UTC 1996

One way to moderate the load on the system without changing the nature of
grex very much is to start turning down the "valves" a bit on e-mail, ftp,
telnet, etc.  If file size transfers, number of e-mail messages (and
size), number of telnet connections per day (or whatever) were all given
some limits, two things would happen. First, there would be less load on
the system, and second, users that hog more than their share of resources
would go elsewhere. This would not shift any special privileges to members
while still lightening the loads with no inconvenience to most users. 

response 39 of 66:

Oct 7 23:18 UTC 1996

   The problem with that is making the valves in the first place.
Mail has a valve already, in that users mail storage is limited
to 1M.  More active valves than that for mail would be rather
hard to implement, and worse, easily circumvented since anyone
could take out nn different accounts to get around the limits.
I'm sure there are some who are doing that already, to get around
the 1M mail limit.

   I'd rather see us send the time and energy on things that
will extend our capabilities.  There is a partial solution
for mail, that will involve a much better connected-to-the-net
machine than we are, to "feed" us our mail.  This will be
completely invisable to humans, but will make it such that 
Grex sees one "eternal mail connection" rather than upwards
of 300 of them at once.  This won't be anything like a "cure"
for Grex's speed problems, but it will have a positive impact.
Staff can start actively thinking about this once we've moved.

   And there are other things, too.  Obviously some of them
will require real effort financially, like getting a Sun-4/400
CPU and memory.  Others will require more in the way of
software effort but not much money.

response 41 of 66:

Oct 8 07:14 UTC 1996

it's so easy to follow the logic in #39. but i can't consider it as the
right direction to go, expecially at this time. in the guise of relieving
a burden, it would create a bigger one. 
  
it looks like: take the most burdensome (to the b0x) service that is
most used/abused by non-supporters and open it up even more burden. as
has been demonstrated by each watering for the growing of grex, there is
an incremental improvement for supporers and an opened&filling flood
gate for the rest of the planet.
  
the resource availablilty is repeatedly sucked up by loads almost equal to
the increase of resources. i.e., for every addition of greater resource, 
a very little percentage is realized here.
  
i've also noticed kinda of a slack off on use of the dialins. i would
suspect (can't get at the right files) that if a separation were done
on ttyuse between dialins and telnet thathe higher *percentage* of
use over any 24 hr period would show up decidedly onthe telnet sessions

reinforcing that grex is based primarily on local conferencing with
additional benefits, rather than additional benefits and, by the way,
some conferencing, too, grex might reconsider the gross number of
available telnet ports and decrease the number.

response 43 of 66:

Oct 8 13:47 UTC 1996

   Rane, you are correct that each improvement in Grex's abilities
has resulted in the increased usage of Grex, slowing it back down
again.  However, we can control that, albeit at the cost of some
serious wrangling in coop.

   When we next upgrade the CPU, we don't *have* to increase the
number of users that we can handle at once.  In the past we have
simply because we wanted to provide more access to all our users.
We've hit the point however, where we can't automatially do that
any more.  After we've upgraded the CPU, things will be fairly
faster, but I don't think I'd support any increase in the number
of telneters until we get a faster net link.  When we do that
faster link, whenever and however it happens, we *might* be able
to increase the number of telnet ports, but then again, we might
not.

   Right now, the Grex staff is spread thinly enough that I don't
think we could reasonably deal with a 96 pty Grex (we're currently
at 64).  Staff (or maintence) resources need to be considered along
with CPU and link bandwidth in the future.

   This is something we've never had to deal with before.  Greg
Cronau was the first person to speak of this I believe, and he
was right, although perhaps a little premature.  But we definitely
have to think about resource vs. size issues in the future, which
is something that we just haven't really had to do, before.

   I believe that Grex growing is a good thing basically, but we've
got to really think about how to properly grow Grex i the future.
Personally, I have no problems with the concept of a Grex where
128 telnet sessions are going, *but it will take work*, should we
decide to do that.

response 45 of 66:

Oct 8 20:39 UTC 1996

   Thats certainly a point that staff needs to think about, Ken.
And, you're right about our capacity being exceeded by just that one 
country of India.  We're going to have some exciting times, figuring
out how to grow Grex successfully.   I don't mean that in a negative way,
either: the more challenges we have, the more neat solutions there are,
to be found somehow.

response 47 of 66:

Oct 9 00:05 UTC 1996

Well, we could do that.  We could eliminate a lot more "undesireables"
by blocking out all non-members, too.  

That would be even easier.

response 49 of 66:

Oct 9 00:47 UTC 1996

Ick.  Don't like any of those suggestions.  Ptewy.

(Gone to get something to take the bad taste out of my mouth.)