Mercurius began with a question: what happened to the networked workstation?
Mercurius is built for real, personal workstations — and for reaching the bigger ones when you need to.
Background
Mercurius did not begin as a graphics project. It began as a question: why has the idea of a networked workstation quietly disappeared? For decades, Unix systems treated the network as an extension of the machine. A workstation was a place you inhabited, not a device you carried.
My own background shapes this view. I grew up with long‑lived machines that mattered. I've had Unix machines at home since Acorn RISCiX and 386BSD. My first proper job was at STC Optical Cable Development Labs, writing software for HP workstations and sharing it through the HP Users’ Group long before “open source” was a phrase. Later, as a Research Associate at Edinburgh University, part of my role involved administering a network of Sun workstations. Those machines were not appliances. They were environments with continuity, personality, and history.
My understanding of “long‑lived Unix machines” was not earned from the outside. It comes from years spent inside them: working on kernel behaviour, tracing failure paths, and helping keep real systems stable so they stay up for months or years at a time. That experience is part of why Mercurius cares so much about security, responsibility, behaviour and continuity: it is built by someone who has seen what happens when those things are treated as optional.
My current network continues that tradition: a workstation, xavier, that has evolved continuously for more than fifteen years. It began life with an i7 motherboard, 32 GiB of RAM, and a single 1TB disk; since then it has been upgraded, expanded, and re‑architected piece by piece — new motherboard, new storage, new graphics cards, new layout, new capabilities — without ever losing its identity. It is now a 5.7GHz i9 with 128GiB RAM over 40TB of disks in a RAID array. A true Ship‑of‑Theseus machine: the same workstation, not because its parts are unchanged, but because its history, its environment, and its role have persisted throughout. Around it lives a network of small Unix systems, each doing one job well. In that world, the workstation is not a disposable box but an enduring presence.
I have a small studio where I play music, and there I use a silent mini‑PC as a thin client. I do not want a second monster machine, and I do not want to maintain two environments. xavier is a magnificent computer that can complete a full, clean Yocto rebuild in around twenty minutes — but the CPU reaches 100 °C and the fans run at full speed while it does so. I do not want that in the studio. But I do want to use that existing workstation, the one that has grown with me for years, and reach it from anywhere without pretending that a laptop or a mini‑PC is its equal. There is a 10 Gb/s fibre run between them. It must be doable.
A recent experience was one of the drivers for this project, providing a concrete example. I was up early so logged into xavier on the console and started on some stuff. After a while it was time to head down to the studio, which meant logging out of xavier and logging in to flash, in another building. If only there was some way I could detach my KDE session on xavier before logging out (leaving the machine free for others to use) and pick it up again on flash. That is a use case Mercurius is intended to address.
Mercurius is not an attempt to invent a new paradigm. Once, many users shared a powerful machine through simple text terminals. When graphical interfaces arrived, X11 extended that model to windows and applications. As personal computers became more capable, the machine on the desk — and eventually the laptop — became both the place where the user sat and the place where the work happened. The networked workstation gradually disappeared from ordinary use.
X11 deserves enormous credit for demonstrating what this could look like. It showed that windows, input, and interaction could move across the network without losing their semantics. But X11’s design is inseparable from its legacy: global state, implicit trust, and decades of accumulated behaviour.
Wayland deserves equal credit for modernising the local graphics stack. Its clarity of scope — doing local graphics well — is a strength. But that scope is intentionally narrow. Wayland assumes a laptop‑centric, local‑only workflow. It omits window‑management semantics by design. It does not attempt to support remote presence, automation, introspection, or multi‑window structure across the network. These are not bugs; they are deliberate choices.
Many applications — from CAD tools to scientific environments — rely on behaviours that Wayland intentionally does not provide. These are not “unfinished features”; they are outside the model. X11 provided them, but only as a side effect of a much larger, older architecture.
The economics have changed again. RAM and high-end GPUs are expensive, while laptops remain constrained by power, cooling, and size. For an engineering team, it can make more sense to give people access to a workstation with a £3,000 graphics card than to buy every engineer a £3,000 laptop that still cannot do the same work. The laptop can provide the convenient, personal place to sit while the demanding applications, large datasets, and expensive hardware remain on machines built for them.
The need for remote computing did not disappear. Public clouds, private clouds, and on‑premises datacentres quietly shifted computing back toward centralised machines. Increasingly, development environments, data processing, and even graphics workloads run on hardware that is not the device in front of you. Laptops have become thin clients again in practice, but without a native, structured way to inhabit a remote graphical environment. SSH remains one of the most widely used network applications in the world because the terminal model never stopped being useful. Mercurius does for GUIs what SSH did for text: provide a secure, explicit, structured way to inhabit a remote machine as if it were local, without pretending that a video stream is a desktop.
Existing remote‑desktop systems treat the workstation as a pixel source. They move images, not windows; frames, not meaning. They do not express the structure of a desktop environment, and they cannot make a remote workstation feel like a place you inhabit. Mercurius exists to fill this gap. It is not a replacement for X11 or Wayland. It is the missing piece: a clean, modern, structured protocol for inhabiting a long‑lived workstation across the network, with windows, focus, and input treated as first‑class concepts.