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

Future AI agents must not execute privileged kernel operations directly. Agent intent flows through policy, permission evaluation, user approval and deterministic services — the kernel API is shaped for that now.

CONCEPT

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.