HopOSRun the machineHOPRun the jobsSURFBring them to the screen

SURF · the distributed desktop

One desktop. Windows from many machines.

A SURF app can run anywhere in a HOP cluster while its window appears on one display. If that machine disappears, HOP restarts the app elsewhere and the window returns.

explore the source → see how it works

built as ordinary HopOS apps · moved by HOP

A SURF desktop with a clock window from node-a, a task manager from node-b and a calculator from node-c
clock @ node-a · taskman @ node-b · calc @ node-c. Three machines, one screen.

What it is

A distributed desktop built from ordinary jobs.

The app owns its window; it does not need to own the screen. It draws on whichever node HOP chose, then sends frames or small scene updates to the display job.

The display composites those windows, routes input back to the right app and can expose the whole screen through a browser.

node-a Go app draws a frame or scene
pixels or patches
display node SURF compositor layout · input · taskbar
framebuffer or web KVM
one screen ▣ ▢ ▣ local monitor or browser

What it demonstrates

The desktop is distributed. The OS stays small.

01

A window belongs to a cluster job.

It reconnects to the display after its process is restarted on another node. The window returns because its identity lives above one particular machine.

windows can move

02

The GUI is not part of HopOS.

HopOS grants one ordinary app access to the framebuffer. Windowing, compositing, the taskbar, browser and web KVM all remain replaceable apps outside the OS.

zero desktop in the kernel

03

Apps send the representation that fits.

A pixel app sends frames. A scene app sends a widget tree once, then tiny patches while the display handles layout, hit-testing and semantic input.

pixels or scene updates

The whole compositor is software: there is no GPU driver anywhere in this stack.

Inside the demo

A browser, an emulator, and the tools around them.

The browser brings fetching, CSS and layout into a Go app. The Game Boy port brings an existing Go emulator to a SURF window. The launcher and task manager connect the desktop to the cluster.

The SURF browser rendering the gethop.org HOP page

browser · from scratch

HTML, CSS and software rendering.

The browser uses Go HTML parsing and selector libraries, with its own fetching, CSS, layout and rendering code. It runs inside an app’s memory partition.

Renders real pages, including this site. Web compatibility and performance are still limited.
A SURF window running Libbet and the Magic Floor in the goboy emulator

Game Boy · third-party Go

Zero upstream lines changed.

goboy runs as a HopOS slot app and presents its screen in a SURF window. A prepare step adds two small adapters beside upstream.

No audio yet. The emulator passes blargg’s CPU instruction tests, eleven of eleven.
taskmanjobs, tasks and live logs from the cluster
launchersubmits a selected app to HOP
dashshows its own protocol traffic
clock + calcsmall pixel and scene examples

What lives where

One hardware grant. Everything else is replaceable.

The GUI flavour of HopOS can grant the framebuffer to one app: display. That is the entire OS-level graphics contract. A headless HopOS image links none of it.

Current scope

Working components, with room to grow.

Available today

  • HopOS apps can build a complete GUI above the OS
  • Windows can reconnect after jobs move between nodes
  • Pure-Go GUI software has a practical porting path
  • A local monitor and browser KVM can share one display

Still in development

  • No production support or stable version contract
  • Published app images are arm64 only
  • The browser fails on plenty of the web
  • No audio or live application-state handoff yet: HOP restarts a failed job, and its new instance reconnects
Build a window. Run it on another machine.

Start with a pixel or scene example, then follow the same protocol through the compositor and input path. Every desktop component is an ordinary HopOS application.

hop-os-surf on GitHub →