Reimagining LibC: The Standard Library as a Stream
From System Calls to Stream Emissions: Transforming the Foundation of Computing.
The C Standard Library (LibC) is the bedrock of modern computing. For decades, it has defined how programs interact with the operating system: open, read, write, malloc. But this foundation is often rigid, tying programs to specific kernel interfaces, memory models, and local execution contexts.
At Datom.world, we ask: What if LibC was just a wrapper around streams?
The Theoretical Foundation: Plan 9 and Pi-Calculus
This isn't a new idea; it's the logical conclusion of history. The Plan 9 operating system proved that resources—files, windows, network connections, processes—could all be treated uniformly as files provided by a 9P file server. Theoretical computer science, specifically the Pi-Calculus, demonstrated that any computation can be modeled as concurrent processes communicating over channels.
Datom.world unifies these concepts. In our architecture, the 'channel' is a Datom Stream, and the 'process' is the Yin.VM. If Pi-Calculus is Turing complete, then a system built entirely on streams can represent any computation, including the entirety of LibC.
LibC as a Stream Schema
Imagine re-implementing LibC not as a set of assembly interruptions (syscalls), but as a projection over datom streams. In this world, a file descriptor is not an integer index in a kernel table; it is a Stream Reference.
The Mapping
- open(path, mode) → Emits a datom
{:a :sys/open :v {:path path}}to the host stream. The host replies with a new stream reference representing that file. - write(fd, buffer) → Emits a datom
{:a :sys/write :v buffer}to the stream referenced byfd. - read(fd, buffer) → Subscribes (takes) from the stream referenced by
fd. - pipe() → Creates a new pair of entangled streams.
The C program doesn't know the difference. It calls write(), passing a buffer. Under the hood, our 'LibC' wrapper wraps that buffer in a datom and pushes it onto a ring buffer.
The Possibilities: Write Once, Run Everywhere
By decoupling the standard library from the kernel syscall interface, we achieve true location independence. A program linked against our Stream-LibC acquires superpowers essentially for free.
1. Kernel-Space execution without Context Switches
Since Datom.world is stream-first, it can run directly in Ring 0 (kernel space). If your C program (e.g., a database engine or a web server) uses Stream-LibC, it can run entirely within the kernel. There is no expensive user-to-kernel context switch for I/O, because I/O is just writing to a memory buffer (the stream).
2. Transparent Distribution
Because a stream is just data, it can be routed over a network. A C program writing to a file doesn't need to know if that file is on a local NVMe drive or on a server in Tokyo. The Datom.world router simply forwards the :sys/write datoms to the appropriate node. Distributed computing becomes as simple as local file I/O.
3. Time Travel and Replayability
Since every 'syscall' is now a datom in a stream, we have a perfect log of execution. We can replay the stream to debug a crash, audit security access, or even migrate a running process to another machine by serializing its stream state.
The Universal Interface
This approach breaks down the walls between languages and runtimes. Any program that can link against C—which is effectively *every* program—can automatically become a citizen of Datom.world. Python, Ruby, Node.js, Rust... if they use LibC, they can use streams.
We are not just building a VM; we are building a Universal Adapter for computation. By adhering to the physics of streams, we allow the vast legacy of existing software to inherit the future of decentralized, immutable, and reactive systems.
Related Reading: