You’re absolutely right that I led with terminology instead of value.
A simpler way to describe it is:
Hibana helps prevent protocol drift bugs in distributed systems.
You describe the interaction once as a global choreography, and each role gets a projected local API.
Because steps are affine (consumed once), invalid transitions like skipping, reusing, or taking the wrong branch are rejected by the type/protocol model.
So the practical goal is fewer hidden state-machine bugs, with one global source of truth for interaction order.
I appreciate the suggestion, and I’ll explain it this way in the next write-up.
Hibana( https://github.com/hibanaworks/hibana ) is an Affine MPST runtime for Rust. The key claim is type-system guardrails. In Hibana software behavior is written as global choreography, projected into role-local sessions, and invalid transitions are rejected by the type/protocol model instead of being handled ad hoc at runtime.
In simple terms, userland just issues syscalls to the kernel. For a command, this could be as straightforward as mkdir dir in the shell or mkdir("dir") in Rust code. While this seems simple, it's not particularly convenient. To enhance usability, we're modeling it after Rust's standard library. For example, having access to handy features like `DirBuilder` makes developing in userland more efficient (see https://doc.rust-lang.org/std/fs/struct.DirBuilder.html). Aligning with Rust's standard library has other benefits, too. One is the absorption of compatibility issues. Rust is compatible with various platforms, and handling compatibility at the level of the Rust standard library, rather than through syscalls or libc, can be more efficient. The goal is that Rust code used on one OS can be recompiled to work on my OS. From a unikernel perspective, recompilation is natural, and if we're only using Rust for development, it enhances safety. By the way, in my OS, libc does not exist. The user library, akin to Rust's std, acts entirely as a wrapper over syscalls.
Both those licenses require you to add the license text as a file to the codebase. Eg see the "How to apply the Apache License to your work" section in the Apache license link that you have there.
Since it's dual-licensed you can add one as LICENSE-MIT and the other as LICENSE-APACHE.
octox is also different in that the kernel, userland, mkfs, and build system are all implemented in Rust, and I think it is also different at the type level, for example, octox using mpmc for Pipe, and using OnceLock and LazyLock for static variable initialization.
Thanks. rxv64 kernel (the much harder part), syslib and ulib are in rust. Replacing userland C with rust would not be hard. Ideally a general purpose OS should support programs written in any of the common programming languages so it would make sense to have some programs in another language to keep the OS API "honest"!
You’re absolutely right that I led with terminology instead of value. A simpler way to describe it is:
Hibana helps prevent protocol drift bugs in distributed systems. You describe the interaction once as a global choreography, and each role gets a projected local API. Because steps are affine (consumed once), invalid transitions like skipping, reusing, or taking the wrong branch are rejected by the type/protocol model.
So the practical goal is fewer hidden state-machine bugs, with one global source of truth for interaction order.
I appreciate the suggestion, and I’ll explain it this way in the next write-up.
reply