From owner-freebsd-arch Thu Nov 9 11:22:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 97AF937B479 for ; Thu, 9 Nov 2000 11:22:49 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA9JMZR10926; Thu, 9 Nov 2000 11:22:35 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 11:22:35 -0800 (PST) From: Matt Dillon Message-Id: <200011091922.eA9JMZR10926@earth.backplane.com> To: Warner Losh Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091909.eA9J9wM10639@earth.backplane.com> <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091915.MAA43115@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200011091909.eA9J9wM10639@earth.backplane.com> Matt Dillon writes: :: 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 also :: have unfond memories of blowing /lib up under linux and not being :: able to do anything. : :In the general case I'd agree with you. Disk is cheap. And almost :all system have split / and /usr. : :In the small, embedded world, however, reducing the 4.1M and 12M to :600k and 1200k respectively is a huge win. We at Timing Solutions run :FreeBSD in 16M or 32M or 64M parts where an extra 6M is a huge win. :Especially on the 16M part. The minimal system that I had went from :14.7M to 7.9M which pushed the 16M part from being useless to being :useful (we have about 6M of binaries and sundries that go onto these :systems). : :I also plan on putting together a small 16M X terminal for the iopener :with this if all goes well. : :Warner 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? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message