Short intro
Chronosapien is not an attempt to build the next Linux. It is a learning system: a small, inspectable OS that forces me to touch the layers most application code hides.
What I was trying to do
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.
What I learned
- 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.
Technical notes
- 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.
Problems / open questions
- 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?
Next steps
- 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.