From owner-freebsd-current Sun Feb 3 18:15:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from hsd.com.au (CPE-144-132-42-44.vic.bigpond.net.au [144.132.42.44]) by hub.freebsd.org (Postfix) with ESMTP id 11B3D37B41E for ; Sun, 3 Feb 2002 18:15:45 -0800 (PST) Received: from ariel by hsd.com.au with SMTP (MDaemon.v3.0.1.R) for ; Mon, 04 Feb 2002 13:13:48 +1100 Reply-To: From: "Andrew Cowan" To: "Mike Meyer" , "Terry Lambert" , "Juha Saarinen" Cc: "Brian T.Schellenberger" , "Wilko Bulte" , "Paul Fardy" , , Subject: RE: Junior Annoying Hacker Task Date: Mon, 4 Feb 2002 13:13:47 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15452.50112.625066.914576@guru.mired.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MDaemon-Deliver-To: current@FreeBSD.ORG X-Return-Path: andrew.cowan@hsd.com.au X-MDRcpt-To: stable@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG How about editing the rc.conf file from the proposed virc program, that would then re-generate the rc.conf file upon saving. Of course the virc would store the underlying configuration in an xml config file.. That should make Kutulu very happy :) However, I have previously thought that a system that used xml files to store application configs (that would then be used to generate valid conf files) would be useful. It would allow gui tools to be easily designed for system administration. Cheers, Andrew > > Terry Lambert types: > > I guess NIH beats an idea to death, even if the original > > implementation bears no resemblence to the current one. > > The problem with the registry is not that it's a single place that > tries to control everything. The problem with the registry is that you > have to have a large chunk of the system functioning in order to fix > things in it should it break - which, from what I've seen, happens all > to frequently. Compare this to unix, where all you need is the kernel, > init, sh and ed - and sufficiently clever people may be able to do it > without init. > > I offer AIX as an example. IBM decided that all those silly flat text > files in Unix was a bad idea and replaced them with object > database. They didn't put everything in one big file like Windows > does, but grouped them "logically", meaning the grouping was unrelated > to the flat text files unix admins used to know. Of course, each > different db used a different command, with a different syntax, to > edit the db. I guess if you're going to make old knowledge useless, > you might as well be thorough about it. > > What this meant in practical terms was that fixing the system required > all the db mechanisms to be working, plus either the man pages or > menu-driven admin tool to be working in order to fix a broken system. > > And that was one of the better features of AIX. > > Juha Saarinen types: > > On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: > > Then again, the registry is the epitome of all that's counter-intuitive, > > awkward and generally oh-why-does-it-have-to-be-like-this. > Maybe it should > > be ported to FreeBSD? ;-)))) > > I haven't followed the thread, so apologies if this is repeated. I > think having menu-driven front end for editing *.conf files - right > now, that would be rc, make, pccard and periodic - isn't such a bad > idea. Nothing about the current behavior needs to change. It's no > worse than letting people use the sysinstall disk management subsystem > rather than fdisk and disklabel. > > Ideally, it would read all of /etc/defaults/*.conf for a description > of each such file. When you chose to edit that file, it would read the > contents for the list of variables and what they do - in the comments > - along with the default values, then get the current values from the > appropriate file in /etc. That means the tool doesn't get out of sync > with the files - except for maybe make.conf. It would require > reworking the comments in the files in /etc/defaults, and a little > more discipline in editing them, but that's not necessarily a bad > thing. > > -- > Mike Meyer http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message