OSDev.org

Hi all,

I'd like to introduce Open Nexus OS, a research microkernel project targeting QEMU RISC-V virt, with an OpenHarmony-inspired userspace architecture.

The project is developed host-first, QEMU-last: most logic lives in host-testable userspace crates, while QEMU is mainly used for bounded end-to-end smoke proofs. The goal is to keep the lower layers explicit and testable instead of optimizing early for demos.

At this point, there is already a fair amount implemented or at least proven in the current architecture, including:
- networking on virtio-net / smoltcp
- DSoftBus-style service-to-service and cross-VM communication
- Noise XK-based authenticated transport work
- observability via logd + crash reporting
- a userspace A/B update skeleton
- capability-based policy / audit groundwork

The current work is still focused on lower-level foundations such as device/MMIO, persistence, identity/key material, and SMP baseline review/stabilization, rather than on early GUI polish.

One thing you will probably not see soon is a flashy GUI or an early demo-first console or shell experience. That is intentional. My task plan is ordered to minimize refactoring and architectural churn, not to maximize short-term presentability. I would rather bring up the system in the order that reduces rework than reshuffle the roadmap just to make it more visually demoable earlier.

All work is tracked in numbered tasks, and I work through them sequentially. Each task carries an explicit status at the top (Draft / In Progress / In Review / Done), so anyone interested can follow the roadmap and current progress directly from the repository.

I am not looking for co-developers at the moment. However, I am always happy to answer questions from anyone interested, and I always enjoy chatting about OS design, architecture trade-offs, task planning, testing strategy, and related topics.

Project links:
- Website: https://open-nexus-os.io
- Repository: https://github.com/open-nexus-OS/open-nexus-OS
- Software DOI: https://doi.org/10.5281/zenodo.18934993
- Papers:
- Part I: https://doi.org/10.5281/zenodo.18935402
- Part II: https://doi.org/10.5281/zenodo.18935755
- Part III: https://doi.org/10.5281/zenodo.18938789
- Part IV: https://doi.org/10.5281/zenodo.18939217
- Contract-Governed LLM Development: https://doi.org/10.5281/zenodo.18941284

If people are interested, I can post occasional milestone updates here when there is something concrete to show.

Thanks.

Your website gives a TLS error in both Firefox (SSL_ERROR_INTERNAL_ERROR_ALERT) and with curl.

jenningschaefer wrote: ↑Wed Mar 11, 2026 5:36 am The project is developed host-first, QEMU-last: most logic lives in host-testable userspace crates

As in just being able to run cargo test or being able to use the same binaries seamlessly on the host and in QEMU?
One of my goals is to allow development on a (Linux) host, then put the exact same binaries on a OS tuned for a specific task.

First of all, thanks a lot for posting your Error of my website. It is pretty late here so I will try to find out what happened tomorrow and hope I can fix this as soon as possible.

For your question, host-first means here most logic is developed and validated as normal host-runnable Rust crates, so a lot of day-to-day work is just cargo test, property tests, Miri, and other fast host-side checks.

It does not mean the exact same binary artifact runs unchanged on Linux and in QEMU. In my setup, the core logic is shared, but it is built against different backends/targets for host vs. OS. So the goal is “same logic, thin platform-specific boundary,” not “one identical binary everywhere.”

If your goal is to develop on Linux and later deploy the exact same binaries onto the target OS, that is a stronger requirement than what I mean by host-first here.

So in short: shared code and shared behavior model, yes; seamless identical binaries, no. I hope that answers the question.