HopOS / HOP / SURF
Run the machine.
Run the jobs.
Bring them to the screen.
A Go operating system, a small orchestrator and a distributed desktop. Each has a clear job. Together, they take you from bare hardware to running services and windows across machines.
HopOS
Compute, with fewer moving parts.
Go directly on ARM64 and RISC-V. Own memory for every app, dedicated or trusted shared cores, and kernel updates while resident apps keep running.
One framework · Go apps · zero-reboot FLIPHow HopOS works → 02 / The jobsHOP
One job model across your machines.
Place processes, Docker containers and HopOS apps. Schedule, update, inspect and recover jobs through one API, with the agent and leader in one Go program.
Placement · health checks · recoveryWhat HOP can run → 03 / The screenSURF
Windows from anywhere in the cluster.
Apps draw on one machine; a display app composites their windows on another. A desktop, browser and emulator built above the same app framework.
Pixel and scene apps · networked displaySee SURF in action →How they fit
Start with the piece you need.
Boot HopOS with a configured set of jobs on one board. Run HOP on your existing Linux or macOS hosts, or use the HOP agent integrated into HopOS. Add SURF when your applications need windows.
The common idea is small, explicit ownership: a memory partition, a job lifecycle, a window. The pages follow those boundaries from features to implementation and source.