Summary: experiences with NanoBSD, successes and nits on a
Soekris 4801
Robert Watson
rwatson at FreeBSD.org
Mon Jun 20 08:56:01 GMT 2005
On Mon, 20 Jun 2005, Garance A Drosehn wrote:
>> If I may jump in here. One way to do the build up vs. cut down thing
>> is to break up more of the system into understandable chunks, but that
>> takes work. Then it's easier to build up a system from components.
>>
>> I'll take a look at nanonbsd hopefully this week anyways, as I need to
>> get it running in a VM as well as on a Soekris at home. I make no
>> promises. The last system I worked with that did a componentization
>> got it very very wrong.
>
> Another thing I was thinking about was that we could have more
> components which trim themselves down based on #defines for something
> like MINIMALIST_USER or MINIMALIST_USERBIN . I almost tried that with
> the recent changes to `env', for instance. The new options I added are
> very nice, but they do add something like 20%-40% to the size of the
> executable. And someone putting together a minimal system could easily
> avoid writing scripts that need the new options.
>
> If a user could set one #define to cause all programs in /usr/bin to
> shrink by 10-15%, that might be valuable. Not sure we could get that
> much, or if we would want to support that idea as time goes on.
Although then you have to wonder, if you can shrink byt 10%-15% without
functional loss, whether that shouldn't be the default :-).
I'm somewhat of the opinion that our flags should be of functional
granularity -- i.e., you identify functionality you either do or don't
want, and get a resulting subset. One of the complications to this is the
dependency concerns -- for example, because NanoBSD says NO_CXX, dhclient
breaks because it relies on devd.
I think we should avoid reaching for unreachable perfection, because if
nothing else, it means we'll never get anywhere. In particular, we should
try to identify incremental changes to our meta-data and build system,
rather than building large new XML-based frameworks that will have to be
created and then separately maintained from our current build
infrastructure. It seems like some obvious steps forward might be:
- Providing more complete NO_xxx functionality, identifying more
components that can easily be frobbed. I.e., I have local patches for
NO_ACL and NO_MAC that remove small but useful functional subsets that I
may get a chance to commit for 6.0, or may not.
- Try to figure out how to better differentiate build vs. install time
frobbing. For example, the NanoBSD NO_CXX concern: we want C++
applications, we just don't want to install the build chain.
Currently, we have no way to differentiate these concepts, since our
dependencies are entirely build-time, and our frobs have to match up
(generally) between build and install. I.e., devd is built only if
!NO_CXX, which is a build-time concern.
Robert N M Watson
More information about the freebsd-current
mailing list