|
Grex > Coop11 > #140: Grex in the new millenium-- should it be web based? | |
|
| Author |
Message |
| 25 new of 91 responses total. |
other
|
|
response 50 of 91:
| 
Dec 7 21:50 UTC 1999 |
for people who want to download mail and get offline to read it, or for people
who prefer the comfort of a graphical interface for conferencing to a command
line. it would be interesting to permit outgoing telnet (since we do anyway).
|
other
|
|
response 51 of 91:
|
Dec 7 21:50 UTC 1999 |
scott slipped in.
|
pfv
|
|
response 52 of 91:
|
Dec 7 21:55 UTC 1999 |
I'm sorry, I guess you lost me...
If they are "comfortable" with that sort of interface, it seems to
me this implies they already have net-access of some sort.
It sounds like a band-aid on something, but I'm not sure (nor
would I want to hazard a guess) on what.
|
gull
|
|
response 53 of 91:
|
Dec 7 22:26 UTC 1999 |
If it's a band-aid, it's a band-aid for people who are not comfortable with
command lines. It'd allow them to use the web-based features of Grex,
without having to buy internet access from somewhere else.
I can't think of a good reason *not* to do it, as long as the current
least-common-denominator access is also maintained.
|
pfv
|
|
response 54 of 91:
|
Dec 7 22:42 UTC 1999 |
Oh, I'd not argue it as a BAD Thing, provided it didn't mulch
CPU like say.. downloading and compiling eggdrop & bnc2 and icq
are already.
I was simply trying to envision why those "web-based tools &
programs" had some advantage to the dialin user over a comline.
Basically, it sounds like an idea to further reduce the "curb" -
and I'm never sure that's a good idea: not even if my own parents
would take advantage of it.
|
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.
|