Date: Mon, 20 Jun 2005 09:58:46 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Garance A Drosehn <gad@FreeBSD.org> Cc: gnn@FreeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@FreeBSD.org Subject: Re: Summary: experiences with NanoBSD, successes and nits on a Soekris 4801 Message-ID: <20050620094835.Q19830@fledge.watson.org> In-Reply-To: <p0621021dbedbfa4dd5ff@[128.113.24.47]> References: <20050619155228.Y6413@fledge.watson.org> <66959.1119209763@critter.freebsd.dk> <m2br613i8n.wl%gnn@neville-neil.com> <p0621021dbedbfa4dd5ff@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050620094835.Q19830>