You are not logged in. Login Now
 0-24   25-49   50-74   75-99   100-124   125-149   150-174   175-199   200-224 
 221-245   246-270   271-295   296-320   321-345   346-370   371-395   396-420   421-445 
 446-470   471-495   496-520   521-545   546-570   571-595   596-620   621-645   646-670 
 671-695   696-720   721-745   746-770   771-795   796-820   821-845   846-870   
 
Author Message
25 new of 870 responses total.
aruba
response 246 of 870: Mark Unseen   Jan 5 22:55 UTC 2005

You can see them in ~aruba/.cfonce if you'd like.  My twitfilter also
highlights responses from cetain people by putting them in a different
color.
gelinas
response 247 of 870: Mark Unseen   Jan 5 23:11 UTC 2005

You change that every time someone whens the letter game, Mark?  cool.  :)
twenex
response 248 of 870: Mark Unseen   Jan 5 23:17 UTC 2005

Thanks, mark.
aruba
response 249 of 870: Mark Unseen   Jan 6 00:54 UTC 2005

Re #247: I confess I often fall behind.  But yes, I have a command to
define a command to print out the letter.match# file of the person who is
"it" in each of the games.
gelinas
response 250 of 870: Mark Unseen   Jan 6 02:06 UTC 2005

I'd noticed that Pine creates debug files on another system I use, so I asked
the sysadmins about it.  They hadn't done anything special.  They also
reported that it behaved similarly on another of their systems.  So the
creation of these files appears to be a decision by the Pine developers.

I added an alias for pine to my list of aliases some time back, because I
want to go directly to the index of messages, not the "main" screen.  I've
now modified that alias to turn off the debug files:

        alias   pine    'pine -d 0 -i'
cross
response 251 of 870: Mark Unseen   Jan 6 02:40 UTC 2005

This response has been erased.

drew
response 252 of 870: Mark Unseen   Jan 6 07:25 UTC 2005

Pine and BBS response still do not work when dialed in direct;
and sz is still missing.
kentn
response 253 of 870: Mark Unseen   Jan 6 13:23 UTC 2005

Does /usr/local/bin/lsz work for you instead?  

I noticed that there is an sb link in /usr/local/bin/ that points to a
non-existent file in grex-scripts.  That might confuse some people.
Would it make sense to link sb to lsb, sz to lsz, etc?
twenex
response 254 of 870: Mark Unseen   Jan 6 14:35 UTC 2005

<twenex muscles in>

Generally speaking, I would advise against linking new versions of programs
(in the sense that vim is a new version of vi, gnu tar a new version of tar)
to the names of the old ones unless the new version provides functionality as 
near as dammit identical to the old one when called as such.

(On a related note: a lot of "easy to use" Linux systems alias "cp" to "cp -i",
"rm" to "rm -i", and so on. If this applies to any grexer, I would advise them 
to realias them back to their default "values". Not doing so runs the risk of
coming to a system  where they are NOT aliased and accidentally deleting
crucial files because you expected the system to ask you if you /really/ wanted
to do that, but it didn't. At first I used to disdain aliases for this reason,
but then I hit upon the following strategy:

Say I type "ls -F" often enough that it becomes a pain to have to type it all
the time, especially since i never use "ls" on its own. So I create an alias
based on ls which gives a clue as to the extra flags, such as "lsf". That's
a simple example, but with longer commands it could be quite useful.

Unless you know your system well, it's a pain to have to find the file where
the distributors have aliased all the commands, and you run the risk of having
to do it again when you upgrade. So just type, for example:

alias ls="/path/to/ls"

in whatever .profile or .login file your shell uses (the csh syntax might 
actually be a little different). This forces the shell to look for the command
instead of replacing its behaviour with a new one. If you don't want to do 
this for all the systems and/or account you use, then just do it for root on 
those systems you have root access to. 
twenex
response 255 of 870: Mark Unseen   Jan 6 14:52 UTC 2005

In all instances of ".profile" or ".login file" above, substitute "rc file"
instead.
keesan
response 256 of 870: Mark Unseen   Jan 6 15:43 UTC 2005

I  was able to telnet in just now but dialin does not work:telnetd:  all
Network ports in use.   ...
Followed a few seconds later by NO CARRIER.    
Twice.
There is considerable telnet lag.   There was no wait when I telnetted.
keesan
response 257 of 870: Mark Unseen   Jan 6 15:52 UTC 2005

Using picospan, there is a few seconds wait for the last few lines of the next
response screen to appear.  Vandalism?
keesan
response 258 of 870: Mark Unseen   Jan 6 15:55 UTC 2005

asd, aka 'smart' is using 97% of CPU for the past 550 minutes, running 'john'.
I will email gelinas.  Grex is still usable.   Is there some way to limit
individual users to 1 or at most 5% of CPU use?  
keesan
response 259 of 870: Mark Unseen   Jan 6 16:06 UTC 2005

I have in the past couple of days received three fragments of emails (presumed
spam) consisting of just the beginning of the header such as:

From the-concourse-on-high Thu Jan  6 11:01:04 2005
Received: from [201.17.23.27] (helo=c911171b.rjo.virtua.com.br)
        by grex.cyberspace.org with smtp (Exim 4.42)
        id 1CmZp2-0003qY-M4; Thu, 06 Jan 2005 10:45:13 -0500
Received: (from pyroxenite@201.17.23.27)
        by helmholtz5[1


Is this just sloppy spam-writing or something going wrong in the middle of 
the mail receiving process at grex?  Or vandalism?
petercon
response 260 of 870: Mark Unseen   Jan 6 16:07 UTC 2005

Some people may have more problems in their scripts now that we've 
moved away from a SysV UNIX to a BSD UNIX - the "usr/ucb" directory in 
a SunOS sytem is where BSD UNIX commands were put in Suns SysV OS.  
Something like the move from Korn shell scripts to bash.  Shell scripts 
using Sun's SysV commands may not work the same in BSD (or be missing 
entirely) so be aware.  

Also, there are more differences in the directory structure and the 
whole environment and deamon setup that may affect scripts written in a 
SysV system.  Better test your scripts before trusting them.

In my case (so far) I had to remove all my aliases and removed 
the '/usr/ucb' reference in two places in my .profile.  I also notice 
git is gone and without mc or git Grex is not very easy to use as file 
management is a pain without a file manager.  I'll keep playing though.
tsty
response 261 of 870: Mark Unseen   Jan 6 16:57 UTC 2005

general question: is there a way to spam-filter for plain-ol-mail?
  
pine is a pain (imnsho) even with its 'advanced' features (bloat?).
  
plain-0L-mail is soooooooooooooooooooo easy to use/learn adn it
soes not suck up f feast-full of quota blocks, either.
mcnally
response 262 of 870: Mark Unseen   Jan 6 17:14 UTC 2005

 re #261:  the tool you want to use is probably procmail.  you can
 pass mail off to a filter before it is ever delivered into your inbox
 and the read the mail that passes the filter with whatever MUA (mail
 user agent, aka "mail reader") you want.

 Sindi can probably tell you how to set up an elaborate system of 
 procmail rules to try to screen out spam or you can wait until staff
 have time to install a system like SpamAssassin or other anti-spam
 package and have procmail use that.
petercon
response 263 of 870: Mark Unseen   Jan 6 17:20 UTC 2005

I don't see color in any command (ls, links, lynx, more(less), w3m, 
etc.) anymore.  I forced pine to use color.  Still using Putty which 
means TERM is set to xterm.  On the Sun aliasing "ls -color" worked but 
not on OpenBSD.
twenex
response 264 of 870: Mark Unseen   Jan 6 17:38 UTC 2005

Set TERM to ansi. You can do this in PuTTY too.
keesan
response 265 of 870: Mark Unseen   Jan 6 17:43 UTC 2005

A friend reports that Pine spellcheck is not working.  I tried it and got a
message about something alternate and 255.

Please feel free to copy /a/k/e/keesan/.forward and also
/a/k/e/keesan/.procmailrc but change keesan in the latter file to your own
login and delete all lines starting with # and also change my whitelist (the
remaining parts with $MAIL on the last of three lines) to your whitelist by
putting in the addresses of friends who write you rather than the From:'s that
I have chosen to let through from my friends.  And email keesan for help.
The complicated bit about Nigeria is to send Nigeria spams to a nigeria folder
and also to polygon who posts them at his website.
davel
response 266 of 870: Mark Unseen   Jan 6 17:54 UTC 2005

Re 260: I think /usr/ucb is a Sun-ism.  It's certainly not SYSV, and the SunOS
we were running before was a BSD, pre-Solaris SunOS.
drew
response 267 of 870: Mark Unseen   Jan 6 22:01 UTC 2005

Re #253:
    lsz works. One major issue solved, one (or two) more to go.
keesan
response 268 of 870: Mark Unseen   Jan 6 23:26 UTC 2005

Party (hayz) is now splitting 98% of CPU usage with smart/asd.  Could some
staff member kindly delete both accounts?
tod
response 269 of 870: Mark Unseen   Jan 6 23:31 UTC 2005

load averages:  2.70,  2.73,  2.77                                    
18:31:34
138 processes: 3 running, 135 idle
CPU states: 94.2% user,  0.0% nice,  5.6% system,  0.2% interrupt,  0.0% idle
Memory: Real: 71M/210M act/tot  Free: 1301M  Swap: 0K/3072M used/tot

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT     TIME    CPU COMMAND
20421 smart     64    0 5668K 5980K run   -      953:53 49.37% john
11064 hayz3141  64    0  300K  896K run   -       44:26 45.80% party
29978 _mysql     2    0   34M   17M sleep poll     1:29  0.00% mysqld
32358 _syslogd   2    0  164K  488K sleep poll     1:16  0.00% syslogd
 3601 named      2    0 2516K 2852K sleep select   1:05  0.00% named
20957 exim       2    0  580K  696K sleep select   0:27  0.00% exim-4.42-2
15359 _pflogd    4    0  512K  328K sleep bpf      0:08  0.00% pflogd
15771 root       2    0  284K 1000K idle  select   0:05  0.00% sshd
10834 root       2    0 1092K 1932K sleep select   0:04  0.00% httpd
mcnally
response 270 of 870: Mark Unseen   Jan 7 00:49 UTC 2005

 re #268:  quoting % CPU usage is not enough to establish that a user
 is abusing the system.  At the very least we'd need to know the load
 average on the system as well.  When not very much is going on it's
 not unusual for a single process or a few processes to appear to hog
 the CPU.  It doesn't necessarily mean they're starving other jobs.
 0-24   25-49   50-74   75-99   100-124   125-149   150-174   175-199   200-224 
 221-245   246-270   271-295   296-320   321-345   346-370   371-395   396-420   421-445 
 446-470   471-495   496-520   521-545   546-570   571-595   596-620   621-645   646-670 
 671-695   696-720   721-745   746-770   771-795   796-820   821-845   846-870   
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss