Re: Locking down the User Interface



On Tue, Nov 14, 2000 at 10:16:29PM +0100 or thereabouts, Guillermo S. Romero / Familia Romero wrote:
> dsh8290 rit edu (2000-11-14 at 1544.58 -0500):
> [good comments]
> 
> I think you have explained the same I think, Unix is multiuser, each
> one is old enough to configure, or not at all if you do not want to

For a variety of reasons I have been thinking back to my first 
experiences with Unix recently. One thing I do remember: there was
so _much_ to learn. This is well before we all got X access or something,
and X means "learn more": or at the time, it did, if you wanted to get
work done.

> invest the time, and a script can restore an account to safe defaults.
> Last time I check, GNOME runs over Unix systems, so you get the Unix
> features (and problems).
> 
> So is one of those who want to lock user options going to tell me why
> it is so needed? Is the response "I am a dictactor and Unix system
> does not help"? The idea, in context (this is not Windows, you can not
> break the machine as normal user, and you can recover default config
> fast), only makes sense for dictator styles, IMHO.

There are perfectly valid reasons for dictator sysadmins. An old trick
in this town's university was to wander into the computer room and
"reserve" a terminal: mess with the terminal settings (vt100s, I 
think, but I forget) to set something to "Block" instead of whatever 
it should be in the "setup" menu. This rendered the terminal unusable
unless the poor person who came along next knew precisely which option
had been changed and what it should have been. Then the trouble-maker
could arrive and be sure there was a terminal they could use.

Similarly, people would accidentally set their terminal type wrongly,
and be unable to run vi and be stuck with ed.

I am sure you can think of similar things. We (ahem) had tons of
these tricks for making sure we could get access in the days of
even more limited terminal access than now :) (Mine was to learn 
how to undo every single one of them and watch to see who came in
and headed for the terminal I was using only to stop on confusion!)

In the university I first met UNIX, I had a list of the terminal
types for different terminals so that I could actually set it up
and use something other than dumb tty mode. That meant I got about
ten times more access than the people who could deal with a vt100
or vt52 but not the dumbs, the various tvi ttys, and goodness knows
what. Great for me, but I was busily not attending my lectures in
order to find these bits of trivia out: more assiduous workers who 
just wanted to type their work up were complete stuck. 

Basically, some things should be consistent in a university 
environment so that _all_ students can be assured that they can use
things and that they don't have to rely on the charity of those
people who are able to tweak things to _their_ satisfaction and
render the machine unusable for the next person.

> BTW, for those who think full standarization at working place is right
> (yes, if you want bored workers, and thus improductive workers), I
> would ask them if the seats are glued and the pens have only one place
> to be put. If computer is, why not the rest? Maybe somebody is
> forgetting to lock things. ;]

As with everything, there are limits -- but I bet that if I put my
brain back into "student with too much time on her hands" mode, I
could think of reasons for why almost everything could/should be 
made unalterable :) ("If you leave this configurable, then someone
will...")

On the question as it was originally formed: I ranted for ages about
the lack of information on how to set up GNOME with certain defaults
in place for everyone. Paul Cooper wrote a great article on One Way
To Do It and I begged people for other approaches, which I now have,
and which I should mark up and send to Paul to add. I'm sorry, I
got delayed :)

Currently, there are various /etc files you can create which say
"this is a default and cannot be changed by users", and in the
future, gconf will help immensely with this problem. Telsa




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]