> In practice, users on timesharing systems seldom need more than 10 or
> 15 simultaneous processes

I submit that this either is no longer true or refers to a type of use
that is no longer common.

It was probably true in the days when users had serial-line terminals
connected to many-user systems - and to the extent that such systems
still exist, I believe it's probably still true.

But with GUIs everywhere, I don't think it's true any longer.  If by
"timesharing" you mean basically that sort of setup, one central
machine with users connected through a narrow channel like a serial
line, then your remark is probably true - and irrelevant to most
machines, and certainly most NetBSD machines, today.  But if by
"timesharing" you mean the technical meaning, timeslicing between
multiple processes, then approximately everything is a timesharing
system, and I don't think 10-15 processes covers it.

I used to run SunOS on my desktop, and I regularly ran into inability
to start another client because the X server had run out of file
descriptors, under an OS where the limit was, I think, 32.

I just ran a ps on my login screen-and-keyboard machine.  Skipping
things like inetd and sshd, I see 44 processes: 6 terminal emulators,
five ssh processes through whose X forwarding I have windows running on
other of my machines, my login shell, ssh-agent, xinit, the X server,
the shell running my .xinitrc, my session distinguished client, my
window manager, my connection security forwarder, the process
maintaining the window reminding me what my $DISPLAY is, my root
background maintainer, two clocks, a picture displayer, seven shells, a
picture display daemon, nine ssh clients running remote sessions to
various other machines in the local terminal emulator windows, an alarm
clock / timer program, and the ps and netcat through which I fetched
the listing into the editor I'm writing this message in.  If I'd just
started my session, maybe a third of those wouldn't be there.

Now, I probably run more goop than most people - but I also run
lighter-weight goop; no konqerors and its ilk that gulp five and ten
processes at a crack.

And I didn't even skew the results by running a multi-machine directory
comparison script I use that spins off some 30 to 50 processes all on
its own.  (The machine bogs down a little when I start it, but it soon
ends up with most of them waiting on the network - the house net runs
wide open for a while - or on other involved processes.)

> I would support lowering the default per-user process limit back to
> 80; I suspect it was raised for the sake of convenience for those who
> run huge numbers of server processes under a single UID (e.g. apache)
> but don't understand how to raise the resource limit,

Well, I didn't raise it and I don't know why whoever did did.

However, I suspect most NetBSD machines are single-user (in the sense
of being used by a single human, not in the technical sense of running
in single-user mode).  As such, the correct setting for the per-user
process limit is the number of process slots minus the peak root usage
you want to allow for.

On the machine I mentioned above where I had 44 processes, kern.maxproc
is 532.  With a per-user process limit of 160, that means 372 process
table slots are effectively reserved for root (of which maybe a dozen
are in use).  Since I do my process-consumptive work as myself, rather
than root, this is totally backwards, and in fact I have taken to
adding three lines very early in /etc/rc:

n=`sysctl -n proc.$$.rlimit.maxproc.hard`
sysctl -w proc.$$.rlimit.maxproc.soft=$n
sysctl -w proc.1.rlimit.maxproc.soft=$n

> Certainly it was a mistake to raise the *per-user* limit but not the
> *system-wide* limit, as each user can now consume twice as many slots
> in a table of limited size.

I'm not sure I agree with this, since the typical users-per-machine
ratio has been decreasing and I suspect is probably near 1 now, in
which case, as I remarked above, having the per-user limit plus the
peak root usage you want to allow for much less than the total process
table size is just plain wasteful.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B