response 25 of 111:

Oct 23 23:35 UTC 1998

If posting a book online would cause a lot of people to access it often, that
does not sound like a good idea, but this is a rather obscure book, about 500K
at the moment without HTML, all text, minimal number of spaces, and it is
related to a conference on fruit growing that I hope to start in January. 
It is not even my book, I am just the typist and would have an easier time
updating it in my own account than somewhere outside of grex.  The way the
author keeps adding more fruits, it might exceed 1M soon, if I can keep up.

response 27 of 111:

Oct 24 06:45 UTC 1998

But why 1 MB? No argument has been offered that 1 MB is the "right"
allocation. Why not 0.5 MB? What test was used to pick the "right" value?
So, why not 2 MB? Wouldn't the "right" allocation change with time, as
needs and resources changed? So the number should be adjusted periodically.
I suggest a step up is desirable because of the dirt-cheaness of disk space,
compared to just a few years ago.

response 29 of 111:

Oct 24 12:00 UTC 1998

I'll disagree, to a point.  *Any* limit is arbitrary, & would be open to the
same complaint.  The falling price of disk may be balanced by growth in the
rate at which new users are added, over the same period.

The way most users operate, 1 MB is really quite a lot of space.  Most people
who run afoul of this limit probably do so through not bothering to clean up.
In the days when mail was the default mailer, people commonly didn't realize
that mail they'd read (but not specifically deleted) went into mbox, where
it sat, growing, forever - just to name one example.  I see *no* virtue in
increasing the amount of just-haven't-thought-about-it clutter.  A policy of
being flexible, allowing those with reasons beyond laziness to ask for a
higher quota, seems reasonable.  If the number of such requests starts to
increase markedly, *that* is the time to discuss raising the general limit.

I'll add that I've been a fairly frequent hasn't-bothered-to-clean-up-lately
offender.  I see it's time I dealt with some old mail right now, in fact.

response 31 of 111:

Oct 26 19:02 UTC 1998

Actually, having more a higher disk quota might very well put more stress on
the link.  I'd imagine there are people who want to bring over some software
package (eggdrop, for example) and don't because it's bigger than 1 MB. 
However, a lot of such packages are smaller than 2 MB, and so more people might
bring over such packages.  Admittidly, it's a bit thin, but it's an idea. 
Regardless, we do not have enough disk space to allow people more than 1 MB of
space.  We could add more disks. Disk is, as  you say, cheap.  However, there
are hidden costs.  The biggest is staff time.  Another is electricity.  I'm
sure more disk space is in the offing, but I probably wouldn't support a bigger
quota. If you have 1.5 MB of mail, how often do you read it all?  I have much
less than that, and I never refer back to 99% of it.

response 33 of 111:

Oct 27 03:05 UTC 1998

   Dan is right -- one thing on Grex usually affects the other, and
disk space does impact link usage.  Disk we can grow, and is getting
cheaper every month.  Link bandwidth is expensive, has not gone down
is price that much, and is rather expensive to grow.

   One technical question is how big a SCSI disk we can put on Grex.
This version of SunOS can only handle 2G partitions, which isn't a
problem, but I have yet to get a definitive answer on Grex using
say a 4G disk and splitting it up into 2 2G partitions.  What I'd
really like is to get one of the slightly older 9G full-height
disks (I've seen them for about $450 lately) and have several 2G
spaces to play with.

   Yes, we need to get more disk.  Ans yes, we should probably
raise the limit, *AND* recognize that local users who use the
dialin lines present a significantly smaller load on Grex than
a user coming in the net link.

response 35 of 111:

Oct 27 13:47 UTC 1998

   Well, if we could disassociate local users from Internet users in terms
of moving data back and forth, I'd agree pretty much.  It's the link that
is our real bottleneck that makes us throttle our disk back.

response 37 of 111:

Oct 28 21:08 UTC 1998

   I'm not sure I understand what you're saying.

   If our remote users didn't shovel vast, endless piles of files into
and out of Grex, we'd have more bandwidth, and we'd be able to deal
with local users having huge amounts of disk, easily.

response 39 of 111:

Oct 29 16:34 UTC 1998

   Thats difficult to do.  There is a concept in many version of UNIX
called quotas, which can limit the disk space that a user can have,
but the quota code on SunOS is not good, and worse yet even if it
worked perfectly it slows disk writes, as each write has to be checked
against the limit for that uid.

   Putting a limit on how much data you could move out of Grex is
almost impossible.  Every method of transporting data, (FTP, all
the x,y,z modem programs, cat, and anything else that could display
data) would have to be taught how to do this.  Sometimes, a seemingly
simple idea like placing limits is next to impossible.  Now, we could
do this, but only at the cost of dampening the freedoms that accounts
here have.  If we restricted things to a meny system, then we could
do this, but change what Grex is.

response 43 of 111:

Nov 2 18:53 UTC 1998

The delete-only option is harsh.  What if someone wanted to make a backup
copy of the file, transfer it, compress it?  It should at least be readable.
In that case, a user could, say, copy the file to /tmp, compress it, remove
the uncompressed version from his home directory, and then, if he had enough
space, he could transfer the compressed version back.  

response 45 of 111:

Nov 3 01:57 UTC 1998

Not when you're doing it, I suppose. You'd want to not be doing it most
of the time.

response 47 of 111:

Nov 3 10:36 UTC 1998

Disk may be cheap, but talk is cheaper.