ulimit considered braindamaged ?

[Guy Harris]

> To declare this approach in terms like "...come to their senses..." and 
> "...is the wrong solution...", on the other hand seems a bit arrogant.  

The arrogance here is AT&T-IS's, not mine; by hardwiring the limit to 1MB or
so (count your blessings - at least it's a #define constant; in S3 it was a
hardwired 1L<<11!)  and providing no way of changing this without hackery,
they declared that nobody should ever want to create files larger than 1MB
unless they're running as "root" or want to go through that hackery.
Sticking this into the kernel without making it a configurable parameter
*is* senseless; the complaints that surface periodically on the net about
this should be sufficient evidence of that.

> Possibly 'a better way...', but wrong?  Wording of a response can 
> make it so much more acceptable and more pleasant to read.

Yes, *wrong*.  If some people find it unacceptable to state that, that's
their problem.

If the intent is to limit people's usage of disk space, "ulimit" doesn't
succeed in many cases.  Individual users are quite likely to have lots of
small files, and "ulimit" does nothing about that.  Disk quota mechanisms
can control that.

If the intent is to control runaway programs, it should be user-controllable
and should default to "infinity", not 1MB.  There's no reason whatsoever to
penalize database programs and the like, as they often have quite legitimate
reasons to have files larger than 1MB.  4BSD has a mechanism which is almost
identical (it also sends a signal if you exceed the file size limit, and
also provides limits for other resources such as CPU time), but the kernel
doesn't set "init"s file size limit to 1MB.