Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <863@twwells.uucp>
Date: 25 Apr 89 05:12:02 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <829@twwells.uucp> <1295@frog.UUCP>
Reply-To: bill@twwells.UUCP (T. William Wells)
Followup-To: alt.flame
Organization: None, Ft. Lauderdale
Lines: 44
Summary:
Expires:
Sender:
Distribution:
Keywords:

In article <1295@frog.UUCP> john@frog.UUCP (SuperUser) writes:
: In article <829@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes:
: > In article <1423@cunixc.cc.columbia.edu> seth@ctr.columbia.edu (Seth Robertson) writes:
: > : In article <10065@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
: > : |It's great for testing whether your application recovers gracefully from
: > : |"file system full"-like conditions!
: > > [no, fill a file system]
: > I suspect that there are very few environments where it is reasonable
: > to fill up file systems just because you want to test out "file
: > system full" checking.
:
: However, using ulimit() to test that makes it harder to discover that your
: application recovers from that by creating another file and logging a message
: to it.

Huh? If ulimit causes a failure, one can always create or extend
another file, so long as that file is smaller than the ulimit. It is
quotas that would screw you there. And if you want to test for write
failure on the additional file, that too can be arranged simply
enough.

: If you aren't going to buy enough hardware to properly test your software,
: why bother with testing at all?

Don't be silly. All test environments are deficient in some way or
another. It's called cost. And practicality. It is wholly useless to
argue that one should have extra hardware to test an error condition
when it is entirely possible and extremely easy to simulate the error
condition using software.

Tell me, does your testing environment include hardware that you can
do things to like smoking chips to see if the OS will recover from the
induced parity errors? How about an alpha-hit generator? A disk that
is partly defective? An OS that crashes randomly? A user that enjoys
destroying keyboards while your program is running?

I thought not.

Why did you make such an irrelevant, and nasty, statement?

Note that followups have been directed to alt.flame.

---
Bill                            { uunet | novavax } !twwells!bill