remmers
|
|
response 50 of 57:
| 
Dec 7 00:45 UTC 1998 |
I fired up Grex's mighty online search engine (otherwise known as
"grep") and managed to track down the online discussion on opening
up http. It's in Coop 7, Item 93 (item:coop7,93). The reasoning
presented there for doing so was essentially as Steve recollects
it in resp:48.
The feeling seems to have been that board ratification would be
sufficent, and there was mention of bringing the issue to a board
meeting, but that apparently never happened. There's nothing on
it in the agenda item for that month's board meeting (item:coop7,102)
or the minutes (item:coop7,107). So that step evidently just got
forgotten, until now.
(I do recommend reading the agenda item -- Coop 7, item 102 -- for
its entertainment value. It goes on for 93 responses, most of them
having to do with the concept and propriety of the board having
pre-meeting dinners. Amazing stuff. I'd totally forgotten the
discussion ever took place.)
|
rtg
|
|
response 51 of 57:
|
Dec 11 04:40 UTC 1998 |
As I read this whole discussion, I find myself boiling it down to a single
question: What is the maximum level of service we can provide with the
limited resources we have available?
In the light of this, and the general feeling that our internet connection
bandwidth is the single most limiting factor, I ask why we allow ANY
protocols to pass twice over that link? It seems ridiculous to me for
anybody to be using telnet to come into grex, and then expect to go back
out the same link with http or ftp or whatever.
We are here to serve as a community bulletin board, and as an educational
resource. To me, this means that we provide our local services such as
bbs, party, and the tools necessary to write and compile simple programs
so that people can get an idea of how these magic boxes work. As a
service to our geographical community, we provide dialups, email, lynx,
and possibly telnet access to other systems.
I have made the assumption that if a user has the capability to run a
telnet client to access our locally-provided services, then they also have
the capability to run lynx or ftp locally, so it's a waste of our cpu and
especially bandwidth to run them here.
There are lots of people who share internet access with family members, or
have their only internet access at work, so I see us providing a real
service to allow our 'remote' users to receive e-mail here. (aside: What
is the total cumulative data flow for a POP3 session downloading n
messages, vs a telnet session running pine, paging through the same
messages slowly? Would POP3 allow us to serve more users more
efficiently?)
The other protocols they can run themselves, so why do we allow them to
telnet in, then surf from here?
I would support a proposal to broaden the access we allow to dialin
local users, whether they are paying members or not, and severely restrict
the use of any outgoing protocols by remote telnet users, whether they are
paying members or not.
I guess I'm making the assumption that if someone comes here to do
something they could just as easily do at home, then they must be up to no
good, and they're trying to hide behind us.
|
davel
|
|
response 53 of 57:
|
Dec 11 12:17 UTC 1998 |
As to why someone might reasonably telnet in & then access the web, consider
me. If I am telnetted in to Grex, it's from a shell account at work. From
that system (and in fact from anywhere) I do not have an ISP account providing
web access. Coming in from work I'm most likely (not always, but usually)
on to get some kind of information for my job. I may find something that has
a URL in it. I can run lynx as well from work, but not while I'm telnetted
in to Grex. (In principle I can suspend the telnet session, but in practice,
when I'm telnetted to Grex in particular, that usually means my connection
will be hung when I get back to it, for some reason.)
|