A writing Pod.
A manuscript and selected research notes. File access can be limited to those Memories, with network access granted only when needed.
NIX / PODS
One task. Its own space.
Pods bring applications, runtimes, permissions, and resources together around what you want to do.
03 / SOFTWARE ISOLATION
One intent.
The right Pod underneath.
A Pod is NIX’s application deployment unit: an artifact, runtime or guest image, permissions, resource limits, data mounts, and a launch recipe. “Pod” is a NIX abstraction; Linux containers cannot run directly on a new kernel without the required runtime and system-call support.
| Pod type | Execution path | Scope and dependencies |
|---|---|---|
| Native | NIX executable or a ported WebAssembly runtime | New tools target the NIX ABI/SDK. WebAssembly requires a supported host runtime and explicitly exposed capabilities. |
| Compatibility | Ported API/runtime layer | Per-application validation. Wine-like tooling needs substantial OS interfaces and graphics support; it is not a universal Windows switch. |
| Virtual machine | Windows or Linux guest in an app-scoped VM | Core virtualization primitives and a user-space VMM/device model. Licensed guest media and application installers. Window integration presents the requested application directly, with an optional desktop. |
| Emulated | CPU and device emulation in a ported runtime | Fallback for unsupported architectures or old hardware assumptions. Higher overhead; test graphics, audio, timing, and input individually. |
Legacy example: “I want to play Freelancer.”
Research the exact edition and installer first. Select a tested guest configuration, request legal installation media and any required license, then create a dedicated Windows Pod. Install the game, configure graphics/input/audio, verify launch, and register Freelancer for prompt launch, with an icon only on a requested desktop. The guest OS remains an implementation detail with an accessible management view.
Compatibility is a test result, never a blanket guarantee. Diablo needs edition-specific research, launcher support, GPU drivers, and any online-service or anti-cheat requirements. GPU passthrough requires IOMMU support and a compatible device allocation; a separate host display adapter may be needed.
Pod manifest contract
id artifact_hash runtime entrypoint memory_refs capabilities network_policy cpu_ram_gpu_limits license_refs rollback_version
Read-only base images, writable app overlays, explicit Memory mounts, and mediated device access. Uninstall removes the runtime and task registration while offering a separate choice for user-created Memories.
PERMISSIONS / A SMALLER REACH
Give the task what it needs.
A game Pod.
The chosen runtime, installation files, save data, input, audio, and the graphics resources the tested configuration requires.
A build Pod.
Source, pinned dependencies, compiler tools, and a place to return artifacts. It does not install software directly or browse the personal store.
LIFECYCLE / A WAY BACK
Prepare. Review. Open.
Keep a rollback point.
A Pod proposal names its artifact, runtime, resource budget, mounts, and permissions. Installation should be atomic; launch should be repeatable. A failed update should leave the previous version available. Removing a Pod should give you a separate choice about the work you created with it.
Meet Memories ↗CONTINUE EXPLORINGMemories