I ran a "!w" today at the "Ok: " prompt and noticed that instead of
seeing "trn" as  a "what" entry, I saw "trn (newsgroup deleted)". Is this a 
change, or have I just not noticed it before? I think it'd be kind of 
embarrassing if someone were to run the "!w" command while I'm over in 
"alt.sex.bestiality.barney", even though I'm most likely doing something
kosher. ("alt.sex.bestiality.barney" was a bogus example; we don't receive
it yet, and I'd probably stick to "alt.tv.barney" anyway, but I need an
example to make my point.) Thoughts?

43 responses total.

There's been no change, but don't worry.   You probably invoked trn
by typing 'trn <name-of-newsgroup>'.  When you run a command, Unix
stores the command name *and any parameters you supply* in a table
which is accessed and displayed with the 'w' and 'ps' commands.

If you don't want people to know what newsgroup you're in, type
'trn' with no parameters and 'go' to the newsgroup once you're inside
trn.  That way, 'w' will just report that you're running trn.

Thanks. The person I had "!w"'d must have been pretty eager to get to that 
icular newsgroup... not me! I'll always use "!trn"!

Yep, it's amazing, some of the things you find out about people with
the w command.  Actually, I'm thankful - it was running a w command
and seeing someone using a program called "elm" that got me to start
using it.

Ow.

I've been using elm for a while now, it's faster than Pine, yet better than
mail.

   Actually, if you want to discuss the implications of finding out
what people do/think, try looking at their .newsrc file.  I know of
a place in town that, once they were on the net, had some interesting
problems once it was known that some of the technical folk there read
"Those" kinds of newsgroups.

There are ways of fooling finger and w and who...

Yup.

re #7: how? is that something that the general user could learn? I already 
        avoid "!trn"-ing specific newsgroups, but I haven't checked my .newsrc
        file to see what it says, if anything. Tell us more, please.

It's a file in your home directory that newsreader programs like trn use
to keep track of what newsgroups you subscribe to and what articles you've
read.  To view it, type "!cat .newsrc" at the next prompt.  It's normally
world-readable, so other users can look at a person's .newsrc to see what
newsgroups the person has been doing lately.

I don't think it will break anything if you depermit reading of .newsrc
by others.  To do this, type "!chmod og-r .newsrc".

I wouldn't expect it to break anything, but it's also possible that it won't
do any good.  .newsrc is renamed and recreated every time you run trn, and
the permissions may be reset when this happens - or it may use the permissions
of the old one; I've never tried it.  (But most likely it just uses your
umask when it creates the new one, I think.)

A possibly simpler solution would be to create a directory to which no one
else has rights, move your .newsrc and .oldnewsrc and your news dirs under
*that*, and go there every time you run trn.  (Or is there something else,
like some environment variable, that you'd need or want to set?)

Note that what people see if they use finger or w may not be what you expect
in any case, if what you run calls some other program.  People running mail
or elm or the bbs with an editor set can commonly be seen running vi or
whatever on some file or other in /tmp as they compose their material.

Kent, I also am interested in what you said in #7.  Say on, please.  Purely
abstract curiosity, of course.

Or just change your umask to 077.

trn uses your home directory to store your .newsrc and .oldnewsrc
files by default, but this can be changed through a trn flag.
(No, I'm afraid I don't remember which one, and I don't have a
convenient way of looking at the manpage right now.)

I don't need to fool people I'm only in clean conferences.

Define "clean" as you intend to mean it.

This is not a foolproof method, but will distract the idly curious
and the Unix-inept (like most bosses and coworkers):
 
#include <stdio.h>
 
main()
{
        execl ("/usr/ucb/ftp", "vi test.tex", (char *) NULL);   
}
 
I'd like to know of a better way, if one exists.

This response has been erased.

Re #16:  You're exploiting a special property of ftp there...

very good.

I count myself among the Unix-inept. If I go to a Unix prompt, do I enter the
contents of #16 on one line? Also, I've noticed that some people who shell
have their shell listed instead of what they're actually doing. Perhaps if
I moved to a shell other than Picospan...?

No carson, #16 was a c program. It needs to be compiled and loaded,
then it will be a program that does what he wants. kentn left those
juicy bits out.

This response has been erased.

Yes, I left out a lot of juicy bits, but then I'm not the expert at this
and others around here are.  It works for programs other than ftp (I
use it for trn, for example).  You'll have to improvise.  I'd also like
to know how to read command line parameters into such a program, so
for example, one could use it to disguise sz usage.
   Anyway, you compile it with cc or gcc to get an executable (compile
everything between "#include" and "}" inclusive).  As shown in :16
it will look like you're using vi when you're actually using ftp, though
I hear it's possible to get more direct information on a job's status
than what w, who, or finger give, therefore this method can be defeated.
   A better place to discuss (or ask) about this sort of thing would
be in the jellyware conf.

It's not anything about ftp, it's using a property of the exec() family
of functions, that (many of them, anyway) allow you to give one name for
what's running and specify a different name as what actually is called.
Hm.  Cute idea, Kent.  I think that if you tried to set this up to be
called with a command line, then that command line (besides showing up
briefly even with w) would be available to ps.  Someone with more experience
with these functions in this environment may correct me.  You could work
around this by setting your umask to disallow read access to others, creating
a temp file with your command line, and making the program read its parameters
from that, I think.  But I'm not really sure what all might show up.

Hmmm...I might try that, Dave.  Oh, and this certainly isn't my idea
or my programming...it was forwarded to me from a Usenet discussion last
year. 

A prime example of what this item is about:

  2:58pm  up 1 day, 23:15,  9 users,  load average: 0.56, 0.30, 0.03
User     tty       login@  idle   JCPU   PCPU  what
gracel   ttyh0     2:45pm     5      5      3  vi /u/gracel/cf.buffer 
carl     ttyh1     1:33pm         1:35         vi +15 /usr/local/lib/lynx/menu/
mta      ttyh2    12:48pm     2     24     13  mail 
robh     ttyh4    12:39pm         2:24   1:24  trn 
tsty     ttyh5     1:58pm     9     23      6  more 
babat    ttyp0     2:53pm     2      2      2  /usr/local/bin/bbs 
gregc    ttyp2    10:08am  2:36     30      5  -tcsh 
other    ttyp4     2:36pm     1     22     10  w 
rwalters ttyp6     2:13pm    17      7      7  trn alt.binaries.pictures.erotic

Enjoy!

What, me using trn?  Preposterous!

I was on with 16 *other* people!  The link is GROWING!

um, the link stays the same. The use grows, and the connection slows.

When talking about the load average, What is a good load average to have
the system running halfway quickly?

The follwing "w" I did at the same time that I was typing this message,
and the system seems to be responding fairly nicely.

 11:24am  up 2 days, 19:41,  12 users,  load average: 0.51, 0.27, 0.03
User     tty       login@  idle   JCPU   PCPU  what
cicero   ttyh0    10:13am           17     10  more 
remmers  ttyh1    11:16am           13      3  ftp ftp.cica.indiana.edu 
newuser  ttyh3    11:12am     3                -
wjw      ttyh4    11:21am                      mail 
robh     ttyh5    10:43am         1:10     16  trn 
srw      ttyp0    11:04am     2                -usr/local/bin/tcsh 
curby    ttyp1    11:11am     1     12      2  pico /home/curby/.cfdir/cf.buffe
srw      ttyp2    11:05am     2     10      5  bbs 
beng     ttyp5    11:23am            4      4  pine 
srw      ttyp6    11:23am     1      2      2  lynx 
pig      ttyp7    11:23am            4      4  pine 
curby    ttyp9    11:24am            1         w 

wait until 5 or 6 people are trying to use trn at the same time...

When the average gets to around 30...things really slow down...heh

re #30: 0.51 is a very light load. The old grex would get up to 6 or 9
and then the system would be on its knees. 

re #31: This load average is a measure of the length of the queue of
processes waiting to get service from the CPU. When you have a lot
of people waiting for communications (which is what trn does) I believe
that they will see slow response, but it will not show up in the
load average.

Wait until you see 5 or 6 people trying to compile programs at the same
time.  Fortunately, that doesn't happen.

Gee, you mean I shouldn't use grex as a backup system for my programming
students in case the emu system goes down?

I wanna see this now! Is there any way we could get, say, carl compiling 
lynx, srw fixing up layers, gregc, mju, and steve doing something or other,
popcorn fixing up mathom, and remmers with several of his CS students
doing their programming, all on Grex at once? I'd *LOVE* to try to trn during
that! Can we get them all to telnet in, too?

=)

Actually, I have seen the new Grex with a load average around 10 and the
system was still responding very quickly. The ibig difference is that the
new Grex has 32 meg of main memory. That's alot of memory even
for a modern machine. On the old Grex, if there were 10 processes
in the run queue, at least half of them would be swapped out
to disk and there would be alot of disk activity involved. On the new
machine, all those users will be in memory.

   Yes Carson, we could, but it'd be painful for those on the link.
We've enough CPU power that the system would deal with things OK,
but the poor little link would be pretty beaten up.

The machine I use at work has 128 meg of main memory.  When the load
average hit around 32 one day, the whole system bit the dust...
(All the tmp space had been used up and most regular Unix commands
would just sit in the job queue, leading to a fast-climbing average.
It was fun to watch...until the system crashed, that is).  Is there
some upper (practical) limit for load average (given a certain amt
of RAM)?

   It all depends on anumber of factors, which are CPU, disk speed
I/O throughput of the system and others, to name just a few.  Most
system will start to die at abuut 30, though.  You could make a
system that could do better if you really wanted to.  Wait a
couplea years.

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