Lately Grex has developed a new class of users -- web-page builders.  We
seem to have a good number of users who log in here only to create and
maintain a web page.

This seems to me to be very much the kind of activity that uses Grex
resources, while contributing very little to the Grex community.

I should note that I have talked to some who seemed eager to send in money
to Grex.  I doubt if they contribute less than other users in the financial
sense.

Certainly we want to continue to allow people to create web-pages, but some
of these can be rather resource intensive, much more so than the users who
only log in to read and send mail.

I have mixed feelings about this, and no idea whatsoever what, if anything,
should be done about it.  I thought collecting opinions and ideas might
be useful.  That's what this item is for.

382 responses total.

  Is there any chance that with new SUN equipment, there can be .gifs
and graphics on the homepages or would they still take up too much space?

I have mixed feelings as well about web pages because most seem to be
geared as much toward vanity and self promotion as toward a legitimate
desire to share one's interests.

I guess one reason people might want their grex logins iimmortalized
in the case of their death, is so their homepage will be out there
outliving them.  A few decades from now, we'll be running into a lot of
dead peoddead people's web pages without even knowing it!

  More important than the space images take up, I think, is the portion
of Grex's Internet bandwidth they take when people access them.  I don't
know where packets from http servers are prioritized relative to other
Internet services, but with a 28.8k link, either the web pages with
graphics would be almost unusably slow, or if they got adequate priority,
then Grex's telnet or mail transmissions might become unusably slow.  
 
  Jan, can you give more info on "some of these can be rather resource
intensive?"  Like, what resources?  With graphics and CGI scripts disabled,
it seems like just text pages would be undemanding.  But depending on the
web server software, and frequency of access, I guess they could be.

This question is part of the larger question of how Grex should allocate
its limited resources, or even *if* Grex should implement any allocation.
We already suppress .gifs, and maybe it will be the turn of homepages
next. I think that an "item by item" approach will be both very time
consuming as well as inherently unfair. I propose that we consider
implementing limits on *resource use*, as represented by filespace, file
transfer (including reading homepages), and on-Grex activities. What the
resource use is for, as long as its legal, should be of much less concern. 

However there is a further question of how Grex wants to allocate its
resources. We say we are a conferencing system, but I don't think that is
the primary consumer of resources. Like Jan, I also think that the uses to
which Grex are put should include, to some extent, activities by each user
that "contribute to the Grex community", as well as others that meet the
individual wants of the users. This could be approached by deciding the
"rankings" of Grex uses with respect to its contribution to the Grex
community, and then apply *weights* to the resource limits. If all the
weights are equal, then we just have resource limits. However if the
weight on .gif transfer, or a homepage (as examples - no immediate
judgement of prospective weights are implied) is set higher, those uses
would count more heavily against the users limits. 

Is this a type of approach that would both retain the freedom that Grex
offers and respond to Grex's limited resources? 

How resource intensive they are depends on the size and amount of traffic.
I spoke to one person who wanted to set up a site for various Olde English
manuscripts (Beowulfe and stuff like that).  He was very willing to try
to keep things small and expressed interest in donating money, plus it
sounded like kind of a neat project, but things of that sort could potentially
be a non-trival load. GIFs aren't the only big files in the world.

Exactly. A file-transfer limit would constrain both uses equally.

I'm not sure our gif blocks are working right.

Re 2: telnet and the interactive parts of ftp sessions get high priority
in tcp/ip.  Everything else gets low priority, including http.

In fact, the low priority that http gets causes it to fail to work 
when the interactive load gets too high. It slows down to 0, and
then the clients time out, thinking the server is down.

Because http traffic doesn't influence telnet traffic very greatly,
I think the use of large files is self-limiting. I personally am
not convinced that we need to be blocking gif files, but that is
our policy at present.

Given the open nature of our system, I think it is reasonable to
allow users to have web pages, despite failing to contribute to
Grex in any other way. We could restrict it to members only,
then it might generate revenue for the treasury.

http service will never be acceptably fast unless we can upgrade our link
to a faster speed, and even then it probably still won't be quite
"acceptable".

This comes down to the old question of what, exactly, Grex is for.  Certainly
we are a conferencing system, but the wonderful thing about Grex, to me, has
always been that we were more than that.  To those who have had access to fast
computers with fast Internet connections, Grex may not be much more than just
a conferencing system, but for those who don't have that kind of resources
Grex can be useful for a lot more.

When I first got on Grex, it certainly wasn't for the conferences.  I had seen
discussion areas, which I guess could have been called conferences, on other
local BBSs, and they hadn't impressed me.  I started Grexing because I heard
that there was this free system that I could get to by calling 761-3000 that
I could use for Internet e-mail.  As a high school student in the days, just
a few years ago, when high schools weren't providing e-mail to their students,
that was something I couldn't get anywhere else, so Grex was a great resource.
Once I started using Grex for mail, I also started playing around with the
Unix shell a bit, and combining the free shell access I had on Grex with a
Unix book I bought was able to learn a fair amount about Unix.  Several months
later I discovered the conferences, and started using them too.  Like
everything else I had found on Grex, they too were a cool thing to play with.
Now conferences and party are pretty much all I do on Grex, because I have
better access in other places, but I'm sure there are other people out there
in the same situation I was in a little more than three years ago when I first
discovered Grex.

That said, conferences and party are a big part of Grex, and as Grex's
discussion areas they are the things that really keeps Grex's "community"
together.  I don't think we want to do anything to make those two parts of
Grex any slower than they have to be.  Still, we have to consider that they
may not be all that Grex should be.

It all comes down to what kind of limits we want to put on things.  We
certainly don't have the bandwidth for big gifs, and probably not even for
little gifs, so when we figure out a good way of technically blocking those,
we should definitely do it.  In the mean time, we should discourage them. 
With text, OTOH, it really doesn't take up any more bandwidth than any of the
other text leaving Grex, and those who can't afford to pay an ISP to hold
their homepage, or don't consider it worth what ISPs charge, still can benifit
quite a bit from having an outlet for their creativity.  Like it or not, one
of the things that Grex does best is to educate people, in lots of different
was.  One of those ways is by letting them write a lot, for an audience rather
than just for a teacher.  Letting people put up a text only homepage is an
excellent way of doing that.  So is having conferences.

(srw slipped in)

  Jan, your point about text files also being big is taken.  But I'm
interested in whether your concern is due to web pages *currently*
using a large chunk of any of Grex's resources (and if so, which), or
due to its creating a potential problem in the future?  Good question
either way, but my opinion would be swayed if I found out half our
Internet bandwidth is eaten by http traffic!  :-)  I would *think*
srw's "self-limiting" theory would keep it low, but you never know.

I want to note something here. Srw and I got into a small disagreement about
http in the staff conference. Steve, you made the comment that "http is
not an inefficiant protocol". I agree, I never said the http protocol
itself was inefficiant. My assertion, is that the Web paradigm *encourages*
a style of programming that is inefficiant.

I've seen web pages that could have been encoded with 5 highlighted pieces
of text that say essentially "click me", but instead the user chose to
make each of those buttons a 20K gif file that says "Click Me" in 256 colors
with nifty graphics.

The paradigm encourages extravagance, and that extravagance devours net
bandwidth.

gregc has hit the nail on the head, IMHO.  Every time I visit
my parents' house and use their super-duper Pentium to connect
to CompuServer and run Mosaic, I'm constantly underimpressed
with what the Web looks like.  From here, on Lynx, either a page
has lots of text (great) or lots of [INLINE] markers and nothing
else (no problem, I never visit there again).  But I get on
with Mosaic, I sit there for five minutes waiting for an image to
download, and it's a button that says "click here" or "go back"
or "send mail".  Did I really need to spend five minutes on-line
for "click here"?  (Which, in Lynx, wouldn't have taken five seconds
to download?)

I still love the Web, but I will never understand the desire for
huge pointless pictures.  I outgrew pretty pictures in books when I was
five years old, and as far as I'm concerned, anyone who NEEDS
images to make their home page good is a five-year-old.

I'd like to see Grex provide a Web presence for those who can't
shell out the bucks for a glitzy page somewhere else, but I
don't think we should sacrifice our bandwidth to let people
get glitzy here.

Re 10: At some point Marcus collected some statistics about how much
of Grex's net bandwidth was being taken up by the very small number of
graphical files that were on people's web pages.  I don't remember the exact
numbers, but they were surprisingly large.  That was when he added the blocks
to httpd to prevent people from using graphics on Grex.

Robh said:
> I still love the Web, but I will never understand the desire for
> huge pointless pictures.  I outgrew pretty pictures in books when I was
> five years old, and as far as I'm concerned, anyone who NEEDS
> images to make their home page good is a five-year-old.

While I think the web encourages extravagance, I won't go as far as the
above analysis. I think it's obvious why alot of people do it. Computers
in general and the Internet in particular, have been hemmed in by a text-
only interface for most of their existance. It's only recently that graphics
started to become do-able. For many years, people have had graphically
oriented information that they wanted to display, but had to resort to crude
ascii-graphics(of which we have alot on Grex BTW), or rely on proprietary,
incompatable, graphics exchange methods. Now, along comes the web, with a
standardized methodology for passing graphics around, and people who have been
frustrated all these years, are going alittle crazy. I think it's a fad, once
the novelty wears off and people get tired of waitng for 5 minute web page
loads, you'll see the graphics disappear from the glitz-only locations and
only be used where they are necasary.

I agree. My amazement with glitzy graphics has already gone stale.

...but to bring this back to whether or not we should encourage personal web
pages.

My opinion is that personal web pages are fine, but that there should be some
limit as to how many bytes that web page can contain.  I don't know exactly
what that number is, maybe 100 kbytes, maybe 250 kbytes.

I also think that we should not allow users to set up web pages for
commercial purposes.

Grex allows advertising for comercial purposes.  I've also sent e-mail
via this system for comercial purposes.  I like the idea of limiting the
size of the web page though.

This is interesting cause netmeg has like unlimited space for web pages
at the moment.  Maybe we can set something up.

Re 16 - I hope we don't make the limit 100kb, I'm already over that.
With nothing but text!  >8)

Re 14 - Well, I'm not saying that I think all graphics suck.
There are a few sites I can remember that I really
enojyed viewing graphically via Mosaic.  Curiously, those
were the pages that looked really great in Lynx, too.
When someone puts effort into making their pages look
good under multiple platforms, it shows.

You have to remember, though, being both the Webmaster and a
helper, I'm constantly bombarded with users begging and
pleading to let them have graphics here, because without
graphics their pages are going to suck, and they don't know
what they can do.  (Hmm, maybe shell out the whole $2 a month
for a Web site on one of the low-cost providers I keep seeing
ads for on Usenet?  Naaaaaaah...)

I was going to say that I didn't see how anyone could make a homepage
worth reading over ca. 10kB  8^?. I constructed one for mnac that
seems too long - at 5kB. I fear to read your's, Rob B^].

The term "homepage" seems to be used in two different ways--
as a person's "main" document, or as the whole collection of
web-accessible documents that they keep in their directory.
One 100kb document would be a bit excessive, but a collection
of smaller documents whose size totals to 100kb is a different
story, and the latter is what Rob has.

And as far as size limits are concerned--there's a disk quota
(don't remember exactly what it is, but I believe it's at least
a megabyte) that we suggest users limit themselves to. Should
we care about how much space a person's web pages use as long
as their total file space stays within the limit?

I generally use the phrase "Web-space" to refer to all the Web-
accessible documents a user has.

I'm not sure about the inividual file sizes, though.  Is it
harder for Grex to send one 100kb document, or twenty 5kb
documents?

With a 100kb document, Grex will download the whole 100kb on
every access unless the user aborts the transfer. With twenty
5kb documents, it'll only download 5kb at a time, and most
users will probably access only a subset of the documents.
So a collection of small documents is apt to be less of a
burden on the bandwidth than one big document.

Re commercial pages on Grex: Commercial pages tend to get a *lot* more hits
than personal pages.  I mean, compare the traffic to the Coca Coal web page
to the traffic that Joe Blow from Idaho's web page gets.  Because of the
traffic, I could see us not wanting commercial web pages on Grex.

I halfway agree.  I'm concerned about the inevitable crises about what's
commercial, say, when Mary posts an announcement of her neighbor's garage
sale with tons of old & maybe rare LPs?  Having such a rule is going to
require an enforcement mechanism, and that's going to mean someone's having
to pass judgment *at least* whenever someone complains ... and if *only* when
someone complains, then those who we clamp down on are likely to complain
(rightly) that they're being singled out.  I hate the thought of the extra
link traffic, but I *really* hate the management job this involves.

We probably have the capability to keep track of how many bytes of data was
sent due to hits on any particular user's web page.  If that gets to be
excessive for some user (where our notion of excessive might be tempered by
whether the user is a member), we might start sending the person mail
asking him to seek a new home.

That's not a real formal policy, but it's more or less the way we handle
things with mail.

It might be good to write some guidelines for Grex web pages:
   - no pictures stored on Grex.
   - total file space less than whatever.
   - Try to do many small pages rather than single large pages.
   - If you really have a lot of traffic, we recommend you talk to...
etc.

I prefer to specify some numerical limits (filespace, bytes transferred,
etc), with of course the capability to permit more by jusitifed request,
because it requires less management time and helps prevents inequities.
I would particularly not want to give members a higher maximum than
non-members, unless we adopt a policy to that effect. We should not have
any hidden resource "perks" for members. 

Re 25 - Yes, but what do you think the odds are that
the Coca-Cola Corporation would *want* a Web page here?  >8)
I would assume that anyone who was willing to set up
a commercial Web page on a system that didn't allow graphics
or CGI at all would be pretty desperate, and probably not
have a lot of money.

I'm not sure I like the idea of limiting how many accesses
a single user can have to their Web space here, or how
much bandwidth they can use, etc., just because that's not
something a user can control easily.  Let's say that people
are accessing my pages "too often", and the other staffers
tell me about this.  What am I supposed to do about it?
I can't control how many people try to access my pages.
What, I should scatter a few hundred typoes all over the
place and hope it drives people away?  Put in lots of
obscenities?  (That might attract even more accesses...  >8)

  In that situation, you could pay $2/mo to one of the organizations
you suggest, and change the links in your primary web page to that
site.  I don't see a need for web disk quotas beyond normal disk
quotas, nor for web bandwidth/access quotas until or unless there is
evidence they're using a sizable chunk of Grex's resources.  But *if*
that happens, users (including those using Grex for profit) are able
to move their pages elsewhere if they want to keep them available.

Re #11 - Greg and I seem to agree about the issues of efficiency and
extravagance. I am going to back away (a bit) from some of my claims that http
shuts down too often due to link traffic. I believe it used to do that
much more than it seems to do any more. I am inclined to  believe that
the recent changes to the packet fragmenting parameters
have resolved much of the problem and made the link
more efficient. Http usage has been improved a bit because of this.
It is still extraordinarily slow when the link is busy, and that is by design.

The big disagreement Greg and I seem to have is over the value of 
bringing a web-based front end to conferencing. I am not talking about
an extravagant or glitzy thing. I can do it with no graphics at all.
I believe it will allow the power of picospan to reach users who would 
not otherwise find it.  I also believe that this would be a good thing.

Actually, no. That issue is merely a matter of opinion, and you might 
actually convince me otherwise if you can come up with a neat design.

Our area of "big disagreement" was over your idea of making http packets
high priority. That is simply wrong. If everyone on the system voted
to do it, it would still be wrong. Like the apochyphal story of some
southern states legislature voting to change "pi" to "3" so it would be
easier to deal with, there are certain things you can't vote into "rightness".

Re 30 -Rob, that's a silly policy idea as it stands, and I'll
illustrate why:  (one of the few advantages of working at Meijer,
my brain is free to come up with bizarre scenarios like this)

Let's say that I'm a hacker-type who's royally ticked off at
janc because he's fixed the bug in party that let people read
private channels.  How do I take my revenge upon him?  Simple.
I go to another system, whip up a small shell script that accesses
janc's page, oh, ten thousand times, and sit back and let
it run.

At which point I have to tell janc that he can't have his pages
here on Grex any more, because he's generating too much traffic.
Does this make any kind of sense?  Do we really need to encourage
yet another potential hacker problem?  Especially one that
will take up huge amounts of bandwidth?

"But they can do that now", I hear you say.  Yes, but if they do
it now we won't reward them by removing the other user's pages.

"Well, if we know it's a hacker-type we won't do anything."
Do you want to be the one sorting through the entire log file
trying to figure out if a page is being "attacked" or not?
I think I have better things to do than play forensic analyst.

(And the sad thing is, I can't afford another $2 a month for
computer access, and would probably have to deperm all of my
Web space if that happened.)

I really do not understand why we want to punish users for
having comparatively popular pages.

  I've already stated my opposition to web quotas at this point, in
case that wasn't clear, but to answer your last paragraph....
 
  Same reason we "punish" users for having graphical web pages, for
having a large mail spool, or for using a lot of disk space - to
keep the system working alright for the rest of our users.  Given
Grex's limited resources, we've prioritized what's important to us.
 
  If it comes down to it, if http traffic starts interfering with
e-mail delivery, you can guess which will be deemed more important.
Among possible solutions would be limiting busy pages, as we plan
to limit big mail spools.  Once mail quotas are in place, malicious
users will also be able to flood your mailbox (I think?).
 
  You raise a good point if web access quotas are ever seriously
considered, though I don't think it invalidates the idea.  An attempt
at detection of such "sabotage" could be made.  But hopefully there
won't be a need for such quotas anyway.

It makes no sense IMHO to say set limits (for example 100KB storage for
web space, home directory disk quotas at 1MB, or some amount of http
traffic generated) on the computing resources any one grex user is
entitled to use.  The problem is that any person who wants to increase
his/her allocation needs only to run newuser and create new accounts.  It
is trivial to link my web pages to my alter-ego's web pages.  

Such limits per account will deter the casual resource hog, but they will
soak up time and effort of both serious resource hogs and staff trying to
fight them which might have more productive uses.

I think that given free nature of grex, the best limitation on people's
web usage should be the user's own patients.  Leave http traffic with a
lower priority than other interactive traffic and if http seems too slow
for any user, that user will stop using it and there will be more
bandwidth for the patient ones.

Exactly what I say.

Re 34 - But there is clearly a difference between accesses
on a Web page and the size/contents of the page.  The user
can control how big his/her page is, and can choose not to
include huge pictures files.  (On Grex, their choice doesn't
really enter into it, or course.)  But a user cannot control
what other users at other Internet sites do.

<with serious trepedation, I ask> If you had the hardware and the connectivity
would the above (all of the above) be an issue? Where should the effort
be concentrated?

If we had a T3 connection and a lot more CPU, then none of
this would be much of an issue, no.  This is the problem
with overpopulation, more and more people are trying to use
the same resources.  Of course, if some of those people
became members...

Actually, no adbarr and robh, use grows to fill the available disk space,
CPU and net bandwidth. If we had an 8 processor Sparc 20 and a T3 connection
that together would support 600 simultaineous users, we would grow until
he *had* 600 simultaineous users. And the system would be as slow as it
is now. (And if you thought agora was a problem now......)

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss