From owner-freebsd-arch Tue Feb 20 2:58:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id BE8F737B491 for ; Tue, 20 Feb 2001 02:58:41 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id DAA25219; Tue, 20 Feb 2001 03:52:29 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAx_aioX; Tue Feb 20 03:52:26 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id DAA14109; Tue, 20 Feb 2001 03:58:36 -0700 (MST) From: Terry Lambert Message-Id: <200102201058.DAA14109@usr05.primenet.com> Subject: Re: Moving Things [was Re: List of things to move from main tree] To: dot@dotat.at (Tony Finch) Date: Tue, 20 Feb 2001 10:58:35 +0000 (GMT) Cc: jkh@winston.osd.bsdi.com (Jordan Hubbard), arch@FreeBSD.ORG In-Reply-To: <20010220100445.A35619@hand.dotat.at> from "Tony Finch" at Feb 20, 2001 10:04:45 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This whole thing -- splitting the OS up into a bunch of small > independently-selectable packages -- sounds exactly like the way > Debian works, except I expect FreeBSD would have more emphasis on > using a revision control system for at least the core components > rather than a ports-like collection of random patches. An important point in configuration management, which SCO and Solaris, et. al. have addressed, but which has so far been missing from this discussion is the "binary upgrade" scenario; I think one of the primary design goals has to be, if not to support it, at least to not preclude it being supported later. A nice-to-have would be the ability to "save" the state of a machine, as in "as this machine is currently configured". This probably would exclude configuration data, and be limited to just what was installed. A centralized configuration store would let you include configuration data, which would be potentially impossible otherwise. I expect that you would want to not include IP address or machine name or other per machine static data, but you might include "boots to a KDE login screen" or "uses DHCP to get an IP address". I can't see that being possible, given arbitrary configurations files in arbitrary locations all over the firmament. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message