Logical clocks, event sourcing, provenance, actors, and replay inform SlOS's causal history and inspection tools. These notes connect those ideas to the kernel's implementation and its limits.
| 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. |
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 assigns events a logical position that can be merged with peer activity. Wall ticks support local timing and correlation, while Lamport values preserve observed ordering across message boundaries.
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.
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.
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.
Barrelfish treats a multicore machine as a distributed system, with explicit communication through service discovery, monitors, and message paths.
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.
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.
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.
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, while CJournal extends selected history through SlFS with proof and selfcheck commands. Fixed capacity and retention policies constrain how much can be archived or reconstructed.
| 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. |