Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!ames!ucsd!sdcsvax!ucsdhub!isg100!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <1319@nusdhub.UUCP>
Date: 18 Apr 89 21:44:28 GMT
References: <19516@genrad.UUCP>
Distribution: usa
Organization: National University, San Diego
Lines: 25

in article <19516@genrad.UUCP>, jpn@genrad.uucp (John P. Nelson) says:
> Despite the tone, I really would be happy if someone could demonstrate
> a useful purpose for "ulimit".

While I can make no calim about the reason the default size being what it
is, the ulimit is a distinctly useful concept.

Remembering that UNIXis a software development environment (at least
in it's historical role) the idea of having a curb agains a single file
undergoing runaway growth make alot of sense.  IF you are expecting a
system to produce a small file, say 4k, the ability put a choke of 40k
on it has some real use and value (including the fact that the program
itself can lower the threshold but not raise it.).  Since root can set
it to anything it wants, it is flexable enough for just about any
useage environment.

The real flaw in the ulimit idea is that there is (was) no good way to
set the default to something other than the compiled value.  The
tuneable parameter was a good idea that got rid of most of the problem
in most useages, as was the login-hack before it (abet a bit ugly), but
the continued lack of an by-account limiting mechanisim (say adding a
field to /etc/shadow which will allow login to adjust the accounts
ulimit setting if the field is not blank) is still a bit inexcuseable.

Rob.