Re: Summary: experiences with NanoBSD, successes and nits on a Soekris 4801

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