From: fwp@CC.MsState.Edu (Frank Peters)
Subject: Re: Bringing a Sun to it's knees
Organization: Computing Center, Mississippi State University
Date: Tue, 26 Jan 1993 02:07:51 GMT

In article <1993Jan25.224946.12079@hal.com> ables@hal.com (King Ables) says:
: From article <1993Jan25.221022.28758@ra.msstate.edu>, by fwp@CC.MsState.Edu (Frank Peters):
: > In article <T6AXBYAV@cc.swarthmore.edu> eoliver@ralph.cs.haverford.edu (Erik Oliver) says:
: > : During our Operating Systems class, we were being asked to see for
: > : ourselves that "modern" operating systems place limits on the number of
: > : processes an individual user can run thus preventing over load.
: > 
: > Interesting.  Who came up with that theory?  It isn't true and in many
: > cases it isn't desirable.
: 
: But then you went on to prove that it *is* true ;-) (at least for Unix).

Huh?  Nonsense.  I specifically sited single user workstations as an
example of a situation in which it is NOT desirable (and pointed out
that most of the Suns out there by a wide margin are desktop systems).

: I took the original posting to imply that the class instructor was trying
: to claim that Unix was *not* a "modern OS" because you couldn't protect
: from "this here program that uses up all the processes."  

Then the instructor should probably not be teaching the course.  There
is no absolute correct answer here.  The best choice on a single user
machine is different from the best choice on a multiuser server.

Arguably companies that only make server class machines should choose
a default maximum appropriate for their market (and, in my experience,
many do).  If they don't then that is a flaw in their configuration
not a flaw in UNIX (UNIX has enough flaws without inventing more).

So all the instructor's assignment did was to demonstrate that SunOS
comes, by default, optimised for desktop workstations.  But that
doesn't seem to be what he/she was trying to demonstrate.

:                                                           Unix does have
: a limit and you can change that limit.  You have to rebuild the kernel
: in order to do it, though (at least on versions I know about), so it is
: not as easily configurable as one might like.  The instructor was probably 
: thinking of a limit you could set "on the fly" with an OS command, or
: perhaps being able to set different limits for different users.

I can agree with that.

: The default limit most Unix machines is that the user can use up almost
: all the process slots.  As Frank said, in the case of a single-user
: workstation, this is what you want.  In the case of a multi-user Unix
: machine, clearly you don't want one user to be able to use up everything.

Sun is hindered a bit by the fact that they use the same OS on desktop
machines and servers...and, in the case of SS10s and the like the
distinction isn't an easy one to make.

That said, though, they could certainly do better.  A quick glance
through the administration guide didn't even turn up a discussion
of the issue.

: But just because Unix behaves a certain way by default doesn't mean 
: it can't be adjusted.  Most things like this can be customized for 
: the specific needs of a particular user community.

And it often is.  Many high end only UNIX implementations have a
relatively lower per user limit.

: Unix does not suffer from a problem here unless you have your kernel
: configured incorrectly for your enviornment.  Now whether or not you
: should have to jump through those kind of hoops to set the limits is
: a philosophical (and entirely different) question.  But claiming Unix
: has some deficiency due to not having a way to limit users' use of
: processes is clearly wrong.

It has a way...and, all things considered, not all that complicated a
way (change one line in a C program file and rebuild your kernel...
easier than getting SunOS 4.x to use DNS without YP/NIS).
--
Frank Peters  -  UNIX Systems Programmer  -  Mississippi State University
Internet: fwp@CC.MsState.Edu  -  Phone: (601)325-7030  -  FAX: (601)325-8921
Newsgroups: comp.sys.sun.admin