Well, it depends on what you mean by `unified.' If you mean a
database of some sort that's more unified than a bunch of files in
/etc, one for each application, then no, I don't want to see that.
As soon as you get into a unified single database it becomes *very*
hard to track exactly who has made what changes and where. And, of
course, such a thing tends to be difficult to maintain in text
format anyway. There is, of course, no question of using any other
format, since that would go right against the unix philosophy and
make the standard tools we already have (sed, grep, etc.) useless
for manipulating it.

cjs

Curt Sampson    cjs@portal.ca	   Info at http://www.portal.ca/
Internet Portal Services, Inc.	   Through infinite myst, software reverberates
Vancouver, BC  (604) 257-9400	   In code possess'd of invisible folly.

On Mon, 8 Dec 1997, Matthew Jacob wrote:

> Date: Mon, 8 Dec 1997 10:21:24 -0800
> From: Matthew Jacob <mjacob@ns.feral.com>
> To: jimw@numenor.turner.com, cjs@portal.ca
> Subject: Re: HSM deisgn goals was: RE: HSM implementation proposal
> Cc: tech-kern@NetBSD.ORG
> 
> 
> I'm sorry, but I think the two of you are mixing method (implementation) with
> intent (architecture). Personally, I don't much care whether you can use
> ed, vi, emacs, vmr (for those old RSX11 types out there), or twist the
> heads off of pigeons kept in a cage by the server, in order to establish
> in a unified and rational fashion persistent system properties, and further,
> properties that can be changed without rebooting the system.
> 
> It's this thing that end users probably care about- not whether the
> tool to do the job has this bogus little daemon stamped on the metal
> case, no?
> 
> 
>