About
A notebook for things I find interesting.
I'm Aryan Narayan. The more you hold in memory, the higher the chance something gets killed — so I write things down here instead of keeping them in my head. This site is my external memory: a dump of things I've learned that I can revisit later, when the in-memory version has long since been evicted.
What this site is
oomkill.dev is my external memory. Human memory is leaky — keep too much in your head and the OS will quietly evict the parts you don't visit. This site is how I fight that: I write things down when I learn them so I can reload them later without re-deriving everything from scratch.
Most posts start as notes I'd otherwise lose: a diagram, a command that finally made sense, a small experiment that proved a point. I polish them enough to be worth revisiting — ideally in a month, a year, or whenever I hit the same problem again. That's the bar. Not a tutorial, not a tweet: a durable reference that still makes sense when I come back cold.
What I write about
Linux, networking, HTTP, Kubernetes, observability, performance — whatever I'm digging into at the moment. The common thread is systems that go wrong in quiet ways: the connection that looks alive but isn't, the pool that works fine until you scale, the metric that stays green while something is actually broken. If I can reproduce it in a homelab or a small demo and come away with a concrete mental model, it might end up as a post.
Why oomkill
The Linux OOM killer shows up when a machine runs out of memory and the kernel has to pick something to kill. It's blunt, it's impersonal, and it's a hard reminder that memory is finite and you can't just keep allocating forever.
The same thing happens in my head. The more I try to hold at once, the more gets silently evicted — usually the things I most want to keep. Writing here is my fix: get it out of volatile memory and into something persistent before the killer comes for it. The blog is the dump file.