From owner-freebsd-current@FreeBSD.ORG Mon Jun 20 08:56:01 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1A8A16A41C; Mon, 20 Jun 2005 08:56:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 989A343D53; Mon, 20 Jun 2005 08:56:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 0FA4346BA3; Mon, 20 Jun 2005 04:56:01 -0400 (EDT) Date: Mon, 20 Jun 2005 09:58:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Garance A Drosehn In-Reply-To: Message-ID: <20050620094835.Q19830@fledge.watson.org> References: <20050619155228.Y6413@fledge.watson.org> <66959.1119209763@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: gnn@FreeBSD.org, Poul-Henning Kamp , current@FreeBSD.org Subject: Re: Summary: experiences with NanoBSD, successes and nits on a Soekris 4801 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2005 08:56:01 -0000 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