Date: Mon, 08 Jun 1998 23:15:43 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Jun-ichiro Itoh <itojun@itojun.org> Cc: hackers@FreeBSD.ORG, tech-jp@jp.freebsd.org Subject: Re: new config Message-ID: <2238.897372943@time.cdrom.com> In-Reply-To: Your message of "Tue, 09 Jun 1998 13:21:42 %2B0900." <9929.897366102@cardamom.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2238.897372943>