The Law Of Mutating Binary Images

: Wherever mutating binary images are employed, there will exist components in the image which cannot be generated from source code or other textual representation.

The discussion that inspired this was (in regard to Smalltalk):

...many significant instances of various classes were impossible to create from source code -- they had been hand-munged from earlier development images, during initial bootstrap. The root of the process tree, for example, was an instance of Process that lived for more than a decade. I am under the impression that a ceremony of sorts was held when it finally died.

I hadn't heard that, but had always assumed so, because such things always seem to happen to non-static binary images that are not continually regenerated from source, no matter what kind of image it is. (This should be somebody's law.)

For a bit of historic context: The SmalltalkLanguage was originally like this.

When major changes were needed to the image, such as for changes to the floating point representation, they customized operations to "serialize all objects to disk" and to restore them.

I came to this page expected something about inevitable corruption seeping in as well. Imagine your hard drive as a mutating binary image containing, among other things, your Operating System, and note that every single OS image, if in constant use from installing and uninstalling programs, will eventually decay. Various OSs do so at varying rates under varying usages, but unless you freeze the image at some point, it will decay past some point of usability.

Bit rot is implied, yes. But not necessarily past the point of usability -- not if people are willing and able to patch the binary, which happens way more than most people realize.

The KeyKos folks report never having had a significant problem with this in a system with OrthogonalPersistence, which raises much the same issues:

<http://www.agorics.com/Library/KeyKos/checkpoint.html>

Because the important state of a KeyKOS system is held not just in files, but in a complex network of objects and capabilities, it is particularly important to ensure that the entire state of the system can be safely recovered under any conditions. In the 17-year history of KeyKOS, the only cases in which a damaged system state was checkpointed occurred as a result of kernel development and testing. The KeyKOS kernel is now a mature technology, and failures of this type have not been seen for years. There has never been a need for a data recovery utility such as UNIX's fsck. For off-site backup and disaster recovery, tape checkpoints are recommended.