From owner-freebsd-arch Thu Nov 9 11:34:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C248537B479 for ; Thu, 9 Nov 2000 11:34:08 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eA9JY6g21572; Thu, 9 Nov 2000 12:34:07 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43258; Thu, 9 Nov 2000 12:34:06 -0700 (MST) Message-Id: <200011091934.MAA43258@harmony.village.org> To: Matt Dillon Subject: Re: The shared /bin and /sbin bikeshed Cc: Peter Wemm , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 09 Nov 2000 11:22:35 PST." <200011091922.eA9JMZR10926@earth.backplane.com> References: <200011091922.eA9JMZR10926@earth.backplane.com> <200011091909.eA9J9wM10639@earth.backplane.com> <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091915.MAA43115@harmony.village.org> Date: Thu, 09 Nov 2000 12:34:06 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011091922.eA9JMZR10926@earth.backplane.com> Matt Dillon writes: : Ah, for flash booting turnkey solutions... I see the benefit! But : wouldn't something like /stand's all-in-one binary with hardlinks : for most common boot/recovery options be an even better solution? Not always. While you tend to get the absolute smallest system that way, you do pay a price. They are a bit PITA to upgrade individual parts of the system in place (which is sometimes required). It is also harder to layer together different products that way since you pay a big price for each static binary you want to put on the disk. With shared libaries you just add the binaries. We also run to run the same binaries on different systems and don't want to have to regenerate one monolithic binary. And the size savings isn't that huge. It is for similar reasons that we don't do a compressed MFS image for the whole thing. Our volumes are not high enough to deal with those headaches. Also, we need as much ram as we can get for our apps. Some of our boards are maxed out right now. If our volumes were a lot higher, and our margings smaller, I'd likely be shooting at a 2M-4M PicoBSD image. Discounting the RAM issue. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message