Path: utzoo!mnetor!uunet!steinmetz!davidsen
From: davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: news.software.b
Subject: Re: news software speedup
Message-ID: <10161@steinmetz.steinmetz.ge.com>
Date: 29 Mar 88 19:41:38 GMT
References: <649@bms-at.UUCP> <10150@ncc.UUCP> <4246@hoptoad.uucp> <10128@steinmetz.steinmetz.ge.com> <4265@hoptoad.uucp>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 42

In article <4265@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
| [...]
| My intention was to make an *option* to use large virtual memory to turn
| a 1.5 hour process into a 10 minute process.  People on small machines
| are welcome to thrash their disk heads for 90 minutes; I just don't
| see any reason to make my (4MB physical memory) Sun do that, when a
| pretty simple option in the code would eliminate it.

I think that's what I said in part of my posting you didn't quote. What
I want to avoid is *requiring* a lot of memory, not using it if you have
it.

| On the ulimit question, I find it really hard to believe that *anybody*
| seriously thinks we should write all our applications such that they
| will never, under any circumstances, produce files larger than 1MB,
| because AT&T busted one of its releases.  While we're at it, let's make
| sure that nobody is allowed to [ lines and lines of stuff ]

You can approach this is (at least) three ways. You can set the program
to never produce a large file (which I didn't propose), so it will
seldon produce a large file (which I do), or so that it will almost
always produce a large file (such as putting all news for all groups in
one file or somesuch) which isn't proposed at the moment, either.

The choice of setting options with restrictive limits or not is a matter
of opinion, and not a technical issue. For that reason I don't feel that
either of us will convince the other, although I still feel that your
classification of a choice you don't like as a "bug," might mislead
someone into thinking that it doesn't work as documented.

The consequences of having a low limit are that a few programs may fail. 
A high limit will result in having the first program hung in a write
loop run a filesystem out of space.  If this is a user filespace other
users won't be able to save their work, while if it's the system tmp
space some compilers and editors will stop working.  ulimit is not
useful against a malicious user who wants to hurt the system, pnly for
the klutz who loops a program (like someone learning C or F77, perhaps). 

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me