9e38f78379
Two changes per the user's feedback that the slide had unused horizontal space and needed per-PDF context. Layout - The reference scene is now a 2-column grid inside the metric-stack: PDF iframe at ~1.7fr on the left, description panel at ~0.55fr on the right (min 280px). On narrow viewports (<1100px) it falls back to a vertical stack with the description capped to 240px. - Added #zoom=page-width to the iframe URL so the PDF's page fits its column width instead of leaving margins beside an 8.5x11 page rendered in a wider iframe. - Hide the prose card on the references scene — the description panel inside the stack covers what the prose was saying, and freeing the right edge gives the description proper room. Description content - Backend reads <stem>.md sidecar files alongside each PDF and returns the contents in the /api/references payload. - Frontend renders them with a tiny built-in markdown subset (headings, bold/italic, lists, inline code, paragraphs) — no third-party renderer dependency. - Initial draft sidecar .md files committed for the four PDFs currently in references/. Each describes how the paper informs a specific scene of the deck (which model row, which eval protocol, which channel selection). Edit them in place and the panel updates on the next reload.
1.3 KiB
1.3 KiB
Strongest published precedent for this exact setup
This paper applies transformer architectures to per-process
resource-utilisation metrics — the same shape of telemetry we
collect from /proc. Closest reference to "the project we're doing,
but already published."
What we borrowed
- Channel selection. Their list of
/procchannels overlaps heavily with ours (cpu_user_jiffies,cpu_sys_jiffies,rss_bytes,io_*_bytes,voluntary_ctxsw,involuntary_ctxsw, page-fault counters). Our 12-channel selection is essentially this set, validated. - Window-and-classify framing. They confirm that a transformer reading short windows of these counters beats per-window hand-features fed to gradient-boosted trees. That is exactly the comparison we run: KNN-on-features vs sequence-models-on-windows.
- Held-out-sample evaluation. They emphasise generalising to unseen malware families, not unseen time-slices of the same family. We adopt the same eval protocol on the perf scene.
Where it differs
- They use a much larger corpus and run on commercial endpoints; we run on three lab hosts and a Pi. Their numbers are an upper bound on what we can hope to reproduce — they're the target, not the floor.
- They don't publish their exact dataset, so the comparison is architectural, not reproductive.