Mercurius in Use
Real applications, real GPUs, real authentication and real network transport.
Click the image to open the full-resolution screenshot.
It exists
This is not a mock-up. Every mlogo shown is a real Mercurius
Window. Its content is rendered using Vulkan on its workstation, carried
through the Mercurius Object and Message path, and presented using Vulkan
on the Portal GPU. Each window can be moved, resized, stacked, exposed and
closed normally.
Mercurius is a genuine:
- zero-trust
- network-native
- window system
The terminals show Mercurius operating across Ubuntu 24.04, Debian 13,
FreeBSD 15 and openSUSE Leap 16. They exercise multiple workstation and
Portal combinations, including Linux-to-FreeBSD and FreeBSD-to-Linux
operation. The openSUSE virtual machine participates as a Portal; when
asked to act as a workstation without a suitable GPU, Mercurius correctly
reports ENODEV.
Local and remote are the same system
Some of the windows use remote SCTP transport between separate machines;
another uses transport_local on one machine. Everything above
Transport retains the same model in both cases. Applications, Sessions,
Windows, Presenters and Projectors exchange the same Mercurius Messages
whether the Portal is beside the workstation or elsewhere on the network.
That distinction is central to Mercurius. Local operation is not a special fallback and remote operation is not a screen-sharing add-on. A Portal is a seat into the workstation in either case; only the Transport connecting it changes.
Authentication, not a trusted network
Both implemented authentication paths are represented. Some Sessions authenticate non-interactively using per-host SSH keys, while others use a password through PAM. Mercurius authenticates the user and establishes an isolated Session rather than assuming that a Portal is trustworthy merely because it is attached to the local network.
The same zero-trust model applies to every workstation and Portal pairing. Window ownership and Message routing remain scoped to the authenticated Session, independently of the operating systems at either end.
A Unix program, not only a graphics demonstration
The screenshot also shows the mwsc command-line help and its
manual page. Mercurius has an installable command-line Portal, documented
options, operational diagnostics and the supporting material expected of a
usable Unix program. The terminals are part of the evidence: they show the
commands, operating systems and connection paths which produced the visible
windows.
Ordinary Vulkan applications run unmodified
Vulkan programs do not need knowledge of Mercurius or awareness of the underlying network protocol. Mercurius is fully interoperable across several operating systems, GPU and driver stacks, transports and authentication mechanisms. This screenshot shows five windows simultaneously on a Debian miniPC: the mlogo app running on a FreeBSD workstation, the Stanford Dragon running on the local machine and the radial blur, particle campfire and gears from the well-known Sascha Willems Vulkan demos test suite, running on a remote Kubuntu workstation. All render on their assigned workstation GPU and appear as independently managed windows on the Portal desktop.
These applications run unmodified. Each creates its own Vulkan device, swapchain and pipeline on the workstation while the Portal discovers its own GPU and display substrate and presents the results. Local and remote windows share the same model and are managed uniformly by the compositor, whether rendered on Intel integrated graphics, NVIDIA workstation hardware or another device. Mercurius carries output within structured window and presentation messages, preserving window identity, geometry, lifecycle and routing allowing heterogeneous GPUs and operating systems to participate naturally in the same workspace.
Mercurius lets you use your workstation as if your keyboard, mouse, monitor and speakers were plugged into it directly
If you want to play Quake and it isn’t installed on the machine in front of you, but is installed on your workstation, you simply run it there. Mercurius carries the game back to your Portal with full graphics, input, and audio so it feels as though you’re sitting at the workstation itself.
The machine I am sitting at, flash, does not have Quake III Arena installed. The game is installed on a remote workstation named xavier. It runs there, and xavier performs the rendering using its RTX 5070 GPU. Mercurius carries the game’s window, input and audio over separate network streams to my local Portal. Rather than presenting an entire remote desktop, it presents the game as an individual window alongside my local applications, with its sound playing through the speakers beside me.
13:04:02 chris@flash ~/src/mercurius
✖ $ mwsc xavier /opt/quake3/quake3e.x64 &
[1] 379308
13:04:13 chris@flash ~/src/mercurius
✔ $ ps aux | grep quake
chris 379308 23.2 0.4 1159464 135988 pts/4 Sl 13:04 0:16 mwsc xavier /opt/quake3/quake3e.x64
chris 379395 0.0 0.0 6528 2304 pts/4 S+ 13:05 0:00 grep quake
13:05:22 chris@flash ~/src/mercurius
✔ $ ls /opt/quake3/quake3e.x64
ls: cannot access '/opt/quake3/quake3e.x64': No such file or directory