RESENTMENT is a from-scratch operating system kernel for x86_64, ARM64 and RISC-V. It is not a Unix clone. Every capability carries a cryptographic seal with a deadline inside it, the whole machine has one Merkle root digest, and inference is a scheduling class rather than a userspace afterthought.
Each of these is a property of the design rather than a feature bolted on top. Take any one away and the other two stop being interesting.
There is no ambient authority. A task cannot open a file because it knows a path; it can only act on objects it holds a capability for, and every capability is checked four ways on every use — type, rights, generation, and a Kaalka seal.
The seal is the part a conventional design does not have. Revocation elsewhere is a sweep somebody has to remember to run. Here the deadline lives inside the MAC, so a forgotten permission stops working on its own and widening the window by editing the struct invalidates the seal.
Every kernel object is a node carrying a SHA-256 digest over a canonical encoding of its own fields plus the sorted digests of its children. The whole machine has one root hash.
Timestamps, ids and pointers are deliberately excluded from that encoding, so two machines that booted at different times but reached the same configuration hash identically. That single property is what makes state diffable, attestable and replayable instead of something you infer from logs.
A token-generation loop never sleeps for a human, so sleep-credit heuristics give it nothing. It is not batch either — it has a rate the user can see. It is a soft real-time stream, and SCHED_INFERENCE treats it as one: admitted with a declared rate, given a per-period budget, demoted rather than dropped when it overruns.
Attention caches are paged like memory, because they behave like memory. Pages are content-addressed by the digest of the tokens they cover, so two sessions with the same system prompt store it once.
Kaalka derives keying material from the angles between the hands of a clock. In userspace that is a cipher. In a kernel it is how time becomes something authority is measured in: epoch keys that are unrecoverable seconds later, capability seals that expire by construction, and replay defence with no protocol of its own.
Two departures from the reference implementation, both documented and
both verified. The trig core is Q32.32 fixed point,
because a kernel cannot use the FPU in interrupt context and libm is
not bit-reproducible across three architectures — and
make kaalka-check reports it 100% byte-identical
to the reference on every vector. And Kaalka supplies the schedule
while ChaCha20 and HMAC-SHA256 supply the strength;
saying that plainly is part of the design.
These are not libraries the kernel calls. Remove any one and a whole property of the system disappears with it.
Time-driven encryption derived from the angles between the hands of a clock.
Runtime graphs with stable node identity and content-addressed structure.
An English-like language whose programs start with exactly zero permissions.
Nothing above arch/ includes an architecture header. Each port boots to an interactive shell, uses every core the machine has, and passes the same 28 assertions driven over a serial link — including the attestation scenario the whole design exists for.
SYSCALL/SYSRET, IST stacks, SMEP/SMAP/NXCPU_ON/reserved-memory honoured, so OpenSBI's PMP regions are never touchedhart_startinclude/rk/arch.h and a boot stub — roughly forty functions
and one assembly file. The porting guide lists
every one of them, in the order a bring-up actually needs them.
A status table that overstates is worse than none. Everything below is a command you can run, and the output is what it prints.
make test1440 assertions against the real kernel sources, compiled for the host on a synthetic machine. It found a live alignment bug in the slab allocator on its first run.make qemu-test-allEvery architecture booted twice — single core, then with four — and driven through its shell over a serial socket.make kaalka-checkThe fixed-point port compared against the reference implementation, vector by vector.make verifyThe linked image read the way a bootloader will read it, before a bootloader gets the chance to be confused by it.$ make qemu-test-all
=== x86_64 ==================================================
x86_64: all 28 checks passed
=== aarch64 =================================================
aarch64: all 28 checks passed
=== riscv64 =================================================
riscv64: all 28 checks passed
=== x86_64-smp ==============================================
x86_64-smp: all 28 checks passed
=== aarch64-smp =============================================
aarch64-smp: all 28 checks passed
=== riscv64-smp =============================================
riscv64-smp: all 28 checks passed
every check passed on x86_64, aarch64, riscv64,
x86_64-smp, aarch64-smp, riscv64-smp
$ make test
1440 checks, 0 failuresOne command fetches a portable toolchain that targets all three architectures. No installer, no administrator rights, nothing added to your PATH.
git clone https://github.com/ni-sh-a-char/RESENTMENT---kernel
cd RESENTMENT---kernel
make toolchain # portable zig + nasm into .toolchain/
make # build for x86_64
make test # 1440 host assertions
make run # boot it under QEMU, no ISO needed
make run works because the build repackages the same
segments at the same physical addresses in Multiboot 1 headers, which
is what QEMU's -kernel loader understands. That is the
difference between a one-command test and a five-minute one.
# the other two architectures
make ARCH=aarch64
make ARCH=riscv64
make all-arch # all three — the portability check
# or use the container, which needs nothing installed
docker build -t resentment-build buildenv
docker run --rm -v "$PWD":/root/env resentment-build make isoEverything is in the tree. There are no dependencies: the kernel builds from its own sources plus a compiler, and the test suite needs nothing but Python.
Written down because the absences are choices rather than oversights. The full list, with reasons, is in the roadmap.
Boot to a shell on three architectures · SMP on all three · buddy allocator and slab heap · paging, address spaces, copy-on-write · four scheduling classes with admission control · capabilities with Kaalka seals · the runtime graph, snapshots and replay · the federated memory fabric · SHE compiler, VM and shell · SHA-256, HMAC, HKDF, ChaCha20, CSPRNG · VFS, ramfs, devfs, graphfs, initrd · IPC endpoints, channels, notifications · tensors, operators, accelerator HAL, paged KV cache, GGUF · VGA, framebuffer, serial and PS/2 consoles · syscall entry on all three.
Ring-3 userspace. The entry path and the syscall entry exist; the ELF64 loader does not. The interesting part is not the loader — it is what capability set a new process is handed, and how a parent narrows it.
Storage and network. PCI enumeration, virtio, a block layer and a protocol stack. Capabilities make a socket more interesting than usual: "this process may talk to this host until Tuesday" is expressible.
A model, end to end. Quantised kernels and a worked example generating tokens under SCHED_INFERENCE, with the scheduler trace visible in /graph/events.
The documentation on this site is the documentation in the repository — the same files, rendered. Nothing here is a marketing page for something that does not exist yet.