Chapter 1 — The Machine That Needed Boundaries
In 1936, Alan Turing, a British mathematician, asked a question that would change how we understand computation:
What does it actually mean for a problem to be computable?
His answer was not a physical machine, but a mathematical model of one: a machine that follows simple rules, reads symbols, changes them, and moves through a sequence of steps.
The surprising discovery was that even a system built from simple operations has fundamental limits. Some problems cannot be solved by any algorithm of the kind he described.
But another question remained.
What happens when computation moves from mathematics into a real machine—with physical memory, multiple processors, interruptions, and programs that must not interfere with one another?
By the mid-twentieth century, stored-program computers were emerging. The 1945 First Draft of a Report on the EDVAC, associated with John von Neumann, helped describe an influential architecture in which instructions and data could reside in memory. Many researchers contributed to the ideas and machines that made this possible.
As computers grew more capable, engineers needed ways to organise execution. Concepts such as processes, threads, and schedulers emerged to solve practical problems: managing independent work, sharing processors, and controlling when computation runs.
These concepts are not laws of nature. They are human-designed abstractions built on real hardware mechanisms.
That distinction matters.
An abstraction may be useful, even essential, for a particular design. But its name alone guarantees nothing. We must ask what mechanism implements it, what properties that mechanism enforces, and what happens when something goes wrong.
Years later, Jenny began asking a related question while building NXU.
What if we started not with the familiar vocabulary of operating systems, but with the machine itself?
A processor has architectural state. Memory has physical boundaries. Translation hardware enforces access permissions. Exceptions redirect execution. Timers measure time. Interrupt controllers deliver events.
These are mechanisms we can investigate and test.
NXU’s experiment is to discover how much useful computation and isolation can be built from such facts—and which higher-level abstractions are genuinely necessary.
Its terms—Room, Wall, Edge, Fabric, and Pulse—must face exactly the same scrutiny. New names are not new science. Each concept must correspond to a mechanism, provide a measurable guarantee, and survive adversarial testing.
The current NXU prototype is only an early experiment, not a completed operating system or a proven replacement for existing designs.
And that is where the real mystery begins.
If the machine provides mechanisms, and humans invent abstractions to organise them, how do we distinguish what computation truly requires from what generations of engineers simply became accustomed to building?
That question began NXU.
#NXU #software #osdev