[Infrastructures] state machines

Wesley Craig wes@umich.edu
Wed, 20 Sep 2006 15:13:39 -0400


On 20 Sep 2006, at 02:32, Daniel Hagerty wrote:
>> Without getting into "which is better," which is more likely to have
>> the CNAME dependency problem?
>
>     I believe we've covered this already.  Either can demonstrate the
> problem in the end result.
>
>     Any path involving execution has an additional peril of
> demonstrating this flavor of problem during execution.  The math that
> demonstrates the relatively complexity of the two is trivial, should
> we need to see it.
>
>     In truth, even the straight up restore image has an execution
> phase subject to all the usual perils, but I think we can take it as a
> given that it works in practice.

I've read the three paragraphs about three times now.  I get "running  
the log is more likely to produce the CNAME problem."  Please do  
correct me if I've read that wrong.

>     That is not a handwave, I just write coming from a highly
> abstracted thought process.
>
>     An image backup is a representation of "what" where the "how" that
> produced the what is lost.  This is both its strength, and its
> weakness.  By contrast, an execution method produces that "what" from
> the "how", leaving both to be inspected, debugged, etc.

The execution method starts with "what-1", executes "how" to produce  
"what-2".  Without being able to more or less fully inspect "what-1",  
you're not going to have too much idea about "what-2", despite the  
relative clarity of "how".  What if "how" were a simple patch to  
"what-1"?  I will grant you that having "how" as a clear delta  
between "what-1" and "what-2" can be handy for deeper analysis,  
particularly if it's reversible.

>     Do you disagree that the removal of potentially essential
> information increases an image's opacity while also making it simpler?

If I were removing essential information, I would probably be  
increasing an image's opacity.  But it's a presumption that essential  
information must be destroyed.

:wes