SURF · a HopOS tech demo

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.

not remote video

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

Inside the demo

Two deliberately unreasonable apps.

A browser proves the stack can build something complex from scratch. A third-party Game Boy emulator proves existing pure-Go GUI code can be brought along.

The SURF browser rendering the gethop.org HOP page

browser · from scratch

Its own DOM, CSS and layout.

Not a wrapper around an existing engine. Fetching, cascade, layout and rendering all run inside a caged Go app with no Linux underneath.

Incomplete and slow — but it renders real pages, including this site.
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.

The honest status

A tech demo, not a desktop product.

What it proves

  • 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

What it does not promise

  • 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
Curious is the right audience.

Build it, break it and read it. Every desktop component lives in the open, separate from HopOS itself.

hop-os-surf on GitHub →