> >This is the most convincing argument i've heard thus far for the fact
> >that the i386 default limits are too low...  If you can't even fsck a
> >'reasonable size' disk/partition with the default limits, there's a
> >problem.
> 
> why don't we just make fsck check and adjust these limits for itself?
> can't we "assume" that it knows what it's doing?  granted, perhaps
> they are a little low for some things, but since anything can modify
> them if need be, why are shells the only things that do (more or less)?

What are "the right limits" for all architectures, that it should be
setting?

You can't reasonably build that kind of information into fsck; code,
data, and stack usage are going to be different from architecture to
architecture.  additionally, some limits (e.g. maximum stack limit)
_cannot_ be increased for the currently-running process, because of
the way the system is implemented.


In other words:

(1) it's not practical, and indeed makes no sense, to include
information like this in programs like fsck, and

(2) depending on what limits need to be changed, those changes may not
be possible in all cases.


NetBSD should easily support all 'standard' programs in all 'expected'
configurations.  Doing anything else is a very bad idea, and reflects
very badly on the OS.


cgd