Reading room
This room records the ideas SlOS learns from. Each note names a source tradition, states the engineering lesson, and shows how the lesson appears in a small causal operating system.
Operator use
The purpose of this page is instructional. Read each lineage note as a tool for building and inspecting systems: order events, record facts, preserve origin, divide services, and replay state.
Route
| 01 / Lamport clocks | Read logical time as an ordering instrument. A Lamport value states that one event was observed before another through message or program order. |
| 02 / Event sourcing | Treat state as a projection from recorded facts. A current buffer, inbox, or note list is reconstructed from the event material that produced it. |
| 03 / Provenance | Attach origin, parentage, and subsystem labels to data. The operator should be able to ask where a value came from and which operation carried it forward. |
| 04 / Plan 9 | Study namespaces, small protocols, and system services presented as files. The lesson is operational clarity through uniform interfaces. |
| 05 / Barrelfish | Study a machine as a distributed system. The lesson is explicit communication among cores, drivers, monitors, and service endpoints. |
| 06 / Time-travel debugging | Record enough execution history to inspect a prior state. SlOS applies the idea to application timelines and recent kernel causality. |
| 07 / Actor systems | Name independent entities, deliver messages, and keep local state behind an inbox. Causality travels with each message boundary. |
| 08 / SlOS tradeoffs | Keep the mechanism small enough to read. Bounded rings, fixed tables, and explicit snapshots define the operating envelope. |
Lineage A
Lamport clocks give a distributed system a logical timebase. Each local event advances the counter, and each received message merges the remote value before advancing again. The resulting value encodes the observed order of events as a logical position.
SlOS uses this idea in the causal record. Events receive a logical position that can be merged with peer activity. Wall ticks remain useful for the operator; Lamport time carries causal discipline.
Lineage B
Event sourcing stores the facts that changed the system, then derives current state from those facts. The event log holds the durable record, and any current view is computed from it on demand.
SlOS applies the pattern to timelines. Notes, mail, editor buffers, and scheduled commands can be read as ordered application events. Replay turns a cursor position into current state.
Lineage C
Provenance records origin and transformation. A datum carries a history: producer, consumer, operation, and parent material. This is useful for debugging, audit, replication, and teaching.
SlOS represents provenance as parent edges, subsystem names, short descriptions, payloads, and node marks. The operator uses commands such as events, why, trace, and graph to follow that record.
Lineage D
Plan 9 is useful here as an engineering study in small abstractions. Namespaces, files, and simple protocols make services visible and composable. The system teaches through a uniform operating surface.
SlOS learns the value of direct operator vocabulary. Shell commands expose devices, tasks, actors, timelines, and causal history in a small set of inspectable forms.
Lineage E
Barrelfish treats the multicore machine as a distributed system. Communication is explicit. Service discovery, monitors, and message paths are part of the model.
SlOS uses actor routing and mesh vocabulary as a small laboratory for the same habit. A future per-core design can coordinate cores through explicit message passing and causal metadata, with deliberate ownership of shared state.
Lineage F
Time-travel debugging depends on recorded execution. The debugger needs enough history to reconstruct, inspect, or move to a previous state.
SlOS keeps this idea at application scale. Timelines carry a cursor. Rewind and forward move that cursor. Replay reconstructs the state at that selected point.
Lineage G
Actor systems divide software into named entities with private state and message inboxes. Concurrency becomes delivery order, mailbox pressure, and explicit protocol design.
SlOS actors provide named mailboxes and routeable messages. The causal graph records sends and deliveries, so communication becomes part of the machine history.
Lineage H
SlOS is an instructional kernel. It uses fixed pools, bounded rings, simple filesystems, direct drivers, and compact records. These choices make mechanisms inspectable and keep failure modes close to the operator.
The causal ring stores recent history. Durable application state depends on timelines, snapshots, and SlFS files. The model favours explanation and repeatable demonstrations over unbounded archival storage.
Engineering practice
| Name the event | Give each significant operation an event ID, source subsystem, and short description. |
| Attach parents | Record the immediate causes. Use explicit parents for joins, message delivery, and timeline heads. |
| Separate clocks | Use logical time for causal order. Use wall ticks and local counters for operator correlation. |
| Replay views | Reconstruct current state from event material where the application benefits from history. |
| Bound the system | Choose fixed limits deliberately and document what persists beyond each bounded structure. |
Cross references
The causality laboratory gives the event model in detail. The source plates show code excerpts. The manual lists subsystems and commands. The showcase supplies operator evidence.
Working rule: every borrowed idea is reduced to an inspectable mechanism. SlOS favours small records, visible parentage, direct commands, and documented limits.