Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!oliveb!sun!sally!plocher
From: plocher%sally@Sun.COM (John Plocher)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <101492@sun.Eng.Sun.COM>
Date: 27 Apr 89 03:33:55 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <829@twwells.uucp> <1295@frog.UUCP> <863@twwells.uucp>
Sender: news@sun.Eng.Sun.COM
Reply-To: plocher@sun.UUCP (John Plocher)
Organization: Sun Microsystems, Mountain View
Lines: 19

In article <863@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
>>>>>>> (many people) write:
>>>>>>> (use ulimit instead of filling a file system)
>Huh? If ulimit causes a failure, one can always create or extend
>another file, so long as that file is smaller than the ulimit.

But, with a full filesystem you can NOT "always create or extend another file"

>: If you aren't going to buy enough hardware to properly test your software,
>
>Don't be silly. All test environments are deficient in some way or
>
>Tell me, does your testing environment include hardware that you can
> A disk that
>is partly defective? An OS that crashes randomly?

Well, at Microport we did have several "bad" disks which we used to test
the fault handling code in our device drivers.  As to an OS which crashes
randomly, well, not intentionally  :-))))