Newsgroups: comp.sys.apollo
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: Re: process priorities (problem?)
Message-ID: <1991Mar20.062300.25980@alchemy.chem.utoronto.ca>
Organization: University of Toronto Chemistry Department
References: <18030@milton.u.washington.edu> <504080ad.20b6d@apollo.HP.COM>
Date: Wed, 20 Mar 1991 06:23:00 GMT

In article <504080ad.20b6d@apollo.HP.COM> smv@apollo.HP.COM (Steve Valentine) writes:
>In article <18030@milton.u.washington.edu> etb@milton.u.washington.edu (Eric Bushnell) writes:
>>Would someone be so kind as to explain how
>>Domain process priorities work?
>
>You're running into one of those areas where Domain/OS maps a square UNIX peg
>into a round Aegis hole.
> <... niceness<->Aegis priority mapping deleted>

This table is certainly wrong for nice values of 2 through 20 inclusive,
all of which result in Aegis priority range of 3-16, negating much of
the usefulness of nice/renice.

>>An ordinary, unprivileged user wasn't happy
>>with the priority of his batch job, which he
>>had started with /usr/bin/nohup. So he used
>>/etc/renice to change his priority to -20,
>>the highest priority in BSD unix. Only the
>>superuser can do this, right? Apparently not.
>
>It has long been the Apollo position that Domain Nodes are single user machines.
>We try very hard to make the node as usefull as possible to it's one user.
>An ordinary, unpriviledged user in this environment may very well have reason to
>adjust the priority of some process on his or her node, and can only hurt
>themselves by doing so.  When nodes are used in shared environments,
>their users must learn that it is socially unacceptable to take advantage of
>some of the features available.  If we required root access to renice processes,
>we would be depriving our users of a feature that they have become accustomed to
>and which we feel they can benefit from.

Our nodes were sold to us as multi-user workstations (especially the
DN10000); being able to renice any other user's process, including kernel
level processes, and to be able to raise any process priority is a gross
violation of UNIX. Apollo UNIX users should never have been given this
"feature" in the first place, which required hacking on the source code.

I agree completely with another posting which said that IBM and Apollo
shouldn't be calling their products "UNIX". Gratuitous changes are a
pain in the <insert favourite region here>.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775