Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Jan 2006 14:34:54 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        phk@phk.freebsd.dk
Cc:        small@freebsd.org, sam@errno.com, rwatson@freebsd.org, current@freebsd.org, rizzo@icir.org
Subject:   Re: [RFC] what do we do with picobsd ? 
Message-ID:  <20060131.143454.76964518.imp@bsdimp.com>
In-Reply-To: <3281.1138742578@critter.freebsd.dk>
References:  <20060131.131654.134137067.imp@bsdimp.com> <3281.1138742578@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <3281.1138742578@critter.freebsd.dk>
            "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: In message <20060131.131654.134137067.imp@bsdimp.com>, "M. Warner Losh" writes:
: >In message: <43DFC2D5.7040706@errno.com>
: >            Sam Leffler <sam@errno.com> writes:
: 
: >Since I've started working on the bring up on an ARM based board, I've
: >been wanting something that is easy to work with and that worked.  I
: >think it would help us a lot in the embedded space if we had something
: >integrated into the base OS to do this stuff.
: 
: I agree.  I think we need to be much more inclusive in our concept of
: a 'release' than we are now.
: 
: As I see it, PicoBSD with its "additive" approach would cover the
: low-capacity (<32 MB ?) range, NanoBSD with its "subtractive" approach
: takes over from there, FreeSBIE covers the "don't touch my disk"
: range and finally the full blown release as we know it.

I tend to agree.  For our build system, we take the additive approach
without the crunchgen step...  Given the price points for various
parts on new projects I'm working on, we may need to move more towards
a crunchgen and/or pure RAM disk...  Having different alternatives
helps us a lot and makes it easy to continue to deploy FreeBSD systems.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060131.143454.76964518.imp>