From owner-freebsd-hackers Tue Jul 13 17: 5:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 77F901535C; Tue, 13 Jul 1999 17:05:27 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id JAA27957; Wed, 14 Jul 1999 09:04:14 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id JAA04943; Wed, 14 Jul 1999 09:04:12 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id JAA15623; Wed, 14 Jul 1999 09:04:13 +0900 (JST) Date: Wed, 14 Jul 1999 09:04:13 +0900 (JST) Message-Id: <199907140004.JAA15623@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132253.PAA81615@apollo.backplane.com> References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> <199907132253.PAA81615@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 15:53:43 -0700 (PDT), Matthew Dillon said: > ... a situation which will never occur if you are managing the memory > through your own custom library. Therefore not relevant. Hm. It's misunderstanding. I don't agree with you about the following point. Thus, the situation might happen. > Give me a shell and I can crash any machine. If you are assuming > hostile users, you cannot assume that your magic overcommit protection > will save your server. Saying that the kernel and application behave > properly is a cop-out, because it's virtually impossible to guarentee > that for every situation. The chance of a user blowing up the server > by finding a bug or a hole somewhere is much, much greater then the chance > of a user running the system out of swap. If you are trying to say that it is easier to crash FreeBSD than the system out of swap. You might be wrong. Memory consumption is quite easy, almost every programmer can do it with normal user privilege. If there is a bug which crashes FreeBSD and which is easier to write than memory consumption, it is better to fix the bug. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message