|
Grex > Helpers > #134: Grex System Problems - Summer 2004 |  |
|
| Author |
Message |
| 25 new of 286 responses total. |
tpryan
|
|
response 46 of 286:
| 
Jul 20 03:26 UTC 2004 |
Dan, I give more authority to ask 'em to stop than it has
for posting them.
|
naftee
|
|
response 47 of 286:
|
Jul 20 03:33 UTC 2004 |
re 44 Can you please retire those items?
|
glenda
|
|
response 48 of 286:
|
Jul 20 04:19 UTC 2004 |
I believe that they have been removed.
|
cross
|
|
response 49 of 286:
|
Jul 20 04:52 UTC 2004 |
This response has been erased.
|
tsty
|
|
response 50 of 286:
|
Jul 20 07:29 UTC 2004 |
hell, a buncha of us *wish* we could take credit for the salvation.
congratulations to whomever it was!
/
|
naftee
|
|
response 51 of 286:
|
Jul 21 02:18 UTC 2004 |
re 49 oic, but why'd it take so long ?!
|
jor
|
|
response 52 of 286:
|
Jul 21 12:09 UTC 2004 |
grex: telnet
/tmp: write failed, file system is full
/tmp: write failed, file system is full
/usr/local/grex-scripts/.inet_real/telnet>
|
jor
|
|
response 53 of 286:
|
Jul 21 12:11 UTC 2004 |
grex: df
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 109823 73971 24870 75% /
/dev/sd0d 156783 120973 20132 86% /usr
/dev/sd6h 1971009 1798533 0 101% /usr/local
/dev/sd0e 706783 372750 263355 59% /bbs
/dev/sd0f 471183 450069 0 106% /x
/dev/sd6g 1969885 1621510 151387 91% /var
/dev/sd7h 1969885 1026946 745951 58% /var/spool/mail
/dev/sd2a 31023 16317 11604 58% /rootbak
/dev/sd2d 31023 15998 11923 57% /suidbin
/dev/sd2f 62863 56584 0 100% /tmp
/dev/sd2h 842574 709514 48803 94% /s
/dev/sd4a 1944365 1749935 0 100% /c
/dev/sd7g 1971009 774405 999504 44% /d
/dev/sd11g 1971692 1733443 41080 98% /a
/dev/sd2e 699223 455142 174159 72% /oldvar
grex:
|
naftee
|
|
response 54 of 286:
|
Jul 21 15:48 UTC 2004 |
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 109823 73979 24862 75% /
/dev/sd0d 156783 121239 19866 86% /usr
/dev/sd6h 1971009 1798541 0 101% /usr/local
/dev/sd0e 706783 372754 263351 59% /bbs
/dev/sd0f 471183 450069 0 106% /x
/dev/sd6g 1969885 1629334 143563 92% /var
/dev/sd7h 1969885 1028824 744073 58% /var/spool/mail
/dev/sd2a 31023 16317 11604 58% /rootbak
/dev/sd2d 31023 15998 11923 57% /suidbin
/dev/sd2f 62863 3873 52704 7% /tmp
/dev/sd2h 842574 709514 48803 94% /s
/dev/sd4a 1944365 1671559 78370 96% /c
/dev/sd7g 1971009 780978 992931 44% /d
/dev/sd11g 1971692 1733229 41294 98% /a
/dev/sd2e 699223 455142 174159 72% /oldvar
|
rcurl
|
|
response 55 of 286:
|
Jul 22 05:26 UTC 2004 |
The vandal has struck here too - 50 newresponse items, with many just
'activations' of items with no response entered. Does Grex have any
way to stop these denial-of-service attacks?
|
glenda
|
|
response 56 of 286:
|
Jul 22 05:34 UTC 2004 |
These are the result of Tod scribbling all his responses yet again.
|
rcurl
|
|
response 57 of 286:
|
Jul 22 05:37 UTC 2004 |
It sure is a nuisance.
|
glenda
|
|
response 58 of 286:
|
Jul 22 05:39 UTC 2004 |
He hit almost every cf, including 107 new responses in Fall 2003 Agora and
60 in Winter 2003/2004.
|
rcurl
|
|
response 59 of 286:
|
Jul 22 05:57 UTC 2004 |
It would be useful if responses could only be scribbled within some short
time - 24 hours? - after posting them.
|
mfp
|
|
response 60 of 286:
|
Jul 22 06:53 UTC 2004 |
That's not technically feasible. Especially since no-one's going to spend
any time doing it. Since they aren't even making New Grex go.
|
slynne
|
|
response 61 of 286:
|
Jul 22 15:19 UTC 2004 |
resp:59 - yes, it would be useful if that were the rule. We could have
avoided the whole valerie and jep thing if that were the case. As it
is, as long as we allow some users to delete their posts, we have to
allow everyone to do it even if some people choose to be obnoxious
about it.
|
albaugh
|
|
response 62 of 286:
|
Jul 22 17:03 UTC 2004 |
I don't think a limit on scribbling is warranted, as much as I'm annoyed.
As intelligently as he writes, tod is acting like a moron every time he does
this. Maybe he's trying to keep up with the polytarp's in the twit race...
|
tod
|
|
response 63 of 286:
|
Jul 22 18:16 UTC 2004 |
Or maybe I'm exercising my right to scribble old responses and saving Grex
some disk space while others see it as a nuisance. Move along, nothing to
see here, folks.
|
rcurl
|
|
response 64 of 286:
|
Jul 22 18:59 UTC 2004 |
Why don't you think a limit on scribbling is warranted, albaugh? It
could give anyone adequate time to scribble if they want. The point is
to stop this *wholesale* scribbling, which grinds one's use of the bbs
to a crawl, as one encounters and bypasses numerous empty responses. If
there were a limit, those that want to scribble would not have as many
to scribble all at once.
|
tod
|
|
response 65 of 286:
|
Jul 22 19:07 UTC 2004 |
Why not change Picospan to not show items as having a new response when there
is just a scribble INSTEAD of punishing those that want to remove their
responses for whatever reasons they may have?
|
gelinas
|
|
response 66 of 286:
|
Jul 22 19:59 UTC 2004 |
I don't _think_ removing your responses will save grex significant disk-space:
each response is lines in a file, and the file still remains after the lines
are gone.
Picospan (and probably every other conferencing system) just compares the
last-modified time of the item file with the last-read time in the
participation file. Deleting a response updates the modification time of the
item file.
|
marcvh
|
|
response 67 of 286:
|
Jul 22 20:02 UTC 2004 |
I'm not sure what the 24-hour time period would do. But it's become
pretty clear that allowing authors to scribble their own responses
causes more problems than it solves.
|
tod
|
|
response 68 of 286:
|
Jul 22 20:48 UTC 2004 |
The discussion of "allowing authors to" is a problem outside of the truth
complaint I'm hearing. People complain they are being told there is a new
response when there isn't one. It has nothing to do with motivation within
authors.
Joe says, " Picospan (and probably every other conferencing system) just
compares the
last-modified time of the item file with the last-read time in the
participation file. Deleting a response updates the modification time of
the
item file."
That sounds like a problem to me. Perhaps its time to revisit the
modification detection process in BBS.
|
marcvh
|
|
response 69 of 286:
|
Jul 22 21:03 UTC 2004 |
"Problem" is relative. PicoSpan was written under the assumption that
modifying responses after they are entered would be a relatively rare
event, and so a little anomalous behavior in this case was acceptable.
Unfortunately, on an open system one can assume that anything which can
be done to annoy people will be done, and not rarely.
|
tod
|
|
response 70 of 286:
|
Jul 22 23:25 UTC 2004 |
"a little anomalous behavior in this case was acceptable"
So the author is responsible if some deem "little" as "too much"?
Illogical.
|