On Sun, Aug 13, 2006 at 03:36:55AM -0400, Daniel Hagerty wrote:
> > In fact, it seems that isconf will blow up if anybody forgets to make
> > changes using isconf at all (vs. restoring the machine to the known good
> > state).
> >
> > Am I missing something?
>
> No, you aren't.
>
> It's a pretty standard problem for sysadmin tools in this space.
Dan, there's got to be some general way of saying this; I think while
either lambda calculus or turing machines can *illustrate* it, they
still don't say *why*.
I'm starting to think that a closer explanation might be something
like:
A machine can be described as a directed graph. The disk states
are nodes, the changes are edges. You can't go backwards along an
edge -- there can be no "undo". You might theoretically be able
to reach a prior node by some other path, but there is no general
solution for generating the code that implements those reverse
edges. Each edge transition -- in any direction -- must be
individually tested to verify that is has reached the desired
node. In the case of normal transistions, this is known as
"testing before production rollout". In the case of reverse
transitions, the resulting disk state must inspected to ensure
that it is indeed the prior state, and not some new node in the
directed graph. Creating the transition code for each reverse
edge, and performing the inspection to ensure that the code
re-creates the prior state, will always be more expensive than
just hitting the big "reset" button and rebuilding the machine
back to the starting state, then replaying the forward edges until
the desired node is reached.
There --- the entire Turing Equivalence paper in one long paragraph. ;-)
And I like the fact that this is starting to sound a lot like plain
old ordinary state machines.
Steve
--
Stephen G. Traugott (KG6HDQ)
Managing Partner, TerraLuna LLC
stevegt@TerraLuna.Org -- http://www.t7a.org