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

Mike Meyer <[EMAIL PROTECTED]>                      http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

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

Reply via email to