// the find
haileys/jsos
An operating system written in JavaScript
JSOS is a small x86 operating system with a C kernel where most of the system, including the console, the shell, init, and several device drivers, is JavaScript running on a VM the author wrote in C. It is a research and hobby project for reading how far a JS engine can carry a kernel, not something to run for real work.
- The split is a real design choice, not a gimmick. The C side is the kernel plus a bytecode VM with a JIT (vm/src/jit.c) and a GC, and drivers like kernel/js/kernel/drivers/fat16.js, ide.js, and pci.js are ordinary JS on top of it.
- The userland runtime is small enough to read in an afternoon. libc is a few files (stdio.c, stdlib.c, string.c) with x87 math in assembly, so there is little hidden between a JS call and the hardware.
- The syscall surface is written down. docs/syscalls.md is generated by scripts/generate-syscall-docs.rb, so the interface is at least documented from a single source.
- The licensing is clear. The kernel, libc, compiler, and VM are BSD, and the one piece of borrowed code (from klange/osdev, NCSA) is called out in the README.
- The README is a license and one sentence. There are no build instructions, no QEMU invocation, and nothing about what boots or what the JS shell can do, so you will be reading Makefiles to get anything running.
- The toolchain is spread across Ruby (compiler/jsx_compiler.rb), CoffeeScript sources in kernel/js/bin, and a git submodule called twostroke that the README never mentions. Expect a fragile setup before you can rebuild a kernel.
- The last push was April 2024, and the repo has a committed hdd.base.img binary and kernel/build directories that hold only .gitkeep placeholders. It reads like a snapshot of a personal project rather than something maintained for other people.
- There is no test suite in the tree. The VM and GC are the parts most likely to break quietly, and the only checks visible in the listing are vm/gctest.c and a single JS demo, gltest.js.