okay so this one’s been in my head for a while. every time I’m debugging something slow on linux I end up with like 3 terminals open — strace in one, perf in another, sometimes py-spy if it’s python — and I’m just manually lining up timestamps trying to figure out what actually caused the slowdown. none of these tools talk to each other. they just dump their own little slice of the truth and leave you to do the detective work.
so I built whyslow. it hooks into the kernel with eBPF and watches three things at once: scheduler switches, futex waits, and block I/O. instead of showing you three separate logs, it actually chains them together and tells you the story.
like instead of
thread stuck for 400ms (somewhere)
you get
thread A blocked on a futex
which was held by thread B
which was blocked on a disk read
that’s the whole point. not “something was slow” but “here’s the chain of custody for why.”
biggest pain building this was honestly not the eBPF part, it was figuring out how to correlate events that come from completely different sources without just guessing. had to build this whole interval-based matching thing to line up “thread went to sleep here” with “thread got woken up there” and make sure the causality actually holds up and isn’t just coincidence in timing.
kept scope small on purpose for v1. only 3 event types, no fancy stack traces yet, x86_64 + arm64 only. figured getting 3 things exactly right beats having 8 things that are kind of right and kind of not.
tested it by writing a little program that deliberately deadlocks itself with a futex and forces a disk read, so I’d have a known answer to check whyslow’s output against. felt really good when the chain it printed out actually matched what I knew was happening under the hood.
still needs root to run since eBPF just doesn’t let you do this stuff unprivileged, that’s a permanent tradeoff not a bug.
next up is probably symbol resolution so it can tell you actual function names instead of just thread ids, and getting it properly published so people can just cargo install it instead of pulling from git.
repo’s here if anyone wants to poke at it: github.com/kaorii-ako/whyslow

Shipping whyslow v1

The problem

Every Linux dev has hit “my program is slow” and reached for strace,
perf, or py-spy — but each tool sees one layer. None of them tell you
why across layers. You end up manually cross-referencing three terminal
windows and timestamps by hand.

What I built

whyslow — a CLI that watches sched_switch, futex, and block I/O events
via eBPF and stitches them into a single causal chain:

$ sudo whyslow run -- ./my-slow-program
 
14:32:07.001 — tid 4821 blocked 412ms on futex 0x7f2a3c001000
 ← woken by tid 4809
 ← tid 4809 blocked 380ms on block I/O (dev nvme0n1p2, sector 88213)

No manual correlation. It finds the root cause and walks you back to it.

Stack

• Rust, aya for pure-Rust eBPF (no libbpf/C toolchain needed)
• Ring buffer for low-overhead event collection — can’t perturb the thing
  you’re measuring
• Interval tree + happens-before edge inference for the causal graph
• Workspace: whyslow-cli, whyslow-ebpf, whyslow-common

Scope for v1

• x86_64 + aarch64 Linux, kernel 5.8+
• Three event sources: sched_switch, futex, block I/O
• No stack symbolication yet — tid/pid/comm only
• Needs root or CAP_BPF — no way around that, eBPF is privileged
  Kept scope narrow on purpose: three event sources done correctly beats
  eight done half right. Validated against a synthetic program that
  deliberately causes futex contention + a disk stall, so there’s ground
  truth to check the causal chain against, not just vibes.

Distribution

• curl -sSf .../install.sh | sh
• Homebrew tap, APT repo, pip wrapper — see DISTRIBUTION.md
• crates.io publish still pending — cargo install works via --git for now

What’s next

• Stack symbolication (native + interpreted languages)
• More event sources without losing causal-chain accuracy
• Actual crates.io publish so cargo install whyslow just works

Repo

github.com/kaorii-ako/whyslow

shipped the portfolio. dark, minimal, 3D, actually interactive — not another cream-background-serif template.

four pages: home, projects, about, contact. proof section leads with QBoard (macropad, XIAO RP2040, QMK, KiCad — repo: github.com/kaorii-ako/QBoard), alongside axon OS and the F1 CFD work.

near-black background, off-white text, one accent color, space grotesk for headers, jetbrains mono for code/labels. checked it on desktop and mobile, fixed the spacing/overflow stuff that broke on smaller screens.

live now.

CLEARED is a flight-themed deep focus timer, built with Tauri 2 (Rust + React + TypeScript). Instead of a plain countdown, every focus session is framed as a flight: pick your home airport, choose a destination and flight duration, pick a seat class, get a boarding pass, then watch a live animated flight map track your session in real time. Land, and you get a streak + miles tracked over time.
Stack:

• Rust (Tauri 2) backend - timer logic, SQLite persistence, system tray, native notifications
• React 19 + TypeScript + Tailwind CSS 4 frontend
• Framer Motion for the flight animations

Features shipped in v0.1.0:

• Full onboarding → destination/seat picker → boarding pass → live tracking flow
• Background system tray timer + native completion notifications
• Local SQLite session history with stats

Repo: github.com/kaorii-ako/CLEARED

Devlog #1 — Vox: push-to-talk dictation

Started Vox: free, open-source, bring-your-own-key dictation. Hold a hotkey, speak, release — cleaned-up text pastes at your cursor. Tauri + Rust, with an LLM pass that polishes the raw transcript.

Funniest bug so far: dictate “do you want to go with a race” → Vox types “I don’t identify with a particular race.” The transcript went to the LLM as a plain chat message, so it answered dictated questions instead of transcribing them. Fixed by wrapping the transcript in <transcript> tags and adding a hard rule: never answer, only clean up. Tested against a local llama3.2 — 4/4 trap inputs now transcribe correctly.

Also wrestled the release CI: macOS builds needed a 10.15+ deployment target for whisper.cpp, Windows ARM doesn’t build upstream yet (dropped it).

Shipped v0.2.2: Linux, Windows, macOS.

Make it look not AI Generated

Portfolio Website — kaorii-ako.vercel.app

Built a personal portfolio from scratch with Next.js 14, Three.js, and Framer Motion. Key features:

• 3D Hero - Interactive Three.js icosahedron
• GitHub Dashboard
• Project
• Custom Design — Syne + Manrope fonts, glass morphism, film grain texture, scroll animations

Stack: TypeScript, Tailwind CSS, Three.js (@react-three/fiber), Framer Motion, Lucide icons. Deployed on Vercel.

Theres also some secret features if you press ctrl+ `

What I built

STDerr is a Slack bot for developers. A little something you’d actually use mid-coding when you’re too lazy to open a browser. Three commands:

/stderr-ping - STDerr latency test

/stderr-connect - Connect to your AI provider with your API key

/stderr-stack [error] - turns a error message into how and what caused it. Powered by your AI provider with API Key

/stderr-timestamp - returns unix timestamp + ISO 8601.

/stderr-commit [description] - turns description into a proper conventional commit message (feat:, fix:, chore:, etc.) powered by your AI provider with API Key

/stderr-regex [description] - turns description into a Regex expression that you can use.

Stack:

• index.js - Main Slack bot (Socket Mode)
• ai.js - Unified AI chat interface
• providers.js - Provider registry
• store.js - Per-user config persistence

Done all the wirings for the PCB.

Currently trying to install fusion onto my linux (Zorin - Ubuntu) right now. If anyone knows how to do it please let me know.

Adding more AI to the settings!

v3 and final.
https://noct-os.vercel.app/os

made safari work (kinda)
and improved terminal and main vibes