Xref: utzoo comp.sources.d:3566 comp.bugs.sys5:859
Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!genrad!jpn
From: jpn@genrad.uucp (John P. Nelson)
Newsgroups: comp.sources.d,comp.bugs.sys5
Subject: ulimit (was: getty/login for callback)
Message-ID: <19516@genrad.UUCP>
Date: 13 Apr 89 12:41:01 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <28@wells.UUCP> <399@aucis.UUCP> <501@bilver.UUCP>
Sender: news@genrad.UUCP
Reply-To: jpn@genrad.genrad.COM (John P. Nelson)
Followup-To: comp.bugs.sys5
Distribution: usa
Organization: GenRad, Inc., Concord, Mass.
Lines: 24

>The newer system permit ulimit to be defined at a higher limit.  And putting
>the ulimit in the profile makes sense (to me at least) on a system like that.

Excuse me, perhaps I'm slow.  But could someone please explain to me
just what the PURPOSE of "ulimit" is?  What are it's GOOD points?  It
strikes me as a misfeature, one whose elimination would benefit
EVERYONE.  I mean, it's not a quota system, users can still fill the
disk with lots of files smaller than the ulimit.

What could POSSIBLY have been going through the minds of the developers
at AT&T: "Let's add something to the system that adds no value but will
frustrate everyone who ever runs into it.  And while we're at it, we'll
make the default setting too small, and make it so that only root can
change the setting, and then, only on a process-by-process basis." It
sounds like something a COMPETITOR would try to sneak in, like industrial
sabatoge!

Despite the tone, I really would be happy if someone could demonstrate
a useful purpose for "ulimit".

     john nelson

UUCP:	{decvax,mit-eddie}!genrad!jpn
smail:	jpn@genrad.com