Posted on by Rainer Gerhards

An old and possibly important text rediscovered…

Seventeen years old, raw “armchair philosophy” — but surprisingly close to what I still believe today.

While reflecting on my current work, I remembered a text I had written in April 2008 during a discussion with a friend in biology. It’s an unfinished “armchair philosophy” piece — raw, dense, and hard to read — but it still reflects many of my core beliefs about IT systems. I’m publishing it unchanged as an archival entry, because the foundations it sketches are still relevant today.

This was written nearly 20 years ago. I left it unchanged, because it shows my thinking as it was at the time. In the future I plan to revisit these ideas in more accessible form and explain how they connect to what I do today. Of course, my thinking has evolved — but the foundations you see here remain part of my tech philosophy.

A unified look at unanimated, animated and technical entities

Author: Rainer Gerhards <rgerhards@adiscon.com>

This paper tries to define some properties common to unanimated, animated and technical entities. This is done in the hope that such a unified look facilitates the adoption of principles known in one field onto another. The actual main target is to enable IT systems to be build based upon biological principles.

Entity

  • Entities have a recursive nature:
    • Every entity is a combination of a number of other entities (“sub-entities”), which it contains
      •  
    • Every entity is contained in another entity, the “super-entity”
      • This super-entity is also called the entities “environment”
    • This obviously leads to the well-known question if any entity exists that does not have a sub- or super-entity. For the purpose of this document, this question is ignored.
  • Entities whose sub-entities are organized in mostly the same manner belong to the same class of entities.
    • Some variations may exist in organization and type of sub-entities
      • As long as these variations are slight, the entity belongs to the same class; if the variations are sufficiently large, an entity belongs to a new class. There is no sharp border between the two.
    • Hierarchies of entity classes exists, where each class inherits properties from another class
  • Entities can only work within specific operational constraints
    • Environmental
    • Internal (? – really? Or a weird case of environmental abstraction?)
    • Some violation of regular operational constraints is acceptable, depending on
      • how far they are violated
      • how long they are violated
    • The quicker the change occurs and the higher the magnitude of change, the less likely an entity can tolerate the change.
    • A single entity will not be able to survive some high magnitude changes.
  • Entities are not perfect [? What is perfect? If we see a class of entities as something sufficiently close to each other, aren’t we biased? Let’s assume we’d define a class of entities to be only those that are exactly identical. In that sense, we would have perfection inside entity classes, but each individual would probably be its own class. This is impractical to work with. So we tolerate some variance inside individual entities, as long as all entities of a given class have sufficiently close properties – which then enable us to provide some operations on the class, and not individual entities. Of course, if we abstract incorrectly, we may even damage some entities, namely those whose properties are outside tolerance for a given operation. If we apply this view, it looks like there is no perfection at all. Entities are constantly evolving and only our perception of them would call them imperfect compared to an (arbitrarily defined) class.]
    • Imperfection occurs due to reproduction
    • Imperfection occurs due to environmental changes
      • The longer an individual entity exists, the higher the probability and magnitude of imperfection
    • [? Can one draw the conclusion that “old” individuals have a higher chance of reproduction failures due to the fact that they have a greater probability and magnitude of “imperfection due to environmental changes”? If so, would that mean evolution “speeds” up with increasing longevity of a class of entities? But, in contrast, isn’t increased longevity caused by the entity’s increased resistance to changes … well, maybe – lost the thought now, somewhat along the lines of “higher imperfection tolerance” – entities with higher tolerance against imperfection tend to live longer, which increases their potential number of descendants, but only if their ability to carry out the reproduction method does not decrease)]
    • They tolerate some degree of malfunction
      • May lead to (noticeable) operational degradation
      • Tolerable as long as the entities prime properties [definition?] are not damaged [?… as the entity does not violate its super-entities operational constraints (but then, isn’t that recursive, too?)/as long as the entity provides less operational degradation to its super-entity than the loss of this entity would cause (in which the super-entity, if operating correctly and capable to do so, may chose to terminate the degraded entity)]
    • Slight changes in interaction with sub-entities and super-entities cause “failures” inside the entities. Due to evolution, these may manifest over time.
  • Entities may move between environments
    • Constraint by availability of a transfer environment or tolerance against environmental differences during transfer
    • An entity may permanently exist in any environment that does not violate its operational constraints
    • An entity may temporarily exist in any environment that does violate its operational constraints in a tolerable manner; the entity may experience severe degradation of its functionality inside such an environment.
    • An entity cannot exists in any environment that violates its operational constraints in an intolerable manner
  • There is a finite set of sub-entities inside each entity, the “resources”
    • All sub-entities must be built from this pool of available resources.
    • Sub-entities may be recombined (requires death of some entities) to form new sub-entities. A recombination always requires sufficient resources to be available.
    • An entity may receive or lose some of its resources by interaction with its peers and the environment. Depending on the entity and/or the environment, such resource loss and gain may be easy and frequent or hard and infrequent.
    • Entities gained must not be beneficial for an entity (e.g. if harmful sub-entities are gained); similarly, loss of (harmful) entities may be beneficial for an entity.
    • Even the gain of harmful sub-entities may be beneficial to an entity, but only if it develops a capability to deal with the harmful effects (e.g. the harmful sub-entity may be destructed without causing harm and its resources will become part of the entities resource pool, in turn enhancing the ability to create new sub-entities [?real world example needed – is this true at all?]
  • Sub-entities within an entity have different levels of usefulness for the entity
    • Some sub-entities are required; the entity cannot exist without them
    • Some sub-entities are harmful; they degrade the entities primary function
      • In extreme cases, they may cause death of the entity
        • Due to direct destruction or transformation of the entity itself or its sub-entities
        • Due to modification in operations mode which let the super-entity consider the entity to be harmful and thus removal of it (caused by the super-entity)
    • Usefulness of sub-entities is not a digital good/bad switch
      • There exists several “flavors” of usefulness in between
      • For example, some sub-entities may be desirable (but acceptable if not present) while some may be undesirable (do not cause serious degradation if present, but better if not present)
      • “bad” sub-entities may turn out to be “good” ones under certain environmental changes
      • “bad” sub-entities may case evolution [?or are they even a perquisite?]
  • Entities interact with
    • Their environment
    • their sub-entities
    • Interaction of entities with their peers (inside a given environment) is just a special case of environment interaction [?]
    • ??Entities mostly interact with their direct sub- and super-entities, but interaction may also involve several layers at once

question to ask: how to explain the (chain of?) interaction(s) that occur if a cosmic ray damages RNA inside a cell?

  • IT sample: document loss due to lightning (someone is writing a manuscript and loses it due to lightning)
    • Lightning strikes public power converter station (lightning strike is a sudden, a too quickly environmental change, the entity “power converter” is operated outside acceptable operational parameters. This results in total malfunction).
    • The super-entity (power grid) notices [how? – e.g. out of band alert, operational parameter change] malfunction of one of its sub-entities. It decides whether this is acceptable (e.g. use a backup) or some degradation of operation is necessary. We assume there is no backup entity for that subpart of the power grid available. So the power grid reorganizes itself by shutting down the malfunctioning part. To do so, it interacts with its sub-entities and probably also needs to interact with its super-entities.
    • Power is shut down for parts of the network to prevent it from overload (higher-level entity protects its function by scarifying the least damage subsystem)
    • Computer does not receive any more power and fails (too-drastic and frequent environment change)
    • In-memory data is no longer refreshed and vanishes (computer has died – too drastic environment change)
    • Data element stored is lost

Growth

  • MISSING [questions to ask: When is an entity an entity? Does an entity grow in itself or is growth the continued destruction/construction of entities? How do technical systems grow?]

Reproduction

  • Entities reproduce via a reproduction method
    • The specifics of the reproduction method vary (potentially greatly) by entity class and individual entity
  • Reproduction requires
    • A sufficiently large number of entities
    • Availability of sub-entities
  • The better a class of entities can reproduce, the higher the chance of survival of this entity class
  • There exists a hierarchy of entity classes in regard to reproduction
    • Some entity classes cannot reproduce themselves
    • Some can reproduce themselves a limited number of times
    • ??Some cannot reproduce themselves, but can produce derived entity classes (that is, they can replenish supplies of derived classes, but cannot replenish themselves. Loss of these classes leads to loss of the derived classes, too.
    • ??Some classes can reproduce themselves and can also produce derived classes.
    •  
  •  

Evolution

  • Evolution requires that individual entities have a limited lifespan
  • Evolution requires imperfection and malfunction
  • To evolve, Entities must be able to reproduce
    • Only those entity classes can evolve which can natively reproduce themselvs.
      • Entity classes which can only support limited reproduction
  • Evolution never occurs on the individual entity level; instead classes of entities evolve
  • An evolved class of entities is able to co-exist with the entities that it evolved from
  • If the evolved class of entities [??has advantages over the class it evolved from??], the evolved class will reproduce better than the one it evolved from.

Death

  • An entity dies when it is deconstructed in a way that makes it impossible to reconstruct that very same entity
    • Sub-entities of the entity do not necessarily die together with the entity. They may migrate to a new environment. In fact, this is the most common option. Even if the sub-entities and its sub-entities die together with the primary entity, at some sub-entity level they will not die but instead be moved to a new entity. However, that sub-level may be very low.
    • So death of an entity triggers cascading death of its sub-entities. Each cascade ends when the sub-entity in question moves to a new environment.
    • That is, death ultimately leads to some sub-entity moving to a new environment. Thus, death of one entity contributes to maintenance, construction or growth of other entities.
    • If we assume that each environment has only a limited set of “building blocks” (sub-entities at a very low level), we may conclude that death benefits reproduction (by providing the necessary sub-entities to build the reproduced entity). Similarly, if we assume that there is a top-level entity without super-entities, we may conclude that death is a perquisite of reproduction (because that entity cannot draw additional building blocks from its peers or super-entities, which don’t exist in that case). Based on the fact that evolution requires reproduction, we may also conclude that evolution depends on the ability of individual entities to die.
  • An entity is not dead as long as it is not deconstructed
    • It may be dormant, that is not able to perform any of its usual activities; this is considered a strong degradation of functionality, not loss of functionality
    • The key difference between a dead entity and a dormant entity is that the later may continue to provide its usual activities
      • This probably requires an external event, like a change in the environment or an external injection/migration of new sub-entities.
      • Operations of the once-dormant may continue to be somewhat degraded; however, this is still the same individual entity as long as “mostly” [define!] consists of the same sub-entities that it had before its dormant period.
  • A class of entities may also die, in which case we consider the class to be extinct.
    • A class is extinct if
      • All of its individual entities have died
    • A class is endangered if
      • There are only few individual entities left
      • Reproduction is no longer possible
        • In this case, extinction may be avoided by identifying a new reproduction method

Some Samples

  • Consider the International Space Station (ISS), an entity with humans (astronauts) being part of its sub-entities. In a sense, the humans are a subsystem of the ISS [providing essential services to it], while the ISS is a subsystem of human society (a higher-level entity of humans) [providing essential service to the scientific community]. What makes the ISS an interesting sample is that biological and technical components make up for a system which depends on both its biological and technical components to function – in a very obvious way. Similar obvious sample are submarines.
    • The ISS provides an acceptable environment to the humans.
    • The humans in turn provide necessary maintenance to the ISS.
    • The ISS can tolerate sudden death of the humans
      • Its operation will gradually degrade
      • In the long term, this will lead to death of the ISS
      • If humans are “resupplied”, the ISS death can be avoided (but operations may be permanently degraded based on the stage of degradation that was reached without humans)
      • The human society at large would not be affected by the loss of the human astronauts
    • The humans can tolerate death of the ISS
      • requirements
        • Another suitable environment must exist (e.g. earth)
        • A way must exist to reach that other environment (e.g. the Sojuz capsule docked to the ISS – the “transfer environment”)
        • ISS death must happen slow enough to enable humans to migrate to the transfer environment (e.g. a. complete sudden disintegration of the ISS by a meteoroid impact would be too fast to allow the humans to escape)
      • Humans would continue to exist in a different environment without “operational degradation”
      • The human society would suffer a slight operational degradation by the loss of scientific resources
    • Of course, there are also hybrid scenarios thinkable. One more example:
      • The ISS would experience an operational degradation (e.g. due to a large micro-meteoroid impact) that makes the ISS environment unacceptable to humans (e.g. slow but unstoppable loss of oxygen).
      • Humans are able to escape the ISS and thus continue to exist
      • The ISS does not necessarily die; its operation degrades, but oxygen is not vital to ISS operations. Without oxygen, the ISS loses it human “subsystem”, but, as we have seen, can continue to exist.
      • If the “human society” super-entity comes to the conclusion that the benefits of the ISS outweigh the cost to fix the problem, humans may again be sent to the ISS to service it.
      • Once the ISS pressure leak could be fixed and oxygen be resupplied (and any other human-unacceptable degradation fixed so that the ISS is again a suitable environment to support humans), humans can re-populate it (even the same humans individuals that escaped it during the failure)
      • This scenario shows that failure of sub-entities can be repaired if the entity considers it useful. In this example, the human society (or the scientific society?) was the entity with the ISS and the human astronauts being sub-entities. It also shows that interaction between layers is required and thus in a multi-layer depth. This obviously requires communication among different layers. [? Can this be thought of being strictly hierarchical in that one layer talks to its upper and lower layer as well as peers but not any further?] Saving the ISS came at the expense of devoting resources which can no longer be used to do something else.
  • Evolution of Software
    • At a high level, there are three classes of entities involved
      • Source code
        • able to evolve (via a human engineer as helper entity)
        • its primary function is to produce derived entities whose primary function is to do something specific. Actually, this “something specific” is what a human typically thinks the source code does, e.g. compute a specific formula. This perception is wrong.
        • Provides a mostly (execution)-environment agnostic description of the programs function
      • Binary code, in file
        • Is produced (generated) based on the source code (via the “compiler” helper entity). This is a specialization of the source code onto a specific set of environments. The transformation causes loss of generic capability (e.g. the ability to work on Linux systems is removed when a source code is “compiled for windows”, which selects specific functionality for the windows environment (side-note: systems exist to support running the same binary code on multiple platforms, but if we look at these, they effectively create their unique environment which is than adopted on top of other environments. While an application binary may run on any system thanks to the newly created environment, it still can do so only as long as a matching (virtual/generalized) environment is available – the application can no longer run natively under the underlying environments. A good analogy of these classes of software is humans living in space or in a submarine. While we live there, we are still unable to exist in the native environment and can survive only when we bring our own environment with us. Fatal failure of that environment is fatal to the human. Similarly, platform-independent software depending on a virtual execution environment will fail if that virtual execution environment fails. It cannot exist nor propagate to the native environment. This is  only a capability of source code).
        • Specifically adopted to a limited set of environments (specific machine architecture, operating system, …)
        • Is NOT expected to evolve; however, may evolve due to harmful activity or violation of operational constraints. In IT, this always means at least partial malfunction of the software (though it may tolerable and in effect not even be detected – depending on circumstances).
        • Can NOT be executed as is. Its primary function is to provide a reproduction template which can be used to create other entities (loaded binary) that can actually perform the primary function.
      • Binary Code, loaded
        • Is produced based on the binary code file (by the loader helper entity) à this is a further specialization of the code onto a very specific environment (the actual execution environment of a specific machine). This comes at the cost of generic properties (e.g. system call addresses are specified generically inside the binary code file but are being replaced by the actual addresses for this system inside the loaded binary code).
        • Each instance has different detail properties and is in that sense unique inside a given system.
        • Is NOT permitted to evolve (actually, some very early software provided this ability intentionally. This is now considered bad design for a number of good reasons). It may evolve due to side-effects of the environment (e.g. power fluctuation, hardware imperfection) or harmful activity. Evolution, if detected, will lead to termination (death) of the loaded code entity.
        • Performs the actual primary function (e.g. do the calculation)
    • The entities have different ~~priority~~ inside the system:
      • If loaded code is damaged,
        • the instance can be terminated (causing death) and reconstructed from the binary code file.
        • May affect overall system operation (as it cost resources and affects other loaded entities), but is in general bearable
        • Loss of all entities of this class is harmless and does not cause extinction as its entities can always be reproduced from the binary code file
        • Instances are routinely produced and killed as part of normal system operations
      • If binary code files are damaged
        • They can NOT be reconstructed from loaded code (missing generic properties)
        • Does not affect the running loaded code
        • But affects the ability to replenish supplies of loaded code instances
        • Affects system performance if binary code files cannot be substituted quickly enough
        • Binary code files are usually stable for long periods of time on the same system
        • Loss of all entities of this class is most often critical to a system
          • source code and helper entities to produce binary code files out of the source code are usually not present on regular systems for a number of reasons
        • If all instances of binary code files are destructed, it still is relatively easy to reproduce them, as the production method from source to binary is well defined and automated.
      • If source code is damaged
        • There is no immediate degradation of any system (because new binary files are being produced relatively seldom)
        • However, no undamaged binary files may be produced by damaged source
        • The loss of all instances of source code is fatal, though not immediately
          • Actual systems can still be operating and even new ones made available thanks to the binary code files
          • However, damages detected in the source code can no longer be repaired
          • Evolution is no longer possible
          • As execution environments constantly evolve (now hardware, operating systems, …), the software can no longer adopt to those new environments
          • In the end-result, it will become extinct (inability to carry out the reproduction function of an entity inside a evolving environment)
      • Different care for different program entities can be observed in practice. They reflect the different value of the code (where value obviously seems to stem from the ability to evolve).
        • Loaded binary code is guarded only very lightly. It’s loss is usually quite acceptable. Note that guards always introduce inefficiency, so not guarding loaded code to heavily is even a perquisite to enable some functionality. Failing instances are simply discarded and re-instantiated. Repairs of malfunctioning loaded code are usually not attempted.
        • Binary code in files are guarded much better. There are also some analysis tools (e.g. Computer Virus Scanners, Checksums, Signatures) which check the integrity of the code files. Repairs on known-malfunctioning code files are usually attempted. Replacing failed files requires effort and often manual intervention. Undetected failures can have large side-effects, because the failure is reproduced each time the code file is loaded for execution.
        • Source Code files are guarded best and are typically also dispersed to many different physical locations (though this may be not always be the case, e.g. with proprietary software). Malicious modifications of source code are very hard to detect and have widespread consequences. Failures are always repaired. Discarding of source code results in huge loss of resources – a full lineage of development is discarded.
      • Loss of source code has happens and has happened in the past. If the code is really important, it can be reverse-engineered, in which case a binary code file is analyzed and based from it new source code of equal functionality is created. In my point of few, this is actually a new application, because it can not draw from previous code. Also note, that the recreated source probably misses some properties of the lost one, except if a sufficient number of binary code files are reverse-engineered to be able to draw conclusions on the original generic code based on that sufficiently large set of specific samples. With computer code, it is often easier to develop a new source code than to try to reverse-engineer.

Originally written on April 21, 2008. Published here unchanged as an archival entry.