Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!voder!pyramid!ncc!atha!lyndon@aurora.AthabascaU.CA
From: lyndon@aurora.AthabascaU.CA (Lyndon Nerenberg)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Summary: reality? we don't need no ...
Message-ID: <545@aurora.AthabascaU.CA>
Date: 25 Apr 89 18:59:00 GMT
References: <836@twwells.uucp> <4428@ihuxz.ATT.COM>
Sender: news@cs.AthabascaU.CA
Reply-To: lyndon@nexus.ca (Lyndon Nerenberg)
Organization: Athabasca University
Lines: 42
In-reply-to: burris@ihuxz.ATT.COM (Burris)

In article <4428@ihuxz.ATT.COM>, burris@ihuxz (Burris) writes:
>From article <836@twwells.uucp>, by bill@twwells.uucp (T. William Wells):
>The ulimit has NOTHING to do with the assumption that users are stupid
>or malicious. It DOES however assume that people make mistakes. Do you
>know any programmer who has NEVER hacked up a quick program with an
>infinate loop?

Yes. And those that do nearly always screw up a read loop, not
a write loop. [ I have no numbers to back this, but I've administered
a lot of machines and never seen an mistake like this fill a file
system ]

>It is not difficult at all for the administrator to set a higher
>ulimit for users that have a legitimate need, ESPECIALLY is you have
>source to the login program. I implemented this easily by having the
>login program look through a file to find users that required special
>ulimit sizes and set the appropriate ulimit before exec'ing the shell.

That's a pretty damn big ESPECIALLY. Are you aware of the price your
company charges for that source code? If I was running a commercial
shop, instead of paying a small fortune for source, I would put the
money to better use buying more drives for the disk farm.

>If you had ever been an administrator in a software development
>environment you would see the demonstrated need for the ulimit.

I have, and I don't. If you're developing on a machine that you
sell time on, you deserve what you get when you screw up.

Yes you can turn ulimit up by reconfiguring the kernel. But how do
you rationalize ulimit in a database environment where your running
striped file systems with database files in the range of 2 GBytes each?
As people move towards hypertext and graphics based environments, the
size of the files you have to deal with will increase as well. "No
problem," you say. "Just turn up the ulimit." Well I say, "When the
ulimit reaches the file size limit, what is the point of having
ulimit?" 

As a system administrator I feel that ulimit (if it's to exist) should
default to the maximum possible file size (base on the inode struct).
If *I* as a system administrator want to turn it down, fine. That
isn't too hard to do right now :-) Going the other way isn't ...