|
Grex > Coop11 > #140: Grex in the new millenium-- should it be web based? | |
|
| Author |
Message |
| 25 new of 91 responses total. |
orinoco
|
|
response 55 of 91:
|
Dec 7 22:43 UTC 1999 |
It doesn't take much to get comfortable with a web-type interface; it takes
a good while for someone who doesn't use computers much to get comfortable
with command-line. Someone who _needs_ to dial in because they dont' have
an isp is probably not terribly familiar with computers, and giving people
like that access to the backtalk interface might be nice.
|
pfv
|
|
response 56 of 91:
|
Dec 7 22:52 UTC 1999 |
sure, it might.. I don't fault that..
OTOH, ISP's - particularly with "limited access" are not all that
costly.
If this is a desired state of affairs, why not also consider
acting as an X-server for remote users? Typically, this is
considered too costly in bandwidth - and offering "ppp" is
certainly going to be more "costly" than what is now experienced.
|
other
|
|
response 57 of 91:
|
Dec 7 22:57 UTC 1999 |
re resp:54
why would you be opposed to lowering the "curb?" who are you afraid might
be able to get over a lowered curb, and what are you afraid they will do?
|
pfv
|
|
response 58 of 91:
|
Dec 7 23:31 UTC 1999 |
This response has been erased.
|
gull
|
|
response 59 of 91:
|
Dec 7 23:53 UTC 1999 |
Actually, I doubt the additional bandwidth would be much. I forget how many
phone lines we have...ten, is it? So it'd be no worse, bandwidth wise, than
having 10 new Backtalk users over the 'net. I think the CPU impact would be
minimal. If our terminal server can do PPP, or if we dedicated a low-end
desktop machine to the task, the additional CPU load on grex would be
essentially nil, in fact.
Of course, before we start thinking about that, we need to take care of more
immediate problems, such as disk space. (And before you start, pfv, even if
we removed every copy of eggdrop, every night, we'd still run out of space.
The easiest and best way to fix the problem is to simply add more disk.)
|
pfv
|
|
response 60 of 91:
|
Dec 8 00:18 UTC 1999 |
I won't "start" - eggdrop has been reduced and I admitted that
motnhs ago. OTOH, I've seen and tel'd at least 2 people per day
for a WEEK, regarding icq, eggdrop and bnc compiles.
Yer right though: it's not exclusive to those, however quota's
would prolly help.. As would a low-lvel background-task to reap
those files - perhaps accounts - that keep trying. No joke: the
clowns I spoke to insisted 'newuser' had nothing to say about such
things.. I downloaded the newuser.info stuff: I almost agree -
it's buried amidst a few tons of total crap: it's seriously time
for a rewrite.
OTOH, the very idea of "throwing money (or space) at a problem" is
far and away too republican for me to credit the grexies
suggesting it: it doesn't do a thing to resolve the "issues" (and
they must exist, or the "problem" wouldn't) causing the bottomline
shortages.
As an aside-sorta' thing.. I find it interesting that "update" is
typically run during stateside business-hours, rather than
"stateside downtime" - and I don't belive I've seen a "slow-time"
reaper running at all - reaping the "trouble files". Instead, we
hear of STeve and such cleaning these out "on demand".
If such are not a problem, not even human-intervention is
required. If it IS a problem, why pretend it isn't? Further, why
try to solve these non-problems during CONUS "hours-of-operation"
and manually to boot??
Myself? no problem - I can certainly use space as fast as the
wabbits or whatever is chewing space - I can't determine this, as
I ain't root - although, it certainly won't be with useless porn
images or irc-crappola, teardriops and what have you.. Please do
install that disk: at the least, my partfiles wouldn't get creamed
as often..
|
spooked
|
|
response 61 of 91:
|
Dec 8 02:01 UTC 1999 |
pfv: rewrite the textual documentation as you would have it in newuser. Staff
will take it on board.
Also, write the background background reaper program, and we will look at it.
Nothing is stopping you. Ultimately, we have to be convinced it works and
is not a slog on CPU time.
Nothing is stopping you. We will take your suggestions on board, as will the
greater Grex community.
|
scott
|
|
response 62 of 91:
|
Dec 8 03:00 UTC 1999 |
Heh. If Grex is "slowing down to the point of unusability" you obviously
weren't around for the good old days before the 670 hardware.
|
spooked
|
|
response 63 of 91:
|
Dec 8 03:08 UTC 1999 |
That's right. Grex was at least 5 times slower back in those days. I haven't
noticed a slowdown recently (and I'm in Australia), has anyone else?
|
flem
|
|
response 64 of 91:
|
Dec 8 03:33 UTC 1999 |
Grex is faster than the University of Michigan's servers, most of the time.
Of course, this isn't really a compliment to Grex so much as an indication
that UM has troubles. :)
|
mdw
|
|
response 65 of 91:
|
Dec 8 07:34 UTC 1999 |
"update" runs 24 hours. Probably update isn't what you think it is.
Reaps of "problem" files are done by hand, because that's the only
viable strategy. Most of these files show up on grex in the first place
via ftp, which emits its own fearsome multiline message telling people
this is a bad idea. I doubt it would take long for someone to figure
out that files named "eggdrop" disappear every morning, but files named
"eggdrip" stay around.
|
spooked
|
|
response 66 of 91:
|
Dec 8 10:25 UTC 1999 |
Yup, that's a problem - unless you start getting heavily involved into
intrusion detection type analysis, you're not going to have much success with
a total automated 'solution'. And, actually IDS have huge problems of their
own.
|
pfv
|
|
response 67 of 91:
|
Dec 8 20:02 UTC 1999 |
OK, I'm tinkering with the text to newuser. Hopefully, the tinkering
doesn't induce a problem: it looks like it's encoded as screens or
something.
As far as files & downloading: I presume both ftp and pine/elm/attachments
are logged somewhere - as well as lynx transfers? Where? I need to see it
if there is going to be any sort of "tracking" and "reaction".
|
mdw
|
|
response 68 of 91:
|
Dec 8 20:56 UTC 1999 |
There's a big comment at the start of the newuser text that explains
what all the "funny" encoding information does. Most of the remaining
text is formatted to appear about 20 lines at a time. The text for web
newuser is stored separately.
|
pfv
|
|
response 69 of 91:
|
Dec 8 21:28 UTC 1999 |
Umm.. I'm looking at "nu.info", and I sure don't see anything
other than the "paper-trail" of changes.
|
gull
|
|
response 70 of 91:
|
Dec 9 04:29 UTC 1999 |
I think the reason we don't run disk quotas is that Grex does a lot of disk
I/O. Every reference I've read has indicated that turning on quotas
*dramatically* slows down disk I/O and increases CPU load. Most system
administration books treat it as a last resort, of sorts.
"Throwing space at the problem" makes sense because disk space is currently
very cheap, and faster Sun machines aren't.
My FreeBSD machine runs a locate database update nightly. This is probably
similar to what a program hunting for eggdrops would do, since it too has to
look at every filename on the disk. Despite the fact that I only have about
580 megabytes of storage online, the database update often takes three or
four minutes of disk thrashing to complete -- and it's scheduled for a time
when the machine is usually not being otherwise loaded down. I can
certainly understand the argument that a junk file search program could
consume more resources than it's worth, considering it probably wouldn't
take long for people who really wanted to to find a way around it. In
addition, you'd almost have to tell people what names were being looked for,
because it's not very fair for someone's legitimate file to suddenly
disappear simply because they gave it the wrong name.
|
spooked
|
|
response 71 of 91:
|
Dec 9 05:22 UTC 1999 |
Yes, valid point on disk quotas/IO.
We have several free disks. We are waiting for some free time to install one
or more.
|
dpc
|
|
response 72 of 91:
|
Dec 9 20:38 UTC 1999 |
I think it would be great to provide PPP to local dialers-in.
|
gelinas
|
|
response 73 of 91:
|
Dec 10 07:00 UTC 1999 |
<DRIFT>
(Re #64: which UM servers? Doing what? Feel free to drop me a line at
gelinas@umich.edu to answer.)
</DRIFT>
|
flem
|
|
response 74 of 91:
|
Dec 10 18:02 UTC 1999 |
Oh, I don't remember which servers, or know anything about what might
have caused the problem (which could even by my own network), but during
the last few weeks, I've been getting a lot of lag when using Pine,
logged into the login.itd.umich.edu pool.
|
gelinas
|
|
response 75 of 91:
|
Dec 11 04:46 UTC 1999 |
Close enough; still interested in details, but this probably isn't the time
or place to talk about it.
|
sno
|
|
response 76 of 91:
|
Dec 11 17:49 UTC 1999 |
If compiles are a problem, then perhaps it would be better to restrict
compiler access to members and allow guests to request access to the
compiler.
|
mdw
|
|
response 77 of 91:
|
Dec 11 18:12 UTC 1999 |
Yuck.
|
don
|
|
response 78 of 91:
|
Dec 11 19:41 UTC 1999 |
Somebody's in a bad mood...
|
sno
|
|
response 79 of 91:
|
Dec 11 21:41 UTC 1999 |
Some things are never going to be considered when piped through the
Marcus filter.
|