As a side note, one of the letters mentioned that these types of security
measures would make the system "inconveniently secure". For regular
desktop machines, I agree. For that reason I would say leave the
defaults as they are now. No need to make the default MAX_USER_TASKS =
32 like it is on my system. But, in my case, it is a FAR GREATER
inconvenience to get paged at 4:00AM to come in and reboot a system taken
down by a fork bomb than it is to modify some defines about maximum user
tasks and (hopefully in the future) maximum user memory.
This leads me to my second thought. Since most people wouldn't need to
modify these defines and make their system inconveniently secure, then I
formally withdraw the suggestion of "make tune". Instead, make the
ktune.h file sufficiently commented as to dependencies that a reasonably
experienced person can vi the file and make the changes necessary, but
new users not aware of what they are doing won't break their system by
running make tune and changing things to unreasonable, unuseable values.
The only other option would be to put warnings around make tune so that
new users are aware that they can render their system unbootable by
fiddling with these values, or you would have to check values for
problems in the process of changing them and disallow any values out a
certain range (such as too few tasks or file handles). This, in turn
would greatly increase the complexity of the make tune function I believe.
*****************************************************************************
* Doug Ledford * Unix, Novell, Dos, Windows 3.x, *
* dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician *
* PPP access $14.95/month *****************************************
* Springfield, MO and surrounding * Usenet news, e-mail and shell account.*
* communities. Sign-up online at * Web page creation and hosting, other *
* 873-9000 V.34 * services available, call for info. *
*****************************************************************************