Questions, answered plainly.

The Single Purpose OS: an operating system for dedicated devices, such as kiosks, terminals and control panels, built for each device's one job. You write the device's application in Rust, and NoWayOS builds it, with only the drivers it uses, onto the seL4 microkernel. The image holds that and nothing else: no browser engine, window system, shell, package manager or user account.

A computer with nothing else to do.

An operating system built for one device's one job, rather than built to run anything and then locked down to one thing. Three things make an operating system single purpose:

• Built for one job. Its image holds the application, the drivers that application uses and the kernel, and nothing else: no browser, desktop, shell, package manager or user account.
• Sealed inside. Each part runs in a compartment of its own and reaches only what it was granted, so a fault in one part is designed to stay there.
• Shows its working. It comes with the evidence of what is inside and what each part may do: every grant written down, every component listed, and checks anyone can run.

A Single Purpose OS is not kiosk mode, which locks a general-purpose system to one app and leaves everything else in place, and not a single-user OS, which limits who uses a computer rather than what is in it. NoWayOS is a Single Purpose OS: a computer with nothing else to do.

Because there is no way to exploit what was never built in. The name is about what is left out of a device, not a promise that nothing can ever go wrong with what is left in. What is built in can still have bugs; the claims are that there is far less of it, and that a bug stays in its compartment.

Locking down is secure by configuration: the browser, the desktop and the shell are still there behind the settings, still need patching, and one bug can bypass every setting at once. NoWayOS is secure by construction: those parts were never built into the device, and what remains runs in sealed compartments, so a fault in one part is designed to stay in that part.

No. NoWayOS is in development, and every API is provisional and will change. Over fifty systems boot and check themselves in QEMU, and the user interface, USB keyboard and mouse, timers, watchdog and supervisor run on a Raspberry Pi 5. Secure boot, signed updates applied on the device and production hardware are still to come.

It is intended to be. NoWayOS and the Showcase are to be released under MIT OR Apache-2.0, and the Screen Compiler is MIT. Their publication is being prepared under the NoWayOS organisation on GitHub; until then the repositories are private.

No, and we are careful not to suggest it. NoWayOS runs on seL4, which has machine-checked proofs of correctness and security for specific configurations on its hardware. NoWayOS uses seL4's mixed-criticality configuration, whose AArch64 proofs are in progress, so no NoWayOS image is inside seL4's completed proofs today. NoWayOS's own code is not covered by seL4's proofs at all; it relies on Rust, isolation, testing and bounded proofs of its own. Every image records its exact seL4 configuration (Security).

No. NoWayOS's security comes from its design, not from secrecy: what is left out, and the compartments around what is left in. Being open lets anyone check the claims, run the evidence and report what they find.

It is designed to stay in the compartment it is in, which limits the damage while a fix is made, and with far less code there are far fewer fixes to make. Fixes are to arrive as signed updates that fall back safely: that is designed, not yet built. To report one, please write privately, as each repository's SECURITY.md describes, and not in a public issue.

Not as it stands. NoWayOS runs applications written for it, in Rust; it cannot run Linux or Windows programs, or a web app, because none of what they need is built in. Screens are the easy part: React screens written to the Screen Compiler's supported subset convert to native Rust at build time. The application's logic is rebuilt as NoWayOS protection domains.

No. That is rather the point. There is no browser engine, WebView or JavaScript on a NoWayOS device. Screens are native Rust, drawn by NoWayOS's own small user interface, and can still be designed in React and converted at build time.

QEMU's AArch64 machine, where every system boots first, and the Raspberry Pi 5, the low-cost reference board. NXP's i.MX8 family is the intended production hardware, with a hardware root of trust; it is not yet supported. To build NoWayOS you need Podman (or Docker) and make: it is developed on Apple silicon, and x86-64 hosts are not yet tested.

Clone the nowayos repository, run make container once, then make demo: the clickable demo's scripted session runs on your machine with every frame checked, with no hardware needed. make qemu-test SYSTEM=hello then boots seL4 in QEMU. Getting started walks through it.