From owner-freebsd-hackers Tue Jul 13 15:23: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 3C571150B4 for ; Tue, 13 Jul 1999 15:22:47 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id PAA24683; Tue, 13 Jul 1999 15:22:33 -0700 (PDT) Message-Id: <199907132222.PAA24683@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 15:22:33 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 14:56:52 -0700 (PDT) Matthew Dillon wrote: > Jason, I am using real life situations to demonstrate my point. You are > perfectly welcome to use your own REAL-LIFE situations to demonstrate > yours. It is the real-life application that matters, not a worst-case > nightmare theory. No engineer designs systems based on nightmare > theories. Yes, you're using your own REAL-LIFE situations, from a large ISP, using systems for a few specific server applications, where you have the space to put lots of disk, etc. The things I'm thinking of aren't even necessarily "large server" applcations. NetBSD runs on a CPU that is *often* used in small embedded applcations -- the StrongARM. NetBSD also runs on the Hitachi SH3, another popular embedded processor. An an example of the latter case, NetBSD is actually the OS software running in a *camera* made by a company in Japan. If you can run on a camera, you can run on a lot of other small appliances too (this isn't a stretch). You might be running on a cash register (err, well, those new-fangled touch-screen "transaction terminals"). This isn't a stretch, either. You might be running on a set-top box (nor is this a stretch; hell, I have one of these in my living room, and it's capable of booting the OS from ROM card -- who needs a diskless server? :-). We're talking about systems which just don't have a lot of disk space (in fact, NO DISK AT ALL), but may be running software which is designed to gracefully deal with memory allocation failures. What do you have against giving people the flexibility of preventing overcommit? -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message