From owner-freebsd-arch Fri Nov 10 5:19:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (mobile.wemm.org [202.12.86.17]) by hub.freebsd.org (Postfix) with ESMTP id 26AAC37B479; Fri, 10 Nov 2000 05:19:07 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eAADImW34016; Fri, 10 Nov 2000 21:18:49 +0800 (WST) (envelope-from peter@netplex.com.au) Message-Id: <200011101318.eAADImW34016@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alfred Perlstein Cc: Mike Smith , Matt Dillon , Warner Losh , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed In-Reply-To: <20001109144747.E5112@fw.wintelcom.net> Date: Fri, 10 Nov 2000 21:18:48 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Mike Smith [001109 14:35] wrote: > > > * Matt Dillon [001109 11:11] wrote: > > > > > > > > I'd recommend against the linux /lib + /usr/lib model, it's a big > > > > mess. I don't see much of a point in cutting the size of /bin and > > > > /sbin down, they are already fairly small (3.8M and 10M) and it > > > > isn't as though we need the disk space! The static nature of > > > > /bin and /sbin have saved me more times then I can remember. I als o > > > > have unfond memories of blowing /lib up under linux and not being > > > > able to do anything. > > > > > > root on a Linux box is unable to do squat when the machine is almost > > > out of memory because he can't map in /lib/libc.so to run 'ps' or > > > even another copy of bash. > > > > Um. And root on a BSD box is equally screwed when there's no memory left > > to map in the text segment of 'ps' which just happens to contain another > > copy of libc. > > > > The difference being that if libc is shared, it's already mapped in for > > the hundreds of other programs using it, so you're *better* off, not > > worse. > > The real difference here is that I've seen several instances of a > Linux box unable to cope with this situation and a FreeBSD box > cope. Linux locked up and FreeBSD 'gracefully' shot a process dead > and free'd up some memory. > > What "should" happen versus what _did_ happen doesn't make what > did happen untrue. Just because Linux is braindead in this regard, doesn't mean we have to be too. BTW: kill is a shell builtin command. The real memory requirement is from forking. If linux chooses to get silly about denying mmap() but still allowing fork and copy-on-write, then that is their problem. Besides, having a shared libc is a win for memory because you get the same physical pages mapped in over and over again, rather than having many many seperate copies of libc mapped into different processes with no sharing. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message