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  :)

<I would like to remind viewers that I am just kidding>

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.


> Terry Lambert <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> --
> Mike Meyer <[EMAIL PROTECTED]>
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to