Subject: Re: proposed: changes to "etc" (?)
To: Curt Sampson <>
From: Michael L. VanLoon -- <>
List: tech-kern
Date: 12/16/1997 23:04:49
>On Sun, 23 Nov 1997, Martin Husemann wrote:

>> > The problem with ODM and Windows registry is that they can easily
>> > become trashed to the point where one must re-install the OS.
>> "Easily" must be relative to your point of view.

>As I've stated before, I've used the Novell bindery extensively,
>and had a moderate amount (more than I care to have had) with the
>Windows registry. Both have been more unreliable than a Unix /etc
>directory by a good order of magnitude.

There is not a "Windows registry".  Be careful about lumping Win95
into the same boat as WinNT.  There is a world of difference with
regard to stability and general robustness, and the majority of the
code base is not shared between the two.

If your complaint, however, is that the registry is "unreliable"
because of the way software stores data in it (i. e. a program can
stomp something another program considers important), then I think you
are mis-using the term.

>> And of course, you
>> should backup essential stuff like this ;-)

>How? Let's say settings for application A get trashed on Tuesday,
>but you don't know yet that it's happened. On Wednesday you install
>application B, which makes a whole pile of changes to the registry.
>On Thursday you realise that application A was trashed, but you
>can't restore the whole registry as of Monday, because then you
>blow away your application B changes. This sort of situation is
>what I'm constantly having to deal with when I work with registries.

Write something that can take a registry "snap-shot", and diff
snap-shots from before and after.  There are already a few commercial
programs that will do this for you.

And, in your example, it seems to me you'd either live with
application B's changes, or roll back to A and nuke B altogether.  If
there is a clash, it's possible they can't co-exist.

In reality, I've seen relatively little of this happen, since
application data is generally stored under a vendor-specific key, and
most competent vendors are capable of keeping their own software
co-existing within their own subset of the registry.

But I'm sure everyone has a different set of experience, and just one
bad "application" can make for a lot of pain.  We may see more of this
as more and more applications try to supply a common set of
"services".  Though this will probably happen on a whole larger scale,
such as a distributed directory.

  Michael L. VanLoon                 
      Contract software development for Windows NT, Windows 95 and Unix.
             Windows NT and Unix server development in C++ and C.

        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
        Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
    NetBSD ports in progress: PICA, others...