|
|
| Author |
Message |
| 25 new of 171 responses total. |
srw
|
|
response 75 of 171:
| 
Dec 30 01:36 UTC 1994 |
You hit a nerve andy. Grex has a history and a culture of openness.
Most of those who are actively participating in this discussion and in
the governance of Grex (including myself) are somewhat dedicated to that,
and will likely feel the same way as robh.
Your question, though, is legitimate. Can we afford to be totally open
to millions of would-be new users?
I believe that we cannot afford to be open to them all, but that limiting
access explicitly is not for us. We are limiting access implicitly,
by limiting the width of the pipe. Thus most of them get disgusted with
the nearly unbearable netlag and go elsewhere. This is not necessarily bad,
but I personally would like to see a bigger pipe (and more growth).
I don't think we have to worry about losing robh, because I don't think
we'll every limit non-members here. If we want to limit growth, we will
do so by limiting our hardware acquisitions.
|
andyv
|
|
response 76 of 171:
|
Dec 30 01:50 UTC 1994 |
Rob saying he would leave if a decision like that were made doesn't improve
the atmosphere here. I would hate to hear that at a board meeting. I don't
understand being dedicated to unlimited nonmember use to the point of making
a system useless. Unless, of course, the dial in users don't experience
the lag time. Then the 16 members who get in from the internet are going
to be numbered with the 90% nonpayers with the choice of going someplace else.
|
srw
|
|
response 77 of 171:
|
Dec 30 01:57 UTC 1994 |
I can't speak for the other board members, but I know the culture here
well enough to guess that you would have a hard time finding board members
who would support the idea of limiting non-member access.
Possibly some members are interested in doing that, but I doubt many are.
|
andyv
|
|
response 78 of 171:
|
Dec 30 02:25 UTC 1994 |
When you say members, you are speaking for the board members probably. I
wonder what the general consensus would be if they knew what the options are.
Do the members want a completely open system with growth being limited by
poor service? What did the members say the last time Grex slowed way down
for a long period of time. And, was the problem blamed on the hardware?
If nothing is done, no big deal to me. It will be interesting to see how
the board handles the changes as they come. I'm learning either way. It
seems that there is an "inner circle." I hope that inner circle doesn't
look for another scapegoat for each new problem. Saying it is hardware
problem every few months will be a way of avoiding the real issue of
not being able to keep up with more growth.
|
cel
|
|
response 79 of 171:
|
Dec 30 03:21 UTC 1994 |
andyv in #73 says:
< I don't see why the paying members should have to suffer
< because of uncontrolled growth and be paying for it with their money.
i'm not even a member, and that makes total sense to me. although,
a counter-argument may be that grex members are really paying for
the co-operative management style and the people who hang out here,
and not for guaranteed system response time.
srw in #77 says:
< you would have a hard time finding board members
< who would support the idea of limiting non-member access.
grex limits non-member access to outbound telnet and ftp. why is
it ok to limit access by non-members to using certain networking
facilities, but it's not ok to limit the number of non-members who are
logged on at any given time? i don't see a difference between the two
limits, especially if the latter limit is temporary.
when there is a limited amount of resource available, certain bounds have
to be placed on the use of that resource. unlimited use is a bad idea:
ask any ecologist. i agree with open-ness, but the grex hardware has
limits -- everyone needs to respect these limits, or no-one will be able
to use the machine.
|
chelsea
|
|
response 80 of 171:
|
Dec 30 03:30 UTC 1994 |
Some of us see Grex's grown as a mixed blessing and something
that will challenge our goals rather than a goal in itself.
Andrew, do you know why Grex was started?
|
mju
|
|
response 81 of 171:
|
Dec 30 06:33 UTC 1994 |
The experiment of having restricted access for nonmembers was tried on
another system here in Ann Arbor, called M-Net. They had, at the time
Grex was started, 13 dialin lines (and no Internet connection). Of
those lines, I believe 1 was for staff use, five were for guest use
(nonpaying users), and the remaining seven were for patron use (system
supporters, to the tune of $150/year). There were other system
resources which were similarly limited (I believe games, for instance,
were restricted to patrons only).
[A note for the historians in the crowd -- Yes, I know that M-Net
really had three levels of support, guest/member/patron. I'm glossing
over that because I don't think it's important to the point I'm trying
to make.]
The result was a heavily stratified system. Patrons tended to be more
active on the system, both simply because they cared more and because
it was easier to log on. If you were a guest, you might have to
attack-dial for in excess of two hours during prime access time to get
on. When the Grex founders were meeting, it was thought that this
sort of access restriction based on monetary donations was bad, since
it would discourage people who (for whatever reason) were not a
supporter of the system from contributing their ideas. In fact, the
restriction of Internet access to members, and the restriction of
other items (such as Usenet posting) to members, has always been
controversial on Grex. I think that these restrictions are necessary
for reasons other than to provide an incentive to join Grex as a
member, and I'm not really sure that I want to open that discussion at
this point.
However, the feeling has been strong that people should support Grex
not because of a carrot dangled in front of their nose, but because
it's the Right Thing To Do. In some ways, Grex was a social
experiment started to see whether this sort of system could thrive
under those conditions. Mary will probably claim that we've already
failed; that the fact we've had to restrict Internet access and Usenet
posting to members is proof that those ideals don't work in the real
world. I'm not sure that she's right, and I don't think I want to see
Grex move further in the direction of fee-for-services and
incentive-based fee structuring.
|
srw
|
|
response 82 of 171:
|
Dec 30 07:15 UTC 1994 |
In answer to Chuck's #79 questioning of my response earlier, I have
campaigned on the platform of limiting non-member use of selected
outgoing tcp/ip services. I want to do this to limit use of the
overloaded link, and to hold out a carrot for membership.
Some other candidates have taken the other position, favoring expansion
of access to services for free when additional bandwidth becomes available.
I'd rather see it go to improve the quality of the connection for those
members and nonmembers using it.
By contrast, I am against limiting incoming telnet access for non-members,
as I feel that such an action bites the hand that feeds us in a way.
We need to encourage participation, and I think such a limitation
would be quite counterproductive to that end.
Unlike the founders Marc refers to as feeling that people will join
because it is the right thing to do, I feel that only a small percentage
will do that. I am not as idealistic as that. I came along after the founders,
and while I have a deep respect for what they have done, I am not afraid
to try to improve things by changing them.
I see our membership dues as a donation with associated benefits. I do not
like to use the term 'fee for services', because that implies that we are
selling something, like we would have to refund their money if the net link
went down. We are only selling ourselves, IMO. Others disagree, some strongly.
|
mju
|
|
response 83 of 171:
|
Dec 30 07:38 UTC 1994 |
(Note that when I say "the Grex founders thought that..." or
"the Grex founders did this...", it is of course solely *my*
interpretation, as one of the people who was at the meetings.
No one person can speak for all twelve of us.)
|
rcurl
|
|
response 84 of 171:
|
Dec 30 07:41 UTC 1994 |
The question of how to put some "brakes" on the system, so that it functions
at least reasonab ly well, has become quite vexing, since the internet link
was opened. Before that, with just dialins, members and non-members had
exactly the same access and privileges. With the internet link, it was
obvious (and confirmed by all the inquiries we receive) that having
wide open telent access *and* also outgoing telnet, would attract so many
users, the system would sink under the load. It would also not meet our
obligations to oversee the proper use of the internet, which is our
responsibility too. The immediate and simple solution was to limit a narrow
suite of "services" to those that support the system with donations -
the members. This has clearly curbed the growth in demand on system
resources, but does not accord with the original philosophy. The problem
is, how can the moderated curbs on system use, to maintain functionality,
be fairly distributed across all users, as was the case before the
internet link? I think we need fresh ideas on how to do this. Some
universal "curbs" that might contribute to this would be the filespace
limits (agreed to, but not implemented); limits on bytes transferred
(u/l, d/l and e-mail, etc) per time period; and other such limits that
can be fairly administered for all.
|
andyv
|
|
response 85 of 171:
|
Dec 30 18:35 UTC 1994 |
Mary, if you are asking me if I have read the constitution, yes I have.
|
andyv
|
|
response 86 of 171:
|
Dec 30 19:04 UTC 1994 |
I just checked again and there is no mention of a committment to quality.
Like a soup kitchen committed to feeding the poor which agrees to feed
everyone even if it is only a tablespoon each. Would that kind of
operation be considered successful? (please don't debate the analogy's
appropriaeness but deal with the gist of it as it applies to Grex).
|
chelsea
|
|
response 87 of 171:
|
Dec 30 20:13 UTC 1994 |
Cool, Grex has a constitution? Where'd ya find it? Sounds
interesting.
|
andyv
|
|
response 88 of 171:
|
Dec 30 20:37 UTC 1994 |
Sorry for my ignorance again, Mary, I should have said the bylaws and articles
of incorporation.
|
davel
|
|
response 89 of 171:
|
Dec 30 21:18 UTC 1994 |
Andy, I don't know what you mean in separating the analogy's appropriateness
from "the gist of it as it applies to Grex". And to answer your statement
way back in # 78, I'm not sure whether Steve's last line in # 77 referred
only to board members, but I suspect not. But let me make a different
point: I'm fairly sure that if Grex were to go very far in the direction
of access limitations of the kind you're proposing, a *lot* of the members
(and non-member users) who are most active & who, frankly, keep the ball
in the air are likely to become pretty scarce.
I wasn't around when Grex was being started, & I'm not myself entirely
in sympathy with all the objectives those starting it had; but in any
volunteer-run organization you tinker with organizational culture at
significant risk of killing the whole thing.
That's not to say that no changes are needed, or that any suggestions
should be ruled out a priori, without being considered at all. But I
honestly think that access restrictions along the lines you're suggesting
would be fatal to this system.
|
srw
|
|
response 90 of 171:
|
Dec 30 21:35 UTC 1994 |
What Dave said.
Sorry for the confusion about my last line in 77, it refers to members
meaning members of Grex, not just the board (which is the previous paragraph).
|
cel
|
|
response 91 of 171:
|
Dec 30 22:17 UTC 1994 |
one simple way of fairly spreading the system's load limit among members
and non-members is to reduce the number of pseudo-ttys. that would limit
the number of concurrent incoming telnet users. use a single-threaded
ftp daemon to limit the number of inbound ftp sessions. as the internet
bandwidth situation improves, add more ttys, and increase the allowable
number of concurrent ftp sessions.
using mechanisms such as these would help make grex more usable until
better hardware resources become affordable and there is staff time
to consider them and install them. there is obviously an important
process of thinking about and choosing among alternatives that takes
time -- meanwhile, members and non-members are complaining that service
sux and nothing is ever done about it. (sounds like the university, eh? :-)
successfully running a service like grex means the staff will architect
the system with artificial limits so that they can keep up with growth
and add new resources before real limits are reached. this is definately
a policy issue, but i think it is also a planning philosophy, which is
why i mention it here.
|
robh
|
|
response 92 of 171:
|
Dec 30 23:48 UTC 1994 |
Well, I wouldn't worry about incoming ftp, since nobody seems to be
able to get that to work these days. >8(
I was going to go into more detail on why I felt imposing
restrictions on non-members was "yucky", but mju and the
others have summed it up beautifully.
|
andyv
|
|
response 93 of 171:
|
Dec 31 00:25 UTC 1994 |
I guess the discussion is revolving around the definition of "open access."
Is open access the same as unlimited access? I don't think so. I think
a balance has to struck between unlimited access and quality of service.
I am making suggestions to try to get more input. If anyone is reading
this, I think the readers are starting to get an idea of the situation.
I am getting the idea that if the membership or some future board were to
decide to go in a direction other than the one held by a few key people
Grex's existence would be in jeopardy.
|
robh
|
|
response 94 of 171:
|
Dec 31 00:39 UTC 1994 |
Well, I don't agree with your opinion on unlimited vs. free
access, but you'd probably guessed that. >8)
I think Grex has always been in a position where if a few people
left, it would be in big trouble. I personally would like to
set up some kind of mini-course on Sun hardware, so if something
happened to our technical staff, we wouldn't be up a creek.
Maybe after the move, when access is easier?
|
andyv
|
|
response 95 of 171:
|
Dec 31 00:58 UTC 1994 |
Rob, I am at a loss to know what is meant by open access. I think
unlimited access is much easier to understand. Open access seems to
indicate equal access according to some folks. To others the open
means unlimited access to certain services.
I don't hear much discussion on the quality issue. Can and should a
balance be struck? I haven't formed an opinion other than, a system
which performs poorly isn't that good of a public service.
I better go back an read what I'v written to see if I agree with me ;-)
|
danr
|
|
response 96 of 171:
|
Dec 31 02:35 UTC 1994 |
I don't think we need to impose restrictions on non-members, but
limiting the number of pseudo ttys, as cel suggests, might be a good
idea. Sometimes, I think we take the concept of "openness" too far.
|
andyv
|
|
response 97 of 171:
|
Dec 31 03:05 UTC 1994 |
Translation please. Will doing the above (which I don't understand) insure
the quality of the operation for those who do login?
|
kentn
|
|
response 98 of 171:
|
Dec 31 04:22 UTC 1994 |
Limiting the number of ptys, as suggested, amounts to having a limited
number of dialin modem lines. The more people that are able to login,
the more mail messages that get sent, the more compiling gets done,
the more times bbs is run, etc., all basically simultaneously, which
slows the system down for everyone. If by quality you mean faster
response to your commands, then by having fewer people logged in at
any time, we'll have faster response--this won't affect any delays
caused by the system(s) outside Grex. If by quality you mean being
able to login first time you try every time you try, having less ptys
will aggravate the "no ptys available" problem (analogous to a busy
signal when dialing in). We already have a limited number of ptys, BTW.
At least, that's how I interpret the situation.
|
steve
|
|
response 99 of 171:
|
Dec 31 05:20 UTC 1994 |
Unforunately, limiting the number of ptys won't really fix the problem.
This is because lots of other things run over that pipe at the same time,
and sometimes, those things are what kills us for minutes at a stretch.
For example, I was watching the system when 11 sites attached to us to
feed us pieces of mail. As I had to telnets to Grex at the time, I
wrote a small program to print out the time and 70 "*" characters and a
CRLF. I could watch the programs output crawl to something less than 200
bps (20 characters, I should say) while the mail-attack was going on.
After 5 minutes, the load started decreasing, and after 15 things were
pretty much back to normal. But, during that time there was the equivelant
of many people on, as demonstrated by my test telnet.
So, we could restrict the number of allowed telnet sessions on, but
what would the right number be? I don't really know, myself. And if
we're running close to 48 (48!) telnet sessions at times during the
evening, then cutting the number of ptys to say 32 is going to impact a
lot of people.
Thats why I think we should be thinking in terms of how to grow our
little pipe rather than figure out ways of restricting the number of
people on Grex.
|