From owner-freebsd-current Sun Jun 27 15: 0:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id A84F014DD7 for ; Sun, 27 Jun 1999 15:00:26 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA17603; Sun, 27 Jun 1999 15:00:19 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37769EF5.F5C21AED@gorean.org> Date: Sun, 27 Jun 1999 15:00:21 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "Brian W. Buchanan" Cc: freebsd-current@freebsd.org Subject: Re: /etc/defaults (Was: Re: Out of file descriptors ??) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian W. Buchanan" wrote: > > A nice semi-solution to this problem of having to copy lines from > defaults/rc.conf would be a good curses-based rc.conf configuration tool. Yes, this would be an excellent idea. However to save you time, I'll expound the 3 different areas of argument that always cause this project to stall: 1. GUI platform curses tcl/tk web/cgi other 2. Data storage pattern flat file multiple flat files database sub arguments, what type of database data storage location 3. How to interface 1. and 2. with the installation/upgrade procedure Many arguments here, all depending on what choices people prefer for 1. and 2. You can find much detail about this in the archives, however each time the discussion comes up it spins and spins, but never lands, so we continue to do nothing. I released mergemaster in part to try and light a candle instead of continuing to curse the darkness, and in part to show that it's not impossible to update the rc's (in particular, although there are other important file update issues) within the current system. Then /etc/defaults came along, and, well... I think I've said enough about that already today. :) What this boils down to is, code talks. The possible designs have been discussed to death, it's time for someone to write something. Of course that'll get ripped apart too, but at least we'll have somewhere new to start from. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message