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.
30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
# 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 `/proc` channels 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.
|