The core idea: your files live inside applications. The app decides how you see your content, what you can do with it, and where your work gets saved. What if the OS just understood your files directly — rendered them, indexed them, tracked their history — and editors were tools you picked up only when you needed to change something? No “open with.” No Save button. You view by default, editing is deliberate.

What exists after one week: a from-scratch kernel in Rust on QEMU (aarch64), 27 syscalls, EEVDF scheduler with 4 SMP cores, a full display pipeline (compositor, subpixel TrueType rendering, alpha blending, PNG image viewer), structured IPC via shared-memory ring buffers, an editor process model where the OS service is the sole writer, a filesystem prototype, 900+ tests including a formal bug audit, and ~2,200 lines of design documentation with 13 settled architectural decisions. I’d never even seen Rust code before Friday.

Full story with demo, day-by-day timeline, how I worked with AI, and what I learned: https://github.com/jonathanrtuck/os/discussions/1

Repo: https://github.com/jonathanrtuck/os

I’m not trying to build the next Linux. This is a design exploration — can the document-centric model that OpenDoc and Xerox Star attempted actually work if you rethink the whole stack from the kernel up? I’m genuinely curious what this community thinks.