🚀 go-pugleaf

> anderer@vax1.acs.udel.edu (David G Anderer) writes: 
>>There's no reason they should run jobs on the server, and a good
>>one they shouldn't.
> 
> Do you have any statistics to back this up, or is this a impression that
> you get?  It seems to me that running a job on the workstation takes up
> just as much of the server's resources as running it on the server would.
> 
> Can anyone else comment knowledgeably on this subject?

perhaps his problem isn't one of w/s vs. server in cpu runtime, perhaps
it's more a matter of w/s vs. server RESOURCES.... ie: text table, inode
slots, proc slots, memory, swap, etc.

about once every 2 weeks we run out of text table slots on most of our
servers; always due to developers testing new daemons or something; but
instead of restricting access (which in my book is a NO NO!), i either
reboot every friday night or eval the situation and order more hardware
... another server never hurts, ya know. 

admins also have other tricks... think of a scheme that would make it less
'useful' to run something on a server... like ask your manager for
approval to tighten up system security and chmod 0 /dev/kmem ...  then
"ps" won't work and a developer without the ps command is like a nune
without her hat...

anyways, point is: you have to draw a line between productive and non-
productive environments and let everyone know what the line is. when they
tread on it, let 'em know with a nice warning & detailed explaination.
restricting machine access just creates support & maint headacks for you
and a resentment towards you -and- should be the absolute last thing you
do [to internal staff].

"The Network         Joe Angelo,  VP/Technical Support - Support Group Division
 Adminstrator        Teknekron Software Systems, Palo Alto, CA     415-325-1025
 Is the Computer"    
                     joe@tss.com - uunet!tekbspa!joe - tekbspa!joe@uunet.uu.net