Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!NUSVM.BITNET!GBOPOLY1
From: GBOPOLY1@NUSVM.BITNET (fclim)
Newsgroups: comp.sys.apollo
Subject: re: some questions for the gurus
Message-ID: <8809061151.AA11953@umix.cc.umich.edu>
Date: 6 Sep 88 11:31:19 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 78
X-Unparsable-Date: Tue, 06 Sep 88 18:46:59 SST

hi,
     (2) i am sorry for misleading people like jeff putsch (gatech!
amdcad!neptune.amd.com!putsch).  i do not wish to lock up crp as well
as sigp.  both are definitely needed once in a while, especially by
ordinary users.
     yes, you are right.  "crp -on //w1a -me -cp xdmc shut" won't
work.  i am sorry that i didn't check this out before mailing my
questions.
     another thing about sigp is that i do not wish to see users
killing the printer server.  but still, i will not edacl sigp to
% -.

     (1) and (2) jim rees (rees@mailgw.cc.umich.edu) writes:

>I've heard the claim that things are different in an academic environment,
>that you can't expect students to exhibit responsible behavior.  Well maybe
>I'm just an old fart, but I do expect that of students.  Does the Music
>school lock down the tops of the grand pianos so the students won't cut the
>strings?  I don't think so.

ok, i am sorry for classify students as mischievous.  my problems are
that our students are still green about computers.  they do not know
about partner and diskless nodes and about background (server) processes
or server-server like siomonit which we use for kermit.

>I don't give my car keys to someone I don't trust.  And I don't give a
>computer account to someone I don't trust.  I wouldn't ask a workstation

gee wheesh, i wish i have your authority -- blocking anyone i don't
like from using the computers.  we have laws here against such
discriminations.

>manufacturer to prevent users from shutting the machine down for the same
>reason I don't ask Ford to prevent users from running my car over a cliff.

don't extrapolate.  and if you do extrapolate, make damned sure that
your extrapolation is still in a straight line -- my stat prof.
you might as well say that people shouldn't write in asking questions
on how to prevent god from sending a lightning strike through an open
door at the workstations.

>everyone. But workstations are supposed to put the power into individual
>people's hands. I think that's an important distinction.  When you start
>treating your workstations as timesharing systems, you've taken power out of
>the hands of the people, and put it into the hands of the bureaucrats.  I
>think that's bad.  All of you users out there should be worried when people
>who run computer labs start asking how they can prevent users from shutting
>down the system.  Let them know that's the wrong question to ask.

my policy has always been to keep an open and flexible system
(in a previous query, i asked about allowing users to be able to have
their default login window changed to their choice of shells as well as
using dm or x as default).
i have kept all sources (including my system shell scripts or c programs)
on the file system.
my philosophy is that an open system will allow expermentations which
lead to better understanding.  but WHY would anyone want to try their
hands at shutting down the system?  is that a real big trill?  why
can't they write their programs, use the software packages, etc  and
leave the shutdown and system adminstration to the people who are
hired to look after such things?  why can't they understand by doing
so, they will have all the powers of the workstations, or maybe even
more, in their hands?  i can always write shell scripts or c programs
that will monitor them as if they are winston smiths.  but that will
put more load on the cpu.  and will that help them as well as me?

all i am asking is that apollo computers inc. removes some power
from the dm.  they have make the file system tight with acl et al.
i think it's time now for priorities on processes and shut is the
process to stop the grand-daddy process -- init.  it should be
handle with care.  maybe jim rees is blessed with all disked nodes.
but we can't afford such luxuries.

fclim         --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513