From owner-freebsd-small Tue Jan 25 13:41:21 2000 Delivered-To: freebsd-small@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6F64B153A8 for ; Tue, 25 Jan 2000 13:40:57 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA07576; Tue, 25 Jan 2000 14:40:53 -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 OAA06561; Tue, 25 Jan 2000 14:40:42 -0700 (MST) Message-Id: <200001252140.OAA06561@harmony.village.org> To: Greg Lehey Subject: Re: New approach to picobsd Cc: "Jeffrey S. Sharp" , freebsd-small In-reply-to: Your message of "Wed, 26 Jan 2000 07:58:25 +1030." <20000126075825.C42227@freebie.lemis.com> References: <20000126075825.C42227@freebie.lemis.com> <3888D5CF.329989@achtung.com> <20000122145538.A390@mojave.worldwide.lemis.com> <20000124122024.A4574@horus.co.jyu.fi> <20000125103358.U2643@mojave.worldwide.lemis.com> <005f01bf66f4$05a499f0$0dea5e18@mmcable.com> Date: Tue, 25 Jan 2000 14:40:42 -0700 From: Warner Losh Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been running an uncompressed FreeBSD 3.3ish system in 8-10M of FLASH with MFS for /tmp and other mountpoints (ala rc.diskless). The programs page in off of FLASH and it seems to be fast enough for what we're doing. I have a crude script that builds this from the buildworld tree. I was thinking of creating a release/nanobsd that was based around that script, but that would be too confusing. :-) While it does raise our cost a little to do things this way, we gain a lot more flexibilty. Also, the control programs that are on top of the FreeBSD install can get to be large, so we're running with 64M parts. We're not doing this in large quantities, and the customers are paying us enough that the cost differential per unit isn't worth the extra engineering time. If we were doing this in huge quantities, then we'd likely spend the $$$ to reduce things even further. Until recently, the biggest pole in the tent was termcap{,.db}, but we have an ultra small termcap that we use now that just has cons24, ansi, dumb, xterm and vt100 in it. Something like 1800bytes. Looks like MUNGED TECO macros since I eliminated all white space, long names, newlines, etc. Now there are other big poles, the kernel being first in the list now. Too bad we can't get rid of NFS for this project, that would save another 300k. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message