From owner-FreeBSD-tech-jp@jp.freebsd.org  Tue Jun  9 15:16:51 1998
Received: (from daemon@localhost)
	by jaz.jp.freebsd.org (8.8.8+3.0Wbeta13/8.7.3) id PAA03758;
	Tue, 9 Jun 1998 15:16:51 +0900 (JST)
	(envelope-from owner-FreeBSD-tech-jp@jp.FreeBSD.org)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
	by jaz.jp.freebsd.org (8.8.8+3.0Wbeta13/8.7.3) with ESMTP id PAA03740
	for <tech-jp@jp.freebsd.org>; Tue, 9 Jun 1998 15:16:39 +0900 (JST)
	(envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1])
	by time.cdrom.com (8.8.8/8.8.8) with ESMTP id XAA02244;
	Mon, 8 Jun 1998 23:15:44 -0700 (PDT)
	(envelope-from jkh@time.cdrom.com)
To: Jun-ichiro Itoh <itojun@itojun.org>
cc: hackers@freebsd.org, tech-jp@jp.freebsd.org
In-reply-to: Your message of "Tue, 09 Jun 1998 13:21:42 +0900."
             <9929.897366102@cardamom.itojun.org> 
Date: Mon, 08 Jun 1998 23:15:43 -0700
Message-ID: <2238.897372943@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Reply-To: FreeBSD-tech-jp@jp.freebsd.org
Precedence: bulk
X-Distribute: distribute [version 2.1 (Alpha) patchlevel=24]
X-Sequence: FreeBSD-tech-jp 1501
Subject: [FreeBSD-tech-jp 1501] Re: new config 
Errors-To: owner-FreeBSD-tech-jp@jp.freebsd.org
Sender: owner-FreeBSD-tech-jp@jp.freebsd.org

> 	If something is already decided about this topic, please give me
> 	some pointer for the discussion archive.  I do not want to spend
> 	my time to this, if it will never be merged into.

Well, every time this comes up, a number of folks chime in with "but
config(8) is fundamentally WRONG!  We must get rid of it entirely, not
upgrade it!" and it is my suggestion that you simply ignore all of
those people and go right on ahead with this idea.

The reason I suggest ignoring them has to do with the fact that it's
exceedingly easy to point out the flaws in config(8) but obviously not
so easy to architect a complete replacement or someone would have done
so by now.  Note that I'm not even talking about an implementation,
I'm talking about a reasonable attempt to even _architect_ such a
thing.  I've seen many a pie-in-the-sky treatise go by about how
things ought to work, but not much which really went into significant
detail on how a migration away from config(8) should be done and a
sample timeline showing which tasks will need to be done and in what
order.

If the NetBSD/BSDI folks have improved config(8) to the point where
it's signficantly more usable, I don't see the harm in going in that
direction.  If the new-paradigm weenies also want to use that as a
sufficient goad to get them to really implement a complete
replacement, then that's pretty much a win too since nothing else
seems to be motivating them these days.

- Jordan
