K. K. Subramaniam  wrote on Thu, 20 Aug 2009 18:19:24 +0530
> On Thursday 20 Aug 2009 8:05:14 am Jecel Assumpcao Jr wrote:
> > All of the tools that created the bits in the first place, as well as
> > the tools to change them are inside the same image as the bits. So I
> > don't agree with your analogy.
> I think a better analogy is the way public key cryptography certificates are 
> constituted. What matters is not whether a certificate is encoded in ASCII or 
> binary but whether there is a chain of trust. Should anyone lose their 
> certificate, it can be reconstituted from its parent cert in the chain. But if 
> you happen to lose a root cert then no new chains can be reconstituted. You 
> are stuck with the existing chains originating from this root.

Hmm... I didn't understand this analogy very well. Don't certificates in
the middle of the chain also involve a pair of public/private keys? If
so, it seems to me that losing the private key in the middle would be as
fatal as losing the root one (though it was affect fewer people).

Was the analogy about how a chain of certificates is like a chain of
images (starting all the way back from Smalltalk-76)?

> The key tools for a 'binary' encoding are the equality and diff tools. Given 
> two images A and B, check if they are equivalent. If not, find the difference D 
> that will reconstitute B from A.

This is what the Debian guy was asking for, but the idea was to convert
images into some kind of XML and then use traditional text diff to deal
with that. I used to have great success with diff but in the past few
years its results have become useless for me (probably some default
settting has been changed and I would have to force it to work the old
way), so I am not sure about the value of this approach. A tool that
actually understood images, as you proposed, might work better. It
wouldn't be too easy to write, however (see other thread about object
identity).

-- Jecel