Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: news.software.b
Subject: Re: news software speedup
Message-ID: <4265@hoptoad.uucp>
Date: 28 Mar 88 15:10:29 GMT
References: <649@bms-at.UUCP> <10150@ncc.UUCP> <4246@hoptoad.uucp> <10128@steinmetz.steinmetz.ge.com>
Organization: Grasshopper Group in San Francisco
Lines: 51

davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) wrote:
>                                Obviously having the ulimit (or any other
> configurable parameter) set to an inappropriate value is a "vendor
> problem" rather than a "System V bug."

Not if in the default System V, that AT&T supplies to all the vendors,
the parameter is configured wrong.  That's a bug.  It's a bug that Sun
ships SunOS configured to run out of text table entries if you bring up
seven windows and run the compiler.  Just because you can fix it
without sources doesn't mean it isn't a bug.  If it's a "vendor problem"
howcum all the Sys V vendors have the problem?

The default file size limit should always be no limit.  People who want
a limit can always reduce it in their .login file, but the way it's
implemented you can't *increase* it if you don't like it, the way you
can in BSD.  I don't see why J Random User would ever want to limit the
size of a file he can manipulate though.  It's useless as a system
management tool; somebody who wants to fill the file system can always
just create N files, each of 1 megabyte.  I've heard the stories about
saving yourself from runaway processes filling the disk; tell me, when
is the last time that happened to *you*?  And it only took one "rm"
command to fix it, right?  Ulimit is just a hassle with no benefit, aka a bug.

> I think it would be unwise to speed up expire or anything else by using
> 3-4 MB of memory (forgive me if I misread your intension). There are a
> LOT of machines which don't have that much memory, real or virtual.

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.

======

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 type any lines wider than 80 columns,
and build file systems that can only hold 16 megabytes before you have
to partition your disk.  Since AT&T doesn't support TCP/IP, let's tear
down the Internet, toss NNTP, and go back to 300 baud modems.  No,
wait!  Let's build a whole computer so brain damaged that you can never
use more than 64K of data at once, even though the machine can have
megabytes of main memory!  Oh...your hardware has lots of disk and
columns and networks and main memory?  No problem, we'll get AT&T to
set a limit in software!  Now we're getting somewhere...    :-)
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
		"Watch me change my world..." -- Liquid Theatre