# Made Visible #3: MLOS, Where Memory Means Something Else > Source: > Published: 2026-09-13 07:15:00+00:00 Part 1 drew a microkernel’s flash. Part 2 drew a conventional kernel’s frames and mappings. This one is neither. MLOS is a Rust kernel that boots in a VM and treats resident model state — weights, KV blocks, activations — as kernel objects with residency and tiering, the way Unix treats pages. What is drawn here is its storage and memory: weight tiles arranged in layers, colored by the tier they are resident in — disk, DRAM, or system RAM. Resource Link MLOS sw-ml-study/sw-os-ml How it works Made Visible #1 Comments Discord MLOS MLOS: weight tiles in layers, then one selected, then recolored by tier --- the same viewer, MLOS's own vocabulary. MLOS is the one that breaks the pattern. It is a Rust kernel, it boots in a VM, and its scarce resource is neither flash nor physical frames but resident model state — weights, KV blocks, activations — which it treats as kernel objects with residency and tiering the way Unix treats pages. So across the three, “where is it in memory” means three different things: a block offset in a flash device, a physical frame behind a virtual mapping, and a model object that is either resident or not. Different machines, different decades of hardware, different units of accounting. Same picture, because the question underneath is the same one: what is here, who owns it, and what class of thing is it? That is the point of showing more than one. A visualizer that only ever drew SWTOS would be a SWTOS feature. Drawing systems that share nothing but the question makes it a tool. What three systems bought One system drawn well is a feature of that system. Three systems that share nothing but the question — what is here, who owns it, what class of thing is it — make it a tool, and they are the reason the boundary in part 1 was worth drawing where it was. The visualizer still does not know what an operating system is. It never learned, across three of them.