When a single developer, assisted by an LLM and twenty years of experience, rewrites a microkernel operating system for RISC-V from scratch and releases it under Apache 2.0, the on-premise world gets another reason to look beyond x86. Yuri Zaporozhets, founder of QRV Systems, has just published QSOE (Quick and Secure Operating Environment), an environment that offers two kernels sharing a single userspace: the formally verified seL4 and Skimmer, a custom microkernel designed for multiprocessor machines. The genesis of this achievement is a collection of projects that amount to a tour de force of low-level engineering.

The FPGA personal computer: GateMate PC

At the end of 2025 Zaporozhets powered on his GateMate Personal Computer, a system reminiscent of late‑1980s IBM compatibles but with a 25 MHz RISC‑V core. The board is an Olimex GateMate A1-EVB, priced around €50: an FPGA that hosts almost the entire design. The machine outputs 80×30‑character text with UCS‑2 Unicode, 8 KB of BIOS ROM, and 8 MB of extra PSRAM over a QSPI interface. It is deliberately anachronistic, yet it demonstrates that with open hardware and an FPGA one can build a whole stack – from silicon to the operating system – without relying on proprietary architectures.

The miniature mainframe: System/359

On the same FPGA Zaporozhets then built a “mainframe” explicitly inspired by the IBM System/360. The System/359 is not a clone: it is little‑endian, uses PC‑relative addressing, and distills what was elegant about the original – channel I/O model, clean instruction formats, the Program Status Word concept – while modernising the rest. “Inspired by, not compatible with,” he writes. The project includes an assembler with a powerful macro processor borrowed from NASM (Zaporozhets was a long‑time contributor) and a kernel that already runs a minimal IPL with controllers for PS/2, UART, and even a cryptographic module. It is another building block in a path where technological sovereignty begins with full control over every layer, including the instruction set.

From porting QNX to a complete rewrite

Perhaps the most revealing undertaking was porting the QNX 6.4 kernel to 64‑bit RISC‑V. Zaporozhets took the original sources, frozen in a 32‑bit ILP32 model for x86, ARM, and others, and transformed them into an LP64 system, rewriting large portions of the kernel and services. The result, QRV, reached multi‑user login before being declared finished: the original QNX code cannot be redistributed, and BlackBerry did not respond to the petition for an Apache 2.0 relicense. Without a true open fork, the only way forward was to start from scratch with a free kernel.

QSOE: two kernels, zero dependencies

QSOE is the Plan B that became the main project. It combines a microkernel written from scratch (Skimmer) with seL4, the formally verified kernel that already powers critical systems. Both share the same userspace and build system, licensed under Apache 2.0. The work has deep roots: in 2003 Zaporozhets had already attempted a similar OS with RadiOS. Today, QSOE’s reference hardware is still the Olimex FPGA board, but the design thinks big: SMP, formal verification, strict privilege separation. For those who need on‑premise stacks where trust is not delegated to a vendor, this architecture offers a benchmark: no binary blobs, an open ISA, a verifiable kernel. The assistance of an LLM such as Claude, transparently disclosed, does not detract from the journey: the ideas behind QSOE were already present in projects from two decades ago, when ChatGPT was science fiction.

Why this story matters for on-premise deployment

QSOE and the projects that preceded it show how the convergence of low‑cost FPGAs, RISC‑V architectures, and technically verified kernels enables the construction of environments that are controlled from the ground up. It is not just about “having the source code”: here the hardware is programmable, the instruction set carries no royalties, and the operating system is designed to be inspectable and free of proprietary components. Organizations evaluating on‑premise infrastructure for data sovereignty or regulatory requirements can see in this ecosystem a concrete evolution beyond the “x86 server with Linux and some security policies” model. The porting difficulties and kernel rewrite teach that the road is long, yet full control over TCO and attack surface remains an attainable goal. Using an LLM as a development tool, when handled transparently, can accelerate parts of the work without contradicting the independence of the architecture.