“Open a Linux workspace.”
Propose a guest image, CPU and memory allocation, storage, network policy, and either a full guest desktop or a selected task view.
NIX / WHY THIS IS HARD
NIX Simulation.
One intent. Any workspace.
An entire operating system. A container. An application, a service, or a game. We call this approach NIX Simulation: a universal subsystem that turns what you want to do into the right execution environment—with AI prompting built into the system.
THE APPROACH / NIX SIMULATION
Describe the outcome.
NIX simulates the environment.
Simulation is the name of the complete approach: assembling and managing the computing environment an intent needs. It includes the interface, execution path, resources, permissions, data, and lifecycle—not just the act of running a guest.
Emulation, virtualization, containers, compatibility runtimes, and native execution are mechanisms NIX Simulation can select and combine. Simulation does not mean every instruction is emulated, nor does the name imply that every environment has the same performance or compatibility.
An intent is the outcome you ask for. It can be as small as opening a writing space or as broad as starting a complete operating system. NIX is designed to translate that request into an environment, a resource budget, a set of permissions, and a way to launch, save, stop, and recover it.
The prompt is the front door. The subsystem underneath does the difficult work: selecting a native executable, a supported runtime, a container inside a compatible guest, or a complete virtual machine. Those paths are different. The experience should still start with your intent.
“Run my development stack.”
Prepare the compatible guest and container runtime, persistent project data, service dependencies, and only the network endpoints you approve.
“Let me write. Or play.”
Choose an existing application and its tested execution path. Bring the useful interface forward while keeping the environment manageable.
WHY THIS IS HARD
The prompt is simple.
The computer underneath isn’t.
Why hasn’t this become the ordinary way a personal computer works? Virtual machines, containers, compatibility layers, and AI assistants each solve part of the problem. The challenge is making those parts act like one dependable personal system.
Software expects a world.
An application depends on system calls, libraries, graphics APIs, files, drivers, and sometimes online services. Understanding its name is not enough to supply that world.
The CPU is only the start.
A guest can execute CPU instructions efficiently and still lack usable graphics, audio, storage, input, or networking. Games make those gaps immediately visible.
A useful agent needs limits.
An AI can misunderstand an instruction or propose unsafe code. Built-in prompting must not give model output automatic authority over files, devices, or installation.
Your work must survive.
Updates, crashes, failed builds, and stopped guests cannot be allowed to blur the difference between an application and your creations. Persistence and recovery need their own design.
Everything shares a machine.
Local inference, a guest OS, a compiler, and a game can all compete for memory and compute. NIX needs cancellation, priorities, budgets, and predictable failure behavior.
Invisible cannot mean opaque.
A streamlined interface still has to explain what is running, what it can access, and why it failed. You need control over the machinery even when it stays out of the way.
This is not a claim that nobody has built the individual technologies or explored similar ideas. NIX’s ambition is to bring intent, execution, local intelligence, and personal data together behind one coherent interface.
PERFORMANCE / THE RIGHT EXECUTION PATH
Near-native where possible.
Measured, not assumed.
“Practically native speeds” is the target for suitable workloads on supported hardware-assisted paths. It is not a blanket promise for every application, device, or operating system.
| Path | How it fits the vision | What determines performance |
|---|---|---|
| Native NIX application | Execute code built for NIX directly. | System services, graphics support, scheduling, and application quality. |
| Hardware-assisted guest OS | Use VT-x or AMD-V and second-level address translation so guest CPU code can execute on the processor. | VM exits, device models, storage and network I/O, memory pressure, and graphics access. |
| Container workload | Use a compatible guest kernel and container runtime; a Linux container does not acquire compatibility with Core just by being packaged. | The guest path underneath, resource allocation, filesystem access, and networking. |
| Compatibility runtime | Translate a supported application’s expected OS interfaces. | API coverage, graphics translation, application behavior, and per-title testing. |
| CPU emulation | Provide a fallback when direct execution is unavailable. | Instruction translation and device emulation overhead. This path is not the basis of the near-native target. |
Graphics needs a separate solution: a supported accelerated virtual device, mediated sharing, or carefully isolated passthrough. Hardware availability and guest drivers constrain that choice. A CPU benchmark alone cannot establish game compatibility or frame pacing.
The proposed fast path also keeps the model out of per-frame and per-system-call execution. AI helps plan and configure the environment; deterministic services and the selected runtime carry the workload once it launches.
HOW WE PLAN TO SOLVE IT
Make the boundaries real.
Then make them disappear.
- Start with one known machine.
Fix the CPU, motherboard, graphics, storage, and controllers. Establish repeatable boot, diagnostics, and recovery before expanding the hardware matrix.
- Give intent a concrete contract.
Translate a request into typed plans: the chosen artifact, environment, resource limits, data mounts, network scope, and proposed actions. Ask for missing details that materially change the result.
- Build the execution substrate.
Develop Core’s isolation and virtualization primitives, then the user-space VMM, device models, guest lifecycle, and integration channels. A small inner guest is a starting point, not a substitute for a general guest OS.
- Reuse before inventing.
Evaluate maintained applications, runtimes, and guest tooling. Pioneer is the proposed software engine for scoped research and builds when adaptation is needed—not a replacement for the missing drivers or runtime.
- Keep authority outside the model.
The trusted broker validates plans and permissions. Build environments return artifacts; they do not install directly. Memory grants and device access remain scoped, reviewable, and revocable.
- Make data independent of the runtime.
Use Memories for durable, versioned work. Keep application removal separate from deleting creations. Test restart, export, backup, and recovery as part of each useful experience.
- Prove one complete intent at a time.
Start with a writing task, then a selected legacy application, then more demanding acceleration and gaming paths. Publish exact hardware, software versions, correctness results, latency, resource use, and performance comparisons.
TODAY / NEXT / THE TARGET
A working foundation.
A much larger destination.
The current Core repository documents a QEMU-booted kernel, a writing Pod, persistent Memories, and a small AMD SVM build guest for a specific recipe. That inner guest is an early execution boundary; it is not yet a general-purpose Windows or Linux environment.
NIX Simulation is the target architecture for this universal subsystem. General guest operating systems, container hosting, broad application compatibility, accelerated graphics, and integrated AI orchestration require the next layers of engineering and verification.
Success means more than accepting a prompt. It means the right environment opens, the workload behaves correctly, your work survives, permissions hold, and performance stands up to measurement. That is how the vision becomes a system you can depend on.
Explore the delivery plan ↗ Inspect the Core source ↗LOOK BENEATH THE SURFACEArchitecture