Why I'm Building a Tiny OS in Rust

I wanted to understand how software starts running before there is a browser, framework, filesystem, or friendly runtime. The point is to meet the machine closer to the beginning.

• A hobby OS turns abstract systems concepts into concrete problems quickly.
• Bootloaders, target configuration, serial output, and framebuffer setup all become part of the product surface.
• Rust's no_std environment is a useful constraint because it removes assumptions from normal application development.
• Blank screens are not failure by themselves. They are feedback that the observability path is not good enough yet.

• The early stack is bootloader -> kernel entry -> serial logger -> framebuffer console -> interrupts -> keyboard -> shell.
• Serial logs are the first reliable UI because graphics can fail before a single pixel appears.
• Framebuffer output makes the OS feel visual, but text requires glyph rendering or a console abstraction.
• A tiny shell is useful even before there is a real filesystem because it creates a place to test commands and state.

• How much memory management should be built before the shell becomes more capable?
• What is the cleanest way to teach interrupts without hiding too much detail?
• Should the OS stay educational or evolve into a more playful retro computing environment?

• Keep serial logging boring and reliable.
• Make framebuffer text easier to debug.
• Add more shell commands that expose kernel state.
• Document each boot milestone as a short field note.