Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!hookup!swrinde!sgigate.sgi.com!atha!unixg.ubc.ca!news.bc.net!felix.junction.net!okjunc.junction.net!michael From: michael@okjunc.junction.net (Michael Dillon) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: The Future of FreeBSD... Date: 13 Aug 1995 07:41:58 GMT Organization: Okanagan Internet Junction, Vernon B.C., Canada Lines: 58 Message-ID: <40kac6$aqb@felix.junction.net> References: <3uktse$d9c@hal.nt.tuwien.ac.at> <40gf8q$ddv@hamlet.m-u-b.de> <40if2r$ntj@news.bu.edu> <40j92s$unh@nntpd.lkg.dec.com> NNTP-Posting-Host: okjunc.junction.net >>My full support! Having to deal with Windows NT at work, I know, what >>happens when, say, Registry gets screwed -- the whole damn thing may >>not come up! Even if this happened to be an Intell machine, and you, >>accidentaly have a DOS installed -- you can not go and fix NT from it -- >>Registry database is in a binary form (unlike .ini files of plain old >>Windows). You may very well end up reinstalling the whole OS. >Absolutely agree. However to make BOTH manual and GUI setup >easier perhaps a globally based single keyword file otherwise >parsing becomes a nightmare. If desired the GUI tool (or vi) >can be used to modifiy the keyword file. Then if desired the >various "standard" files could be generated automatically. Let's look at it this way. The NT and VMS idea of a single central registry for all system and application configuration parameters is an EXCELLENT idea. You always know where to find things and ideally you can integrate a hypertext help system with the single configuration editor tool. But, as we all know, it complicates backwards compatibility and makes it hard to build special purpose tools that manipulate the configuration. In complex networks or anywhere you have a skilled admin working on a systems, it is usually easier to deal with plain text config files. The way that everybody can win here is to keep all the plain text config files and implement the registry system as well. The fundamental concept of a registry is that there is one program that can manage all configuration settings. So lets keep that part of the registry system but build it on top of the existing base of multiple text config files. The central registry file would be a directory containing multiple plain text config files, each one of which would define the layout and location of an existing UNIX config file. This would be something akin to a Macintosh resource file with definitions of fields, dialog boxes and all the user interface for managing and editing that particular config file from a GUI environment as well as the procedure for making the config take effect since note everything accepts kill -HUP. Anybody that wishes to ignore the registry system can do so and everything will operate fine. When that admin moves on a nd a new admin comes on the job, the registry system will still be ready to use because it is based on existing files. I'm not saying this will be easy because there are several interesting challenges I can see in building such a system such as preserving comments in config files and especially, what if someone uses vi to comment out a section of the config? A registry user should be able to see the comment and should be able to tell the registry to add that commented section back in at which point the registry program would need to distinguish commented out entries from real comments.... But if this is done it will go a LONG way to making UNIX palatable to the masses of barely computer literate admins who are now running much of the worlds computer and network infrastructure. -- Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com