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]> 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