FAQ / System Queries

No. ITISYOU OS is an independent x86_64 kernel written in Rust (no_std). It contains no Linux kernel code at runtime and no GNU userland. It boots through the rust-osdev bootloader crate, not through a Linux boot chain.

No, and it does not claim to be. Linux is a mature, production-proven kernel ecosystem. ITISYOU OS is a research project testing different hypotheses — explicit authority boundaries, evidence-gated development, recoverability as architecture — for a constrained personal-computing target.

The project is pre-alpha at v0.2.0-dev, milestone “V0.2 — Userspace Foundation”. The V0.1 kernel foundation (boot, memory, interrupts, scheduler, filesystem, shell) is verified in QEMU, and V0.2 has verified Ring 3 userspace with a syscall ABI for a single process. The build page shows the live evidence-backed module table.

No — please don’t. The OS runs exclusively inside QEMU (BIOS and UEFI via OVMF) with project-generated disposable disk images. Physical-hardware boot is intentionally out of scope and untested, and the project’s own safety rules forbid pointing it at a real disk. Real hardware appears on the roadmap only for explicitly approved sacrificial devices, much later.

A virtual one: the QEMU x86_64 machine model, single CPU, no SMP. There is no USB, audio, Wi-Fi, Bluetooth, storage or GPU driver support. Claims will expand only when the corresponding milestones pass verification.

The kernel targets memory-safety discipline, testability and a minimal trusted computing base. Rust (no_std, x86_64-unknown-none) removes whole classes of memory errors by construction, keeps unsafe blocks localized and documented, and lets pure kernel logic be unit-tested on the host — the same code that runs in QEMU. See ADR-0001 in the repository.

A status becomes Verified only when an actual automated run proves it: the QEMU harness requires every expected boot-stage marker, an in-kernel selftest summary with zero failures, and a deterministic exit code — with serial logs and JSON results retained as evidence. “Implemented” (code exists) and “Verified” (evidence exists) are never interchangeable.

The rust-osdev bootloader hands the kernel a typed BootInfo (memory map, physical-memory mapping offset, framebuffer, RSDP). The kernel then walks a fixed stage contract, B000 through B150, emitting one machine-parseable serial marker per stage — the same contract the test harness asserts.

Any future AI layer may reason about the system and propose actions, but it never executes privileged kernel operations directly. Proposals flow through a deterministic pipeline — policy engine, risk/permission evaluation, user approval where required, a narrow privileged service — followed by verification, audit and rollback. No AI component exists in the current runtime; the principle exists now because it constrains kernel interface design.

Not yet, and it does not claim to be. As of V0.2 the kernel runs one userspace process at a time in Ring 3 with MMU-enforced kernel/user separation, validated syscalls, and crash containment — verified by automated QEMU tests. Isolation between multiple user processes (per-process page tables) is still future work. The security posture remains honest boundaries: documented trust boundaries, minimized and documented unsafe code, panic on violated kernel invariants, and strict VM containment so the host machine is never at risk.

The repository is private during early development while the V0.1 foundation and its verification evidence stabilize. It will open later; when it does, this site will link it directly. Until then the engineering documentation, status data and development ledger on this site are the public record.

Not yet — contributions become possible when the source opens. The honest groundwork for that is already public here: architecture, security model, testing strategy, roadmap and known limitations.