|
Grex > Coop7 > #41: Subdirectory for "important file finds 'out there'" |  |
|
| Author |
Message |
| 23 new of 47 responses total. |
steve
|
|
response 25 of 47:
| 
May 11 22:25 UTC 1995 |
There is a limit on the number of FTP sessions that can run
concurrently, but I don't know what it is.
|
popcorn
|
|
response 26 of 47:
|
May 11 22:28 UTC 1995 |
This response has been erased.
|
rcurl
|
|
response 27 of 47:
|
May 12 06:34 UTC 1995 |
This is alleviated by have byte transfer limits to go along with
filespace limits. We know our system has limits, and the only fair
thing to do is spread those limits among all users.
|
mdw
|
|
response 28 of 47:
|
May 12 09:14 UTC 1995 |
FTP sessions suck up some of the limited bandwidth that would otherwise
be used for telnet. Actually, that's not quite right - they mostly
don't, but only because the PPP connection discriminates against FTP.
So telnet sessions still mostly work, but FTP doesn't work very well at
all during prime time. We don't impose any relevant limits on FTP
traffic, so our FTP traffic is basically already limited by people's
patience & available bandwidth (and even so, it's used more than you
might think.) I don't think I've ever seen more than about 5 running,
so I think we can safely conclude that's about what the traffic will
bear.
|
dang
|
|
response 29 of 47:
|
May 12 17:38 UTC 1995 |
Yes, but are byte transfer limits in keeping with grex philosophy? That
has been one of the things that I like about grex, that there are no
byte transfer limits. (I don't transfer much of anything, and I like
the lack of archives, but it's the principal.) I personally think that
we should let them FTP it as much as they want, as long as that doesn't
interfere much with telnet. The primary benifit of grex, as far as I am
concerned, is the cfing, so telnets should be given priority. I really
like the idea of a /library.
|
brenda
|
|
response 30 of 47:
|
May 12 18:08 UTC 1995 |
I ftp stuff onto and from grex all the time. I had to go through 3
systems to get a really big file here on grex that I wanted pretty
badly. I would have been upset if I hadn't been able to ftp it all
here.
Mostly, I think people would limit ftp's to and from grex because
it takes a *long* time to ftp even a small file. No sane person is
going to sit there and wait for eons to transfer files they could
find somewhere else.
Maybe it would make more sense to have a list available for ftp of
cool stuff and where to get it. Only problem with that is, we'd need
an official "list maintainer".
|
rcurl
|
|
response 31 of 47:
|
May 12 20:02 UTC 1995 |
There are many limits on Grex. They are perfectly within that "grex
philosophy": time limits on unused accounts, filespace, connect baud rate,
.gifs, etc. The premise of having limits, of course, is to maintain the
system operability for the maximum number of users. *If* ftp transfer
usage got large enough to make a dent in telnet usage - then I think there
is justification for thinking about setting limits. Of course, this also
presupposes that we choose to establish an archive. In the absence of
that, as now, I don't think that file transfer is a large fraction of the
system load.
|
dang
|
|
response 32 of 47:
|
May 14 17:51 UTC 1995 |
Well, if it is necessary for system integrity, then I don't mind, but I
object to arbitrary limits just because it might someday be a problem.
|
nephi
|
|
response 33 of 47:
|
May 15 01:55 UTC 1995 |
Hmm. Everytime I've ftped stuff from here, I usually get a transfer
rate of about .5kbps. Also, I only do this at about 3am.
I really don't think that ftp will cause a problem with bandwidth.
|
tsty
|
|
response 34 of 47:
|
May 15 04:05 UTC 1995 |
Another reality consideration is that, knowing the time-work to
get something into /Library ( i like Caps for subdirectories), there
would be a somewhat self-limiting investment unless something was
really imiportant enough. I consider that the time-work would keep
the /Library trimmed.
|
rcurl
|
|
response 35 of 47:
|
May 15 06:27 UTC 1995 |
Re #33: I can get up to only ca 1400bps over PPP with a nominal
allowed data rate of 56,700bps. So, I set up the ftp and go read
a book for an hour. Grex would be slower, but that just means one
reads another chapter. The bandwidth issue, then, revolves around
how many users are doing this. If there is really "good stuff"
here not available elsewhere, users will spend the time (and bandwidth)
to download.
|
davel
|
|
response 36 of 47:
|
May 15 11:53 UTC 1995 |
TS, why discriminate against users who are caps-lock-challenged?
|
steve
|
|
response 37 of 47:
|
May 15 14:37 UTC 1995 |
Are they any caps-lock challenged anymore?
|
nephi
|
|
response 38 of 47:
|
May 16 06:18 UTC 1995 |
RE #35:
If Grex is in the business of education, and the stuff that we could
potentially have here is so good that people would be willing to wait
an hour to download it, then we are fulfilling our mission. If this
means that fewer people will want to play around in party or in the
conferences, so be it. Grex has always been "The Land of the Patient".
I don't see why you have a problem with it.
|
rcurl
|
|
response 39 of 47:
|
May 16 06:20 UTC 1995 |
I did not say I had any problem with it. I only was pointing out
that the slowness of the link will not in itself discourage use
of an archive, if the archive contains desirable material.
|
tsty
|
|
response 40 of 47:
|
May 16 09:56 UTC 1995 |
treu, in both directions, getting stuff into /Library from "afar,"
and getting stuff out of /Library for d/l.
|
ajax
|
|
response 41 of 47:
|
May 16 15:18 UTC 1995 |
Here's an idea: TS, how about creating a "library" account, which you can
maintain, and people can add or copy things from /u/library? I don't think
that would need any special approval or anything, and you'd be able to set
it up however you see fit.
|
steve
|
|
response 42 of 47:
|
May 16 17:25 UTC 1995 |
Thats not a bad idea, except for the disk problem. I'd hate to
see someone upload something and then have it vaporized.
|
ajax
|
|
response 43 of 47:
|
May 16 18:25 UTC 1995 |
Ok, so also create a "library2" account to mirror library :-).
|
selena
|
|
response 44 of 47:
|
May 17 00:43 UTC 1995 |
Ajax, cool thinking!
|
tsty
|
|
response 45 of 47:
|
May 18 01:06 UTC 1995 |
lemme look at the mechanics and chmod options of a library login as
owner and perhaps a group library. Yes, I could do this with the
realization that it +might+ (but not necessarily) add a level of
bureacracy (which i would abhor).
As steve pointed out in #42 ... that is the problem whether by
disk bug or NetThug.
What I'd like to see, structurally, is that an addition to /Library/n
where n is the topic subdirectory, would be able to be made by
anyone, but nothing could be rm by anyone except root (or login
library).
Maybe there would be a cron job each day (like we +need+ more cron
jobs) that would locate -r files that were NOT .gz files, gzip
them and change ownerships to prevent rm. Actually, someone could
create a file and just +give+ it a .gz suffix, so a simple find wold
not be entirely sufficient by itself.
Does this sound like useful project? Fwiw, there *is* one file awaiting
inclusion ... the entire zip code directory which can be grepped
either for numerical or alpha stuff, or partial stuff.
|
tsty
|
|
response 46 of 47:
|
May 18 01:39 UTC 1995 |
and, i just tested it, the zipcode file at it's original 660K+ size
gzips to a 230K sized file. My position (regardless of how many gigs
of diskspace grex ever gets) is that all /Library files must be gzipped
which would support the cron job with compression and chmod built in.
|
steve
|
|
response 47 of 47:
|
May 18 21:22 UTC 1995 |
I like the structure of /library; that is just like /tmp. I
think there is a sticky bit 'T' or something like that, that does
what we want.
In the beginning, gzipping things makes sense, but if we decided
to get another disk and devote some real space for this, I think we
could store them without compression.
|