Long-lived project services that observe state and may propose or carry out bounded work under policy.
Resident daemons
in GenOS.
Long-lived project services that observe state and may propose or carry out bounded work under policy.
What it means
in GenOS.
A daemon is a long-lived software process. Its persistence creates lifecycle, supervision, resource, and authority requirements; the organism metaphor adds no biological property.
Long-lived project services that observe state and may propose or carry out bounded work under policy.
A supervisor state machine tracks {starting, ready, degraded, stopped}; restart policy is bounded by a retry budget and must retain crash evidence.
Explore the mechanism: Resident daemons
A qualitative teaching model of this concept. It does not run GenOS or validate its implementation.
The modeled transition may proceed. Change the assumption and move through the stages to inspect the decision path.
How it works
at a glance.
Observe durable state
Long-lived project services that observe state and may propose or carry out bounded work under policy.
Apply daemon policy
A supervisor state machine tracks {starting, ready, degraded, stopped}; restart policy is bounded by a retry budget and must retain crash evidence.
Record bounded action
Record bounded action. A daemon is a long-lived software process. Its persistence creates lifecycle, supervision, resource, and authority requirements; the organism metaphor adds no biological property.
What is connected,
and how far.
The linked, versioned GenOS source defines this concept's supported operations and limits. The status axes describe the implementation and evidence recorded for this entry; they do not establish general mission success, scientific equivalence or behavior beyond that scope.
Persisted mission state and bounded wake/regeneration paths connect selected long-lived services; a multi-instance deployment and general resident-probe coverage are not qualified.
Failure modes have not yet been separately cataloged for this entry; follow the source and evidence links before relying on the mechanism.
The mechanism
behind the analogy.
Design of fault-tolerant computers
Algirdas Avižienis · AFIPS Fall Joint Computer Conference, 733–743
Original fault-tolerance design work. It motivates software failure analysis but does not validate a GenOS pathology label.
Open publication ↗Primary research describes the cited mechanism; specific technologies may instead cite their original technical documentation. These sources provide context and do not validate the GenOS implementation.
Scope and validation boundaries
The linked, versioned GenOS source defines this concept's supported operations and limits. The status axes describe the implementation and evidence recorded for this entry; they do not establish general mission success, scientific equivalence or behavior beyond that scope.