Reading room
This room records the ideas SlOS learns from. The framing is now concrete: durable causal history, time-travel replay, saved queries, and the web explorer make the research lineage visible to an operator.
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, replay state, and state the limits.
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 now applies the idea to timelines, the scrub inspector, and the browser scrubber. |
| 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, durable journals, and explicit validation 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 observed order rather than wall-clock duration.
SlOS uses this habit 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 and now to durable causal history. Notes, mail, editor buffers, scheduled commands, and journal-backed history can be read as ordered facts. Replay turns a cursor or tick 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, proof surfaces, and node marks. The operator uses events, why, trace, graph, cpath, cdot, cq, journal, and the web explorer 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, causal history, saved lenses, pipelines, and HTTP endpoints in 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 and kernel-observation scale. Timelines carry cursors. scrub reconstructs state at ticks and can diff or export JSON. The web explorer exposes the same idea as a browser slider over /api/causal/state?tick=N.
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. Mesh and federation extend the same model across nodes.
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; the CJournal extends selected history durably through SlFS with proof and selfcheck commands. The model favours explanation, bounded artefacts, reproducible validation, and honest operator limits over unbounded archival claims.
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, timeline heads, and federation edges. |
| Separate clocks | Use logical time for causal order. Use wall ticks and local counters for operator correlation. |
| Replay views | Reconstruct current or past state from event material where the application benefits from history. |
| Persist deliberately | Document which history lives in the ring, which history spills to SlFS, and which proof checks validate it. |
| 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 labs turn the ideas into QEMU exercises. The showcase supplies operator evidence.
Working rule: every borrowed idea is reduced to an inspectable mechanism. SlOS favours small records, visible parentage, direct commands, documented limits, and validation that can be rerun.