ITISYOU_OS

Why build another OS?

An operating system is not just a resource allocator; it is the boundary of trust for everything a person does on a machine. ITISYOU OS is a long-term research and engineering project exploring what a personal operating system could look like if designed today — from the kernel upward — around a specific set of hypotheses.

It is an experiment with evidence attached: nothing on this site is claimed beyond what the repository’s verification gates have recorded.

The hypotheses

What changes for a constrained personal-computing target when these are design inputs from the first boot stage rather than retrofits?

  • 01/ explicit privilege and authority boundaries
  • 02/ strong kernel/user isolation
  • 03/ capability-oriented security
  • 04/ recoverable and auditable system changes
  • 05/ deterministic privileged services
  • 06/ local-first intelligence
  • 07/ AI that reasons about the system without unrestricted kernel authority
  • 08/ reproducible configuration and builds
  • 09/ transparent resource ownership
  • 10/ minimal trusted computing base where practical
  • 11/ automatic diagnosis and verification
  • 12/ safe rollback and recovery
  • 13/ modern hardware assumptions over universal legacy compatibility

Engineering principles

The binding principles from the implementation plan, with the honest status of each — principles are practiced, not just stated.

Safety by isolation

V0.1 executes only in QEMU with project-generated disposable images — never pass-through host disks. The blast radius of a kernel bug is a throwaway VM.

IN DEVELOPMENT

Intelligence is not authority

AI agents must not execute privileged kernel operations directly. Agent intent flows through policy, permission evaluation, user approval and deterministic services. On the V0.11 development branch, shipped in v1.0.0, the first agent does exactly that: it files proposals the kernel checks, only the console approves, and the kernel executes, verifies and rolls back.

IN DEVELOPMENT

Small trusted core

Kernel responsibilities are explicit; clear subsystem boundaries and narrow interfaces are preferred over hidden global state. Pure logic lives outside the kernel where it can be host-tested.

IN DEVELOPMENT

Deterministic observability

Every boot stage is observable through serial output even if the framebuffer or keyboard path fails. One stage, one machine-parseable marker.

IN DEVELOPMENT

Failure is data

Panic output, QEMU exit codes, timeouts, exception vectors, failing assertions and serial tails are captured as structured evidence wherever possible.

IN DEVELOPMENT

Reproducibility

A fresh authorized developer or agent should be able to reconstruct the environment from versioned documentation and scripts alone — toolchain pinned, commands documented, builds repeatable.

IN DEVELOPMENT

Research direction, not rivalry

This project does not market itself as “better than Linux” — and won’t. The comparison below is about scope and intent, not quality.

Linux

Production-proven
  • 01/ Mature, production-proven kernel ecosystem spanning three decades of engineering.
  • 02/ Vast hardware support and an ecosystem serving billions of devices.
  • 03/ Compatibility guarantees and POSIX heritage that broad software depends on.

ITISYOU OS

EXPERIMENTAL
  • 01/ Pre-alpha research kernel testing specific hypotheses for one constrained personal-computing target.
  • 02/ QEMU-only, volatile interfaces, no compatibility promises — freedom to redesign boundaries.
  • 03/ Explicit authority boundaries and verification evidence as first-class design inputs.