From 69b87777e5408fc5882653601c661231a7f60863 Mon Sep 17 00:00:00 2001
From: Ed_ <edwardgz@gmail.com>
Date: Tue, 25 Aug 2026 16:26:52 -0400
Subject: [PATCH] make handles bold.

---
 .github/workflows/deploy.yml                  |   2 +
 ...ad-multiple-line-stores-collecting-on-a.md | 188 +++++++++---------
 ...-its-going-to-be-much-slower-you-can-do.md |   8 +-
 .../index.md                                  |  48 ++---
 ...er-introduced-me-to-the-entity-paradigm.md |   4 +-
 ...ies-dont-have-to-go-but-having-a-mental.md |  32 +--
 ...ou-even-have-a-functioning-game-without.md |  20 +-
 ...Shioto-object-data-stuff-function-stuff.md |   4 +-
 ...ing-is-just-functions-and-variables-its.md |   4 +-
 ...heres-a-whole-book-about-this-https-www.md |   4 +-
 ...25-RaykiruS-so-not-an-ecs-but-only-a-es.md |   4 +-
 ...are-guidelines-but-coding-is-a-holistic.md |   4 +-
 ...y-thing-you-ever-need-to-think-about-is.md |   4 +-
 ...ause-entities-and-ecs-are-the-new-shiny.md |   4 +-
 ...out-being-turing-complete-just-requires.md |   4 +-
 ...-matters-is-memory-and-logic-everything.md |   4 +-
 ...re-no-universal-pattern-common-to-every.md |   4 +-
 .../2026-03-25-mcnabbd-thread.md              |   4 +-
 ...ames-objects-arrays-singletons-thats-it.md |   4 +-
 ...-like-the-actually-useful-patterns-just.md |   8 +-
 .../2026-03-25-samloeschen-team-fat-struct.md |   4 +-
 ...y-you-realize-literally-nothing-matters.md |   4 +-
 ...ull-haskell-and-realize-that-everything.md |   4 +-
 ...-a-take-for-the-whole-software-industry.md |   4 +-
 ...nctions-that-operate-on-structs-classes.md |   4 +-
 ...-03-26-eta9499-you-are-almost-there-unc.md |   4 +-
 .../index.md                                  |   6 +-
 ...believe-im-still-writing-games-in-win32.md |   4 +-
 ...is-heaven-when-you-see-what-else-is-out.md |   4 +-
 ...entally-i-made-a-vulkan-wayland-compute.md |   4 +-
 ...-actually-prefer-wayland-because-if-you.md |  50 ++---
 ...dows-makes-some-interesting-choices-lol.md |   4 +-
 ...-i-appreciate-about-wayland-is-that-its.md |   4 +-
 ...inux-apples-and-oranges-comparison-here.md |   4 +-
 .../2026-01-12-FoundryOfLies-its-kwin.md      |   4 +-
 ...st-you-to-stick-with-glfw-if-youre-only.md |   4 +-
 .../2026-01-12-Oka7071-thread.md              |   8 +-
 ...-well-win32-began-as-a-bad-api-and-then.md |   4 +-
 .../2026-01-12-Rami36217810-what-about-x11.md |   8 +-
 ...-12-SyntaxError2505-why-sdl-works-great.md |   4 +-
 .../2026-01-12-f82james-fuck-x11.md           |   4 +-
 ...enough-with-how-old-the-wine-project-is.md |   4 +-
 ...x-elaborate-please-im-still-an-x11-user.md |   4 +-
 ...h-is-like-a-nightmare-but-real-it-is-so.md |   4 +-
 ...2026-01-12-ruminaik-and-let-us-say-amen.md |   4 +-
 ...-instead-if-youre-using-arch-btw-its-in.md |   4 +-
 .../index.md                                  |  10 +-
 ...a-person-with-a-phd-that-might-disagree.md |  32 +--
 .../index.md                                  |   4 +-
 ...ly-thing-on-many-levels-the-entire-arch.md |   4 +-
 ...04-24-matiasgoldberg-whats-the-value-of.md |   4 +-
 .../index.md                                  |   6 +-
 .../index.md                                  |  68 +++----
 .../2022-11-04-rianflo-welcome-not-back.md    |   4 +-
 .../index.md                                  |   4 +-
 .../index.md                                  |  42 ++--
 .../index.md                                  |   2 +-
 .../index.md                                  |   4 +-
 .../index.md                                  |   2 +-
 .../index.md                                  |  10 +-
 ...-see-these-return-still-have-any-of-the.md |   8 +-
 ...mber-watching-all-of-these-blog-entries.md |   4 +-
 ...uutensei-is-the-blog-still-up-somewhere.md |  12 +-
 ...rite-an-engine-called-atom-talked-about.md |   8 +-
 ...-all-those-fondly-i-also-remembered-the.md |   4 +-
 ...r-thesis-advisor-was-a-big-proponent-of.md |  12 +-
 ...hen-i-learned-about-your-work-and-found.md |   4 +-
 ...s-for-digging-those-up-great-stuff-very.md |   4 +-
 .../index.md                                  |  32 +--
 ...an-apu-a-way-to-have-the-storage-device.md |  84 ++++----
 .../2023-06-20-SheriefFYI-great-thread.md     |   4 +-
 ...-nvidia-has-a-very-good-uvm-however-the.md |   4 +-
 .../index.md                                  |  18 +-
 ...-nice-to-talk-a-full-presentation-about.md |   8 +-
 ...n-a-while-people-need-to-be-reminded-to.md |   8 +-
 ...-this-given-i-never-write-code-any-more.md |   4 +-
 ...leonard_coder-4e71-if-you-know-you-know.md |   8 +-
 ...-a-language-beads-which-uses-a-graph-db.md |   4 +-
 ...-used-to-be-like-that-at-least-the-ones.md |   4 +-
 ...ing-it-disoriented-programming-just-the.md |   4 +-
 .../2023-07-01-SimonNordon-nop-is-ideal.md    |   4 +-
 ...teach-it-in-abstinence-only-programming.md |   4 +-
 ...023-07-01-asparagiii-looks-like-a-koala.md |   4 +-
 ...are-is-absense-of-it-https-en-wikipedia.md |   4 +-
 .../2023-07-01-claudiogonzalo-c-to-c.md       |   4 +-
 ...lks-theyre-calling-it-computer-oriented.md |   4 +-
 .../2023-07-01-mike_acton-thread.md           |   4 +-
 ...ter-https-github-com-wyattscarpenter-wu.md |   4 +-
 .../index.md                                  |   2 +-
 .../index.md                                  |  14 +-
 .../index.md                                  |  10 +-
 .../index.md                                  |   8 +-
 .../index.md                                  |  26 +--
 ...esting-crosstalk-from-voltage-inversion.md |  24 +--
 .../index.md                                  |  10 +-
 ...quite-sure-what-do-you-mean-by-subpixel.md |  12 +-
 .../index.md                                  |   8 +-
 ...sses-do-you-need-to-produce-this-result.md |   8 +-
 .../index.md                                  |   8 +-
 ...sign-one-api-for-each-separate-use-case.md |   8 +-
 .../2023-12-15-long-thread/index.md           |  50 ++---
 ...put-the-whole-game-logic-in-a-game-glsl.md |   6 +-
 ...int-six-seconds-d3d12createdevice-on-my.md |  20 +-
 ...-preallocating-every-type-of-descriptor.md |  34 ++--
 .../index.md                                  |  20 +-
 .../index.md                                  |   6 +-
 ...debuggers-should-be-debuggers-made-zero.md |   4 +-
 .../index.md                                  |   4 +-
 ...le-project-knowledge-well-worth-sharing.md |   4 +-
 ...AH-ha-that-wont-save-you-from-my-follow.md |   4 +-
 ...im-deep-in-optimising-shaders-in-an-aaa.md |   4 +-
 .../index.md                                  |   4 +-
 .../index.md                                  |   4 +-
 ...h-line-is-63-spaces-followed-by-a-n-and.md |  16 +-
 ...ck-do-you-care-about-cache-lines-if-you.md |  28 +--
 ...s-super-cool-but-why-map-a-file-and-not.md |  20 +-
 ...hy-you-memory-map-the-32-bit-counter-to.md |  12 +-
 .../index.md                                  |  20 +-
 .../index.md                                  |  16 +-
 ...le-in-your-experience-in-code-like-that.md |  32 +--
 .../index.md                                  |  66 +++---
 ...gileJebrim-shouldnt-uniform-be-a-scalar.md |  64 +++---
 .../index.md                                  |  22 +-
 ...are-its-really-curious-they-still-stick.md |   4 +-
 .../index.md                                  |  22 +-
 .../index.md                                  |   4 +-
 ...gh-current-compilers-are-a-bloated-mess.md |   4 +-
 .../index.md                                  |  16 +-
 ...ou-tried-using-the-intel-cache-controls.md |  12 +-
 .../index.md                                  |  34 ++--
 ...ts-pretty-amazing-how-good-the-hastings.md |   4 +-
 ...ptimization-ideas-1-for-rdna2-simd-insn.md |  12 +-
 ...king-at-a-very-similar-problem-for-hemi.md |   4 +-
 .../index.md                                  |  14 +-
 .../index.md                                  |  12 +-
 .../index.md                                  |  24 +--
 .../index.md                                  |  28 +--
 ...s-similar-but-i-also-feel-that-a-lot-of.md |  12 +-
 ...framegen-was-just-an-offspring-of-mpeg2.md |   4 +-
 ...sualization-of-said-cold-caches-on-a-cs.md |  24 +--
 .../index.md                                  |  36 ++--
 ...raw-spatial-scaling-in-a-custom-resolve.md |  22 +-
 ...mindset-is-more-tuned-towards-rendering.md |   8 +-
 .../index.md                                  |  50 ++---
 .../index.md                                  |   4 +-
 .../2025-02-04-gelatinous-pixel-soup/index.md |  40 ++--
 ...-shader-compiler-not-do-this-i-e-detect.md |   8 +-
 ...be-interested-to-see-a-concrete-example.md |   8 +-
 ...-cache-locality-and-memory-handling-are.md |   4 +-
 ...tandardized-documented-isa-that-enables.md |  32 +--
 .../index.md                                  |  24 +--
 ...hnuke-and-people-think-c-is-the-optimal.md |  12 +-
 ...de-compilation-is-inherently-sequential.md |  12 +-
 .../2025-04-30-onatt0-simply-brilliant.md     |   4 +-
 .../index.md                                  |  28 +--
 ...-thoughts-0-having-a-low-upper-bound-on.md |  36 ++--
 .../index.md                                  |   4 +-
 ...s-the-restart-number-come-from-i-assume.md |   4 +-
 .../index.md                                  |  38 ++--
 ...-given-up-on-trying-to-massage-frontend.md |  32 +--
 ...-top-something-else-ive-been-out-of-the.md |  20 +-
 ...the-plan-is-to-have-the-data-read-write.md |   4 +-
 .../index.md                                  |  20 +-
 ...ly-isnt-hard-its-just-platform-specific.md |   4 +-
 ...xy4MyGPU-it-was-never-hard-just-tedious.md |   4 +-
 ...en-writing-assembly-for-almost-40-years.md |  16 +-
 ...ed-but-i-would-also-love-a-look-at-your.md |   8 +-
 ...Drisc0ll-im-sure-it-would-be-invaluable.md |   4 +-
 ...-would-and-i-think-more-people-would-be.md |   4 +-
 ...ve-only-done-asm-on-amiga-with-devpac-i.md |   8 +-
 ...been-doing-assembly-a-bit-in-d-with-the.md |   8 +-
 ...-people-who-claim-assembly-is-hard-just.md |   4 +-
 ...0-im-learning-assembly-in-my-spare-time.md |   4 +-
 ...-31-biovf-i-would-definitely-watch-that.md |   4 +-
 ...-07-31-cyberbemon-id-love-to-watch-that.md |   4 +-
 ...are-a-lot-of-watch-me-write-this-app-in.md |   4 +-
 .../2025-07-31-furan-would-watch-though.md    |   4 +-
 ...ot-a-blank-canvas-go-for-it-interfacing.md |   8 +-
 ...oing-assembly-as-hobby-68k-assembly-x64.md |  20 +-
 ...07-31-m6502-i-would-enjoy-watching-that.md |   4 +-
 ...if-one-is-ok-with-bottom-up-thinking-99.md |   4 +-
 ...tely-interested-in-anything-you-put-out.md |   4 +-
 ...-07-31-nullspector-i-would-so-love-that.md |   4 +-
 ...aying-maybe-for-vulkan-depending-on-how.md |   4 +-
 .../2025-07-31-opdroid1234-i-would.md         |   4 +-
 ...sh-the-win32-api-was-better-designed-it.md |  14 +-
 ...025-07-31-plasmabitcoin-very-interested.md |   4 +-
 .../2025-07-31-pranksterware-thatd-rock.md    |   4 +-
 ...2025-07-31-roasted6read-i-am-interested.md |   4 +-
 ...ery-interested-in-it-also-on-your-forth.md |   4 +-
 ...lex_fx-is-it-already-aprils-fools-again.md |  20 +-
 .../2025-07-31-ssh4net-please.md              |   4 +-
 ...y-isnt-hard-its-tedious-no-abstractions.md |   4 +-
 .../2025-07-31-totalwert-thread.md            |   4 +-
 ...tart-pretending-i-understood-everything.md |   4 +-
 ...25-08-01-AnshumanKhanna5-video-link-now.md |   4 +-
 ...nt-really-matter-what-language-you-call.md |   4 +-
 ...now-someone-whod-be-excited-opdroid1234.md |   4 +-
 ...zb589-i-would-watch-that-so-count-me-in.md |   4 +-
 .../index.md                                  |  12 +-
 ...on-the-cart-style-memory-model-i-assume.md |  26 +--
 ...-08-01-joeyazf-sounds-super-interesting.md |   4 +-
 ...ooking-forward-to-it-what-do-i-bookmark.md |   4 +-
 ...lly-hope-you-do-this-find-your-posts-so.md |   4 +-
 .../index.md                                  |   6 +-
 ...t-i-do-one-pinned-thread-per-core-sched.md |   4 +-
 ...-works-well-only-if-your-program-is-the.md |   4 +-
 ...ave-a-source-from-which-one-could-learn.md |  28 +--
 .../index.md                                  |  16 +-
 ...-ever-logged-or-some-agreement-that-its.md |   8 +-
 ...ed-the-video-and-one-thing-that-was-not.md |   8 +-
 .../index.md                                  |  10 +-
 ...sed-is-a-significant-improvement-but-it.md |   8 +-
 ...-still-on-opengles-and-webgl-which-dont.md |   4 +-
 ...-had-real-depth-precision-issues-in-our.md |   4 +-
 ...e-far-doesnt-apply-to-ortho-and-many-of.md |   4 +-
 ...really-done-graphics-in-a-while-but-ive.md |   8 +-
 .../index.md                                  |  10 +-
 .../2026-01-14-can-do-that/index.md           |   4 +-
 ...-not-just-use-more-historical-frames-to.md |   8 +-
 .../index.md                                  |  16 +-
 .../index.md                                  |  14 +-
 ...nt-have-to-be-like-this-but-the-new-dma.md |  32 +--
 ...to-see-how-the-gpu-side-audio-turns-out.md |   8 +-
 ...-seemingly-incorrect-due-to-its-use-for.md |   4 +-
 .../index.md                                  |  24 +--
 ...u-do-the-multiply-in-uint128-t-and-then.md |  12 +-
 .../index.md                                  |   6 +-
 ...i-am-still-debugging-by-looking-at-if-a.md |   8 +-
 .../index.md                                  |   6 +-
 ...-think-your-even-suppose-to-change-your.md |   8 +-
 .../index.md                                  |   4 +-
 .../index.md                                  |   4 +-
 .../index.md                                  |   2 +-
 .../index.md                                  |   2 +-
 ...ut-no-c-for-me-so-runit-wins-by-default.md |   2 +-
 ...o-give-artix-lxqt-runit-variation-a-try.md |   6 +-
 ...e-is-this-thin-with-win11-right-now-but.md |   4 +-
 ...ing-to-me-how-this-challenge-would-have.md |   8 +-
 .../index.md                                  |   8 +-
 ...00-interesting-font-does-it-have-a-name.md |   4 +-
 .../index.md                                  |  12 +-
 ...futex-impls-ive-seen-check-for-that-and.md |   8 +-
 ...c-implementation-would-do-that-i-bypass.md |   4 +-
 ...eep-0-will-sleep-for-the-timer-slack-mm.md |   8 +-
 ...-people-trying-to-push-high-frame-rates.md |  16 +-
 ...-do-a-gradual-sleeping-start-with-while.md |  16 +-
 .../index.md                                  |   4 +-
 ...an-use-camac-free-to-take-raw-photos-on.md |   8 +-
 ...-06-13-quiveron_x-why-are-you-using-crt.md |  10 +-
 ...ng-i-wonder-if-crts-can-be-changed-like.md |   4 +-
 ...-14-mayemayey-ohh-what-is-that-a-2070sb.md |  24 +--
 .../index.md                                  |   6 +-
 ...n-crt-or-are-you-emulating-scanlines-in.md |   4 +-
 ...0-chance-you-actually-use-this-font-its.md |  16 +-
 ...06-15-sadhuIGI-also-this-font-is-cursed.md |   4 +-
 .../index.md                                  |   2 +-
 ...ecvmmsg-can-only-work-with-1024-packets.md |  22 +-
 ...k-at-http-lalists-stanford-edu-lad-2001.md |   4 +-
 .../index.md                                  |   2 +-
 .../index.md                                  |   4 +-
 ...actually-reached-out-to-said-developers.md |  16 +-
 ...ay-does-sndrv-pcm-ioctl-hw-params-ioctl.md |  12 +-
 .../index.md                                  |  22 +-
 .../index.md                                  |   4 +-
 .../index.md                                  |   6 +-
 .../index.md                                  |   4 +-
 ...-a-lot-of-old-news-around-1-wine-doesnt.md |   8 +-
 ...two-truths-ive-come-to-accept-in-life-a.md |   4 +-
 ...-about-to-say-i-recall-pulling-this-off.md |   4 +-
 ...c-you-could-pretend-to-be-an-audio-jack.md |   4 +-
 .../index.md                                  |   4 +-
 .../index.md                                  |  10 +-
 .../index.md                                  |   8 +-
 .../index.md                                  |   8 +-
 .../index.md                                  |  12 +-
 ...dioclient-getdeviceperiod-returns-53333.md |   2 +-
 ...once-upon-a-time-wine-didnt-implement-a.md |   4 +-
 .../index.md                                  |   8 +-
 ...-neat-but-is-it-really-true-in-practice.md |   8 +-
 .../index.md                                  |   2 +-
 .../index.md                                  |  10 +-
 .../2026-07-09-BigP4P4Smurf-and-preempt-rt.md |   4 +-
 ...ou-can-also-set-nohz-so-theres-no-timer.md |   4 +-
 ...nk-this-is-simply-available-as-a-kmsdrm.md |  16 +-
 .../index.md                                  |   6 +-
 ...ing-a-stroke-what-is-this-font-it-feels.md |   4 +-
 .../index.md                                  |   6 +-
 .../2026-07-14-bkaradzic-much-clearer.md      |   4 +-
 ...t-this-point-could-make-a-dsl-with-perl.md |   4 +-
 .../index.md                                  |   8 +-
 .../index.md                                  |   6 +-
 .../index.md                                  |  12 +-
 .../index.md                                  |  10 +-
 ...the-tangent-what-is-this-font-and-where.md |  12 +-
 .../index.md                                  |   2 +-
 ...-smaller-code-size-possible-with-custom.md |   4 +-
 .../index.md                                  |   6 +-
 ...instrs-are-anything-but-fast-and-if-you.md |  32 +--
 .../index.md                                  |   6 +-
 .../index.md                                  |  10 +-
 .../index.md                                  |  10 +-
 .../index.md                                  |  24 +--
 .../2026-08-23-operands-time-perf/index.md    |  18 +-
 .../index.md                                  |  12 +-
 .../index.md                                  |  16 +-
 ...ho-cares-do-what-makes-you-happiest-and.md |   4 +-
 ...h-visual-studio-had-better-code-context.md |   4 +-
 ...-globals-defines-were-warm-members-blue.md |  12 +-
 ...-good-faith-reply-is-if-youre-a-systems.md |   4 +-
 ...wrong-with-new-tools-its-just-that-most.md |   4 +-
 ...on-some-large-corps-demand-that-we-have.md |   4 +-
 ...should-write-your-code-on-paper-by-hand.md |   4 +-
 ...ble-to-code-without-assistant-is-a-good.md |   4 +-
 ...mber-how-my-technical-school-assigned-a.md |   4 +-
 ...because-high-arrogance-low-intelligence.md |   4 +-
 ...and-ides-honestly-i-wouldnt-use-notepad.md |  12 +-
 ...much-agree-with-you-but-i-started-using.md |   4 +-
 ...4-05-03-IlyasHairline-to-flex-on-others.md |   4 +-
 ...mber-having-an-argument-with-one-of-the.md |   4 +-
 ...-thought-coding-seemed-cool-and-wrote-a.md |   4 +-
 ...eping-programming-and-thinking-it-makes.md |   4 +-
 ...ig-difference-between-being-able-to-and.md |   4 +-
 ...ve-a-superiority-complex-for-working-in.md |   4 +-
 ...-be-able-to-code-in-notepad-just-so-you.md |   4 +-
 ...gree-especially-if-youre-learning-a-new.md |   4 +-
 ...uldnt-have-to-code-this-way-for-serious.md |   4 +-
 ...2024-05-03-NeutralRational-hes-a-boomer.md |   4 +-
 ...the-point-is-that-you-should-be-able-to.md |  32 +--
 ...024-05-03-OscarBR92-to-assert-dominance.md |   4 +-
 ...nothing-has-more-forever-a-junior-level.md |   4 +-
 ...st-another-it-twitter-bait-just-mute-or.md |   4 +-
 ...-write-all-my-code-in-assembler-too-but.md |   6 +-
 ...abudya-chill-bro-its-an-engagement-bait.md |   4 +-
 ...ts-available-use-it-though-in-my-case-i.md |   4 +-
 ...s-trying-to-act-like-their-depreciating.md |   4 +-
 ...-a-showcase-of-the-im-stronger-than-you.md |   4 +-
 ...or-the-first-few-months-of-my-first-web.md |   4 +-
 ...once-interviewed-where-they-asked-me-to.md |   4 +-
 ...to-consider-to-go-back-to-a-simple-text.md |   4 +-
 ...nt-actually-do-it-you-should-be-able-to.md |   4 +-
 ...ople-feel-scared-to-give-up-lower-level.md |   4 +-
 ...3-_Felipe-blue-check-farming-engagement.md |   4 +-
 ...key-word-is-able-how-many-people-cannot.md |   4 +-
 ...eme-from-a-person-who-posts-nothing-but.md |   4 +-
 .../2024-05-03-baris2c-its-bait.md            |   4 +-
 ...oder-bravado-to-show-off-toy-algorithms.md |   4 +-
 ...e-signaling-but-its-like-being-proud-of.md |   4 +-
 ...use-when-you-have-to-fix-something-on-a.md |   4 +-
 ...should-be-able-to-code-with-punch-cards.md |   4 +-
 ...-is-not-about-when-you-dont-want-to-use.md |   4 +-
 ...nti-tooling-discourse-in-programming-is.md |   4 +-
 ...you-should-be-able-to-it-shows-that-you.md |   4 +-
 ...ogrammers-use-a-magnetized-needle-and-a.md |   4 +-
 ...lisense-is-just-a-faster-way-of-finding.md |   4 +-
 ...ted-in-notepad-now-i-use-vim-for-all-my.md |   4 +-
 ...that-at-an-interview-once-a-programming.md |   4 +-
 ...-in-an-interview-where-they-handed-me-a.md |   4 +-
 ...the-meme-works-infinitely-better-if-you.md |   4 +-
 ...-05-03-heyotetsuo-use-whatever-you-want.md |   4 +-
 ...eme-isnt-saying-you-shouldnt-use-it-its.md |  28 +--
 ...thats-how-we-learned-and-you-should-too.md |   4 +-
 ...-telling-a-carpenter-you-should-be-able.md |   8 +-
 ...es-old-people-feel-cool-because-they-at.md |   4 +-
 ...n-intellisense-yourself-if-you-have-the.md |   4 +-
 ...-able-to-doesnt-mean-prefer-to-its-just.md |  12 +-
 .../2024-05-03-megaloid6-you-are-weak.md      |   4 +-
 ...here-is-some-value-in-this-at-least-for.md |   4 +-
 ...t-about-wanting-its-about-being-able-to.md |   4 +-
 ...-to-do-that-but-to-be-able-to-if-unable.md |  20 +-
 ...t-gaslight-themselves-that-their-broken.md |   4 +-
 ...itors-tend-to-lead-to-other-bad-choices.md |   4 +-
 .../2024-05-03-sksauli-this.md                |   4 +-
 ...rfpappa123-the-decel-mind-is-perplexing.md |   4 +-
 ...ocating-for-notepad-coding-is-much-like.md |   4 +-
 ...dev-to-prove-twitter-theyre-good-coders.md |   4 +-
 ...of-agree-but-im-so-often-forced-to-code.md |   4 +-
 ...vious-engagement-farming-rage-bait-just.md |   4 +-
 ...ire-to-appear-extraordinarily-competent.md |   4 +-
 ...-dont-want-the-distractions-i-dont-want.md |   4 +-
 ...ree-with-the-original-poster-you-should.md |   4 +-
 ...sed-notepad-for-my-shitty-terraria-mods.md |   4 +-
 ...k-people-should-be-able-to-code-without.md |   4 +-
 ...-an-argument-where-people-build-systems.md |   4 +-
 ...is-is-just-another-expression-of-the-if.md |   4 +-
 ...tekeeping-really-there-has-never-been-a.md |   4 +-
 ...y-a-lot-of-the-framework-and-transpiler.md |   4 +-
 ...we-are-limited-by-our-environment-which.md |   4 +-
 ...ke-you-should-only-code-without-support.md |   4 +-
 ...hy-do-they-teach-arithmetic-we-all-have.md |   4 +-
 ...ad-but-i-have-done-a-non-zero-amount-of.md |   4 +-
 ...ill-justify-programming-c-c-on-linux-on.md |   4 +-
 ...u-cant-code-tcl-using-vi-through-a-bash.md |   4 +-
 ...ld-say-you-should-code-in-a-way-that-is.md |   4 +-
 ...the-skill-issue-is-strong-with-this-one.md |   4 +-
 ...o-code-in-c-back-in-2011-and-my-teacher.md |   4 +-
 ...hen-there-is-no-tool-for-something-they.md |   4 +-
 ...know-when-a-time-machine-will-transport.md |   4 +-
 ...-about-gatekeeping-and-feeling-superior.md |   4 +-
 ...a-ctags-and-cscope-if-you-know-you-know.md |   4 +-
 ...ould-waste-time-do-things-in-more-error.md |   4 +-
 ..._devesh-legends-use-nano-or-vim-as-well.md |   4 +-
 .../2024-05-04-real7a-thread.md               |   4 +-
 ...codeblocks-instead-of-visual-studio-for.md |   4 +-
 ...a-lot-of-professionals-who-cant-code-at.md |   4 +-
 ...-be-able-to-program-on-paper-thats-what.md |   4 +-
 ...high-school-memories-where-we-all-wrote.md |   4 +-
 ...uldnt-be-able-to-do-your-job-without-an.md |   4 +-
 ...t-could-be-a-good-idea-to-start-without.md |   4 +-
 ...its-about-leveraging-the-tools-to-be-as.md |   4 +-
 .../index.md                                  |  26 +--
 .../index.md                                  |   4 +-
 ...-this-is-a-super-important-question-imo.md | 134 ++++++-------
 .../index.md                                  |   6 +-
 ...tips-or-existing-solutions-on-achieving.md |  52 ++---
 .../index.md                                  |  16 +-
 ...ause-based-arch-was-interesting-in-many.md |  24 +--
 .../index.md                                  |   6 +-
 .../index.md                                  |   4 +-
 .../2025-11-20-no-tokens-and-no-asts/index.md |   2 +-
 ...l-crime-is-those-idiots-not-knowing-who.md |   4 +-
 ...t-do-you-mean-by-arguments-to-recursion.md |   4 +-
 ...ng-to-read-all-that-im-happy-for-you-or.md |   4 +-
 ...lemente-hizo-de-placa-base-pitando-para.md |   4 +-
 ...-is-an-s-tier-post-1-it-proves-non-slop.md |   4 +-
 ...u-i-understood-5-but-i-still-enjoyed-it.md |   4 +-
 .../2026-07-04-EttoreMariotti-thanks.md       |   4 +-
 ...ak-simply-into-a-mixed-space-where-most.md |   2 +-
 ...great-post-i-cant-pretend-that-i-really.md |   4 +-
 ...ought-you-had-ai-psychosis-but-the-fact.md |   4 +-
 ...-got-interested-in-bend-for-its-prosaic.md |   4 +-
 ...yed-reading-this-post-i-think-that-what.md |   4 +-
 ..._-i-once-implemented-a-type-checker-for.md |   4 +-
 ...026-07-04-LusciousPear-i-love-this-shit.md |   4 +-
 ...nely-sometimes-eh-im-excited-about-your.md |   4 +-
 ...-acham-que-s-eles-s-o-superinteligentes.md |   4 +-
 ...nators-dont-have-valid-types-so-you-are.md |  16 +-
 ...ibility-to-write-fast-interpreter-looks.md |   4 +-
 ...pproach-for-this-is-very-elegant-indeed.md |   4 +-
 ...-prefer-the-previous-angry-rhetoric-pls.md |   8 +-
 ...not-very-technical-did-you-mean-ai-good.md |   4 +-
 ...y-ones-always-get-attention-on-internet.md |   4 +-
 ...t-them-get-you-down-they-can-barely-see.md |   4 +-
 ...sting-and-ill-keep-reading-or-trying-to.md |   4 +-
 ...s-an-emergent-ai-psychosis-psychosis-in.md |   4 +-
 ...hink-this-is-a-super-legible-digestible.md |   4 +-
 ...nt-really-comprehend-what-bend2-will-be.md |   4 +-
 ...dont-hafta-grug-post-to-be-popular-with.md |   4 +-
 ...-ai-advances-the-more-we-need-very-high.md |   4 +-
 ...following-you-when-i-scrolled-across-an.md |   4 +-
 ...-mt-bem-escrito-ficou-bem-mais-f-cil-de.md |   4 +-
 ...s-the-problem-isnt-explaining-something.md |   4 +-
 ...07-04-altansukhbatbay-high-quality-post.md |   4 +-
 ...ig-fan-of-interaction-combinators-and-i.md |   4 +-
 ...his-is-so-cool-and-inspiring-not-that-i.md |   4 +-
 ...r-esse-post-timo-poder-ler-de-voc-essas.md |   4 +-
 ...not-study-lambda-calculus-in-college-or.md |   4 +-
 ...-have-no-idea-what-theyre-talking-about.md |   4 +-
 ...e-a-system-that-provably-must-terminate.md |   4 +-
 ...-good-example-this-is-happening-to-both.md |   4 +-
 ...4-fecklesstit-u-the-best-man-keep-it-up.md |   4 +-
 ...-a-very-naive-and-ignorant-question-but.md |   4 +-
 ...ue-brother-we-smart-people-are-alone-no.md |   4 +-
 ...stion-does-bend-have-an-unscoped-lambda.md |   4 +-
 ...-been-following-you-since-the-beginning.md |   4 +-
 ...e-up-was-really-well-done-thank-you-for.md |   4 +-
 ...-you-cant-understand-my-posts-of-course.md |   4 +-
 ...ot-allowed-to-praise-fable-you-must-bag.md |   2 +-
 ...-cases-https-x-com-misterclayt0n-status.md |   4 +-
 ...s-long-post-version-of-yours-you-should.md |   4 +-
 ...e-the-issue-was-in-duplication-inside-0.md |   4 +-
 ...-you-allow-for-non-termination-on-total.md |  20 +-
 ...ous-what-comes-after-bend2-bend3-or-are.md |  16 +-
 ...ske-gpt-for-translating-your-hieroglyph.md |   4 +-
 ...ove-what-ur-doing-keep-going-one-of-the.md |   4 +-
 ...l-indeed-hard-but-important-to-pick-the.md |   4 +-
 .../2026-07-04-taxilogiker-russel-antinomy.md |   4 +-
 ...aid-he-had-ai-psychosis-for-a-while-and.md |   4 +-
 ...impressive-best-argument-on-the-quality.md |   4 +-
 ...w-many-likes-you-get-its-likes-from-who.md |   8 +-
 ...language-im-trying-to-do-termination-by.md |   4 +-
 .../2026-07-05-IanCSU-sure-i-read-all-that.md |   4 +-
 ...-07-05-JaredC1728-quality-over-quantity.md |   4 +-
 ...gree-on-the-consistency-is-enough-to-do.md |   4 +-
 ...y-to-read-and-i-think-i-understood-most.md |   4 +-
 ...26-07-05-Orbiter777-fable-is-educated-c.md |   4 +-
 ...-the-antidote-i-found-to-ai-psychosis-i.md |   4 +-
 ...re-languages-built-on-bend-incapable-of.md |   4 +-
 ...d-ur-rant-these-types-of-posts-deserves.md |   4 +-
 .../2026-07-05-SteveMoraco-legend.md          |   4 +-
 ...reading-all-that-but-damn-hope-it-works.md |   4 +-
 ...stion-alert-in-bends-syntax-what-is-the.md |   4 +-
 ...s-like-the-precise-symbolic-analogue-of.md |   4 +-
 ...pect-id-read-all-of-this-but-i-did-cant.md |   4 +-
 ...omeone-who-doesnt-understand-the-actual.md |   4 +-
 ...o-market-yourself-youre-not-running-for.md |   4 +-
 ...-it-a-great-shot-thanks-for-an-engaging.md |   4 +-
 ...p-posting-like-you-do-one-day-well-have.md |   4 +-
 ...-want-to-be-able-to-copy-lambdas-though.md |   4 +-
 ...t-is-not-a-rebuttal-to-a-query-about-ai.md |   4 +-
 ...-entire-math-proofs-section-in-my-maths.md |   4 +-
 ...-SGuergachi-hopefully-useful-data-point.md |   4 +-
 .../VictorTaelin/2026-07-04-sighs/index.md    |   2 +-
 ...ers-to-op-install-a-plugin-on-top-of-vs.md |   4 +-
 ...ant-even-ctrl-a-after-some-update-a-few.md |   4 +-
 ...ough-when-you-write-oop-language-design.md |   4 +-
 ...mention-how-modern-software-shamelessly.md |   4 +-
 ...-today-in-vs-2022-the-semantic-analyzer.md |   4 +-
 ...s-the-best-metaphor-not-ironically-also.md |   4 +-
 ...h-is-to-write-code-that-i-can-come-back.md |   4 +-
 ...wtn-vs2022-on-mac-is-virtually-unusable.md |   4 +-
 ...performance-is-a-feature-change-my-mind.md |   4 +-
 ...ly-consider-clean-code-to-mean-that-the.md |   4 +-
 ...ill-end-up-going-the-way-of-all-editors.md |   4 +-
 ...ve-both-vs2022-and-vs2019-on-my-machine.md |   4 +-
 ...velopers-had-no-reason-to-uograde-their.md |   4 +-
 ...code-automatically-mean-more-code-paths.md |   4 +-
 ...good-reason-to-use-vs-instead-of-vscode.md |   8 +-
 ...speaking-thats-a-good-principle-but-its.md |   4 +-
 ...letely-another-aspect-is-the-importance.md |   4 +-
 ...never-had-that-problem-with-that-waaaay.md |   4 +-
 ...nd-false-depends-on-the-project-and-the.md |   4 +-
 ...re-is-difficult-and-most-people-have-no.md |   4 +-
 .../index.md                                  |   6 +-
 ...-25-abductee_org-asimov-vibes-intensify.md |   4 +-
 ...-any-thoughts-on-how-agi-could-help-the.md |   4 +-
 ...was-curious-about-what-it-would-take-to.md |  20 +-
 ...-is-actually-a-fantastic-project-though.md |   4 +-
 ...e-have-too-much-time-for-hobby-projects.md |  52 ++---
 ...-the-context-hilarious-but-forth-as-asm.md |   8 +-
 ...t-if-were-in-an-apocalypse-part-is-very.md |   8 +-
 .../index.md                                  |  18 +-
 .../index.md                                  |  14 +-
 ...ebrim-the-answer-exists-its-called-ispc.md |   4 +-
 ...struction-sets-if-we-have-op-a-and-op-b.md |   4 +-
 .../2025-07-15-DanielJCollier-ispc.md         |   4 +-
 ...-has-simd-aware-data-types-and-makes-it.md |   4 +-
 ...-gamedev-head-just-wants-a-sort-of-game.md |  18 +-
 ...hope-that-this-is-true-but-damn-have-we.md |   4 +-
 ...15-JebsSteve0x1-ffmpeg-thinks-otherwise.md |   4 +-
 ...-ever-studied-apl-it-has-the-best-array.md |   4 +-
 ...ems-to-be-pretty-widespread-so-it-might.md |   4 +-
 ...zzSaw-c-makes-it-fairly-straightforward.md |   4 +-
 .../2025-07-15-VPCOMPRESSB-intels-ispc.md     |   4 +-
 ...into-gcc-whos-only-job-is-making-things.md |   4 +-
 ...mething-like-ispc-how-we-author-shaders.md |   4 +-
 ...al-model-columnar-data-sql-lands-itself.md |   4 +-
 ...-that-have-comptime-also-have-wonderful.md |   4 +-
 ...lled-array-programming-fortran-has-been.md |   4 +-
 ...-futhark-or-array-programming-theres-an.md |   4 +-
 ...try-https-github-com-higherorderco-bend.md |  12 +-
 ...-been-stabilized-yet-but-rusts-portable.md |   4 +-
 .../2025-07-15-dezren39-more-arrays.md        |   4 +-
 ...oes-good-enough-job-with-compiler-flags.md |   4 +-
 ...spc-more-or-less-solved-this-and-in-a-c.md |   4 +-
 ...e-an-oversimplification-but-i-think-the.md |   4 +-
 .../2025-07-15-examachine-possible.md         |   4 +-
 .../2025-07-15-groby-so-fortran.md            |   4 +-
 ...dustry-is-trying-to-do-that-with-vector.md |   4 +-
 .../2025-07-15-jshurmer-i-agree.md            |   4 +-
 ...e-programmer-you-mentioned-uses-oop-and.md |   4 +-
 ...-first-class-simd-support-afaik-but-ive.md |   4 +-
 ...gree-there-is-something-weird-with-simd.md |   4 +-
 ...-we-need-a-system-visualizer-where-devs.md |   4 +-
 ...-spent-time-writing-simd-algorithms-for.md |  24 +--
 ...slendidev-have-you-looked-at-odins-simd.md |   8 +-
 ...ek_UK-whats-wrong-with-using-inline-asm.md |   4 +-
 ...le-arithmetic-operations-on-fixed-sized.md |   4 +-
 ...ase-have-you-met-the-average-programmer.md |   4 +-
 .../2025-07-15-theogcb405-thread.md           |   4 +-
 ...ped-into-my-head-is-languages-like-uiua.md |   4 +-
 ...-really-that-hard-to-use-though-or-what.md |   4 +-
 ...eel-most-of-the-pl-design-community-who.md |  24 +--
 ...en-wondering-about-this-for-over-twenty.md |   4 +-
 ...tly-it-will-definitely-be-a-random-idea.md |   4 +-
 .../index.md                                  |   6 +-
 ...08-03-BurnZeZ-i-do-and-access-it-via-9p.md |   4 +-
 ...Molehill-brb-adding-this-to-my-codebase.md |   4 +-
 ...an-also-implicitly-pass-the-source-code.md |   4 +-
 .../2026-08-03-MikeyBally-this-is-the-way.md  |   4 +-
 ...ppose-you-could-demonstrate-this-with-a.md |   4 +-
 ...this-just-a-python-style-docstring-with.md |   4 +-
 ...rn-microsoft-com-en-us-windows-hardware.md |   4 +-
 ...an-you-post-an-example-of-how-you-would.md |   4 +-
 ...sokol-gfx-does-this-its-really-nice-ive.md |   4 +-
 ...e-seen-this-they-usually-require-unique.md |   4 +-
 ...ts-actually-a-smart-idea-do-you-have-an.md |   8 +-
 ...agging-allocations-and-frames-to-actual.md |   4 +-
 ...dentally-discovered-this-myself-it-just.md |   4 +-
 ...on-draw-string-for-debug-in-my-games-3d.md |   4 +-
 ...this-and-its-a-life-saver-for-debugging.md |   4 +-
 ...s-just-saved-me-from-hours-of-debugging.md |   4 +-
 .../index.md                                  |   4 +-
 ...owck_novel-thanks-a-lot-for-the-example.md |   4 +-
 ...o-the-habit-of-immediately-writing-free.md |   4 +-
 ...tgame-ah-matching-strings-just-like-xml.md |   4 +-
 ...9499-deferloop-is-super-useful-for-this.md |   4 +-
 ...cular-case-though-is-easily-solved-with.md |  16 +-
 ...rything-about-this-and-i-agree-its-fine.md |   2 +-
 ...eat-tip-i-always-used-comments-but-this.md |   4 +-
 ...uld-use-c-with-raii-and-not-have-to-tie.md |   4 +-
 ...this-example-illustates-pretty-good-why.md |   4 +-
 ...nership-raii-makes-such-patterns-really.md |   2 +-
 .../index.md                                  |   6 +-
 .../index.md                                  |   2 +-
 .../2024-12-18-SubstrataVr-example.md         |   4 +-
 .../2024-12-18-TriggerCoder-unroll.md         |   4 +-
 ...point-do-you-think-you-should-convert-a.md |  26 +--
 ...-already-wrote-this-somewhere-but-id-be.md |   8 +-
 ...24-12-18-pr0meteu5-any-concrete-example.md |  14 +-
 ...minds-me-of-games-and-simulations-where.md |   4 +-
 ...ompletely-agree-i-am-interested-in-your.md |   8 +-
 ...ting-projection-of-combinatorics-system.md |   4 +-
 ...for-this-thread-read-it-a-while-ago-but.md |   8 +-
 .../index.md                                  |  16 +-
 ...y-muratori-video-about-people-who-think.md |  20 +-
 ...s-exactly-zero-pain-in-debugging-unique.md |   4 +-
 ...i-miss-the-point-you-are-trying-to-make.md |   4 +-
 ...isnt-such-a-strong-argument-considering.md |   4 +-
 ...ords-but-unique-ptr-is-really-zero-cost.md |  28 +--
 ...ted-assembly-or-other-supposedly-better.md |   4 +-
 ...td-comitee-wrote-thousands-of-lines-for.md |   4 +-
 ...-more-if-attribute-cleanup-was-standard.md |   4 +-
 ...nce-has-been-different-every-piece-of-c.md |  14 +-
 ...ple-will-say-this-garbage-and-then-show.md |   4 +-
 ...-malloc-free-is-a-common-c-practice-and.md |  30 +--
 ...ny-large-codebase-and-youll-see-a-bunch.md |   8 +-
 ...endidev-do-you-have-any-example-of-this.md |  44 ++--
 ...-zero-overhead-in-the-abstract-isnt-the.md |   4 +-
 .../index.md                                  |  26 +--
 ...ike-using-lambdas-or-local-functions-to.md |   4 +-
 ...a-similar-problem-comes-when-you-follow.md |   4 +-
 ...mpletely-agree-adding-a-helper-function.md |   4 +-
 ...te-helper-functions-especially-the-ones.md |   4 +-
 ...to-refer-to-declarative-as-just-fucking.md |   4 +-
 ...ve-been-compressing-in-terms-of-section.md |   4 +-
 ...d-focusing-on-the-data-you-work-and-how.md |   4 +-
 ...ten-inline-every-helper-function-i-find.md |   4 +-
 ...mate18-entry-point-you-mean-indirection.md |   4 +-
 ...norg-fewer-entry-points-fewer-surprises.md |   4 +-
 ...exactly-sure-what-do-you-mean-with-this.md |   4 +-
 ...e-giant-matching-functions-with-lots-of.md |   6 +-
 ...o-compress-is-dsl-vv-everything-else-is.md |   4 +-
 ...dry-can-be-extremely-overdone-llms-love.md |   4 +-
 ...ave-an-example-or-a-before-and-after-by.md |   4 +-
 ...said-it-would-be-useful-to-see-examples.md |   4 +-
 ...model-for-this-are-you-putting-the-mess.md |   4 +-
 ...on-explicitly-limits-the-variables-that.md |  10 +-
 ...is-as-it-maps-the-problem-with-input-on.md |   4 +-
 ...does-this-imply-if-you-took-an-external.md |   4 +-
 ...tell-just-how-many-times-ive-pulled-out.md |   4 +-
 ...ess-kind-of-working-fine-but-dirty-with.md |   4 +-
 .../2026-06-02-sipubot-db.md                  |   4 +-
 ...ught-of-helper-f-ns-as-code-compression.md |   4 +-
 ...what-about-polymorphism-and-inheritance.md |  32 +--
 ...ill-love-to-read-a-long-article-on-this.md |   4 +-
 ...are-an-open-source-project-that-follows.md |   8 +-
 ...gger-is-easy-to-read-for-such-a-complex.md |   4 +-
 ...remdak-i-like-a-big-ass-on-my-functions.md |   4 +-
 ...teresting-i-was-just-reviewing-code-and.md |   4 +-
 ...ou-have-a-code-example-of-how-you-would.md |   4 +-
 .../index.md                                  |   4 +-
 ...-a-concrete-example-of-this-it-might-be.md |   4 +-
 ...e-noticed-that-inlining-is-just-amazing.md |   4 +-
 ...g-o3-if-you-compare-the-assembly-output.md |  12 +-
 ...-have-a-favorite-example-from-raddbg-to.md |   4 +-
 ...seems-like-such-good-advice-and-hard-to.md |   6 +-
 ...-first-thing-i-do-in-every-big-refactor.md |   4 +-
 ...w-this-sounds-like-a-nice-feature-for-a.md |   4 +-
 .../2026-08-07-tralamazza-couldnt-resist.md   |   4 +-
 ...-this-process-to-linearise-the-mutually.md |   4 +-
 ...rmack-wrote-about-this-http-number-none.md |   4 +-
 ...e-will-say-that-a-good-abstraction-lets.md |   4 +-
 ...ndamental-property-of-abstraction-is-to.md |   4 +-
 ...wonder-why-we-dont-have-a-tool-do-we-to.md |   4 +-
 .../index.md                                  |   6 +-
 .../index.md                                  |  26 +--
 ...is-how-much-overhead-of-course-even-not.md |  12 +-
 .../index.md                                  |  34 ++--
 ...-common-problem-thin-wrapper-interfaces.md |  76 +++----
 ...fly-discussed-this-topic-in-my-siggraph.md |  24 +--
 ...e-i-abstract-at-a-higher-level-i-end-up.md |   4 +-
 ...-whatever-you-want-the-api-just-because.md |   4 +-
 ...t-disagree-but-the-reason-is-that-99-of.md |   4 +-
 ...-the-key-benefit-is-two-fold-making-the.md |   2 +-
 ...r-pipeline-is-basically-a-full-piece-of.md |   4 +-
 ...xactly-that-my-abstraction-is-basically.md |   4 +-
 .../index.md                                  |   6 +-
 ...is-is-not-timothy-lottes-then-who-is-it.md |   4 +-
 ...e-goes-a-bit-beyond-that-judging-by-the.md |   8 +-
 .../index.md                                  |   4 +-
 ...ldnt-this-make-working-with-arrays-more.md |  12 +-
 ...nfusing-if-you-arent-used-to-it-that-is.md |   2 +-
 ...er-arithmetic-based-on-type-sizes-makes.md |   8 +-
 ...l-im-parsing-through-a-binary-array-and.md |   4 +-
 ...the-displeasure-of-being-exposed-to-hex.md |   4 +-
 ...tingly-if-you-try-to-write-rust-in-this.md |   4 +-
 .../index.md                                  |  14 +-
 ...hen-you-combine-this-with-all-the-other.md |   8 +-
 .../2024-01-23-MrJayLC-neat.md                |   4 +-
 .../2024-01-23-alurmanc-i-love-this.md        |   4 +-
 ...it-be-transformarguments-parameters-are.md |   4 +-
 ...es-default-work-do-variable-args-bypass.md |   4 +-
 ...-designated-initializers-is-one-thing-i.md |   4 +-
 ...problem-here-is-that-you-cannot-do-this.md |   8 +-
 .../2025-08-13-JLakness-c-functor-method.md   |   4 +-
 ...amenko-this-one-is-amazing-to-be-honest.md |   4 +-
 ...tten-to-this-place-i-gotta-keep-pushing.md |   4 +-
 ...soo-good-i-did-it-in-typescript-as-well.md |   4 +-
 ...ool-but-this-doesnt-mean-c-is-a-good-or.md |   4 +-
 ...nly-one-who-thinks-this-is-terrible-its.md |  48 ++---
 ...-dont-know-what-i-am-looking-at-anymore.md |   4 +-
 .../2025-08-14-emh203-bravo.md                |   4 +-
 ...2025-08-14-etozheya42-lets-go-10k-likes.md |   4 +-
 ...ed_state-instantly-rewriting-everything.md |   4 +-
 ...025-08-14-siddhantCodes-this-is-so-cool.md |   4 +-
 ...just-one-like-but-together-we-build-the.md |   4 +-
 .../2025-12-29-CarloIlCugino-thank-you.md     |   4 +-
 .../index.md                                  |   6 +-
 .../winning_tactic/2026-06-07-i-see/index.md  |   4 +-
 notes/How threads are organized.md            |   6 +
 publish/quartz-patches/apply.py               |   7 +
 publish/quartz.custom.scss                    |  55 ++++-
 publish/setup.ps1                             |   5 +
 publish/threadwell-reader.js                  |  86 ++++++++
 scripts/twitter/emit_archive.py               |  23 ++-
 scripts/twitter/render.py                     |  28 ++-
 .../twitter/tests/test_reply_attribution.py   |  56 ++++--
 728 files changed, 3291 insertions(+), 3087 deletions(-)
 create mode 100644 publish/threadwell-reader.js

diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
index 6eb3b32..c27c07d 100644
--- a/.github/workflows/deploy.yml
+++ b/.github/workflows/deploy.yml
@@ -36,6 +36,8 @@ jobs:
         run: |
           cp publish/quartz.config.yaml site/quartz.config.yaml
           cp publish/quartz.custom.scss site/quartz/styles/custom.scss
+          mkdir -p site/quartz/static
+          cp publish/threadwell-reader.js site/quartz/static/threadwell-reader.js
       - uses: actions/setup-node@v6
         with:
           node-version: 24
diff --git a/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-NOTimothyLottes-3-if-you-had-multiple-line-stores-collecting-on-a.md b/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-NOTimothyLottes-3-if-you-had-multiple-line-stores-collecting-on-a.md
index 2a0f304..b71beb7 100644
--- a/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-NOTimothyLottes-3-if-you-had-multiple-line-stores-collecting-on-a.md
+++ b/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-NOTimothyLottes-3-if-you-had-multiple-line-stores-collecting-on-a.md
@@ -26,291 +26,291 @@ parent_post_id: "1869436199884222515"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1869436525869724013
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 (3.) If you had multiple line stores collecting on a given line with ECC, you'd have the same bottleneck as fire-and-forget atomics. A throughput of one line modification per clock.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1869436940334014771
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 (4.) Note the prior assumes a read hit! 
 
 So at the point you get anti-atomic, you are also anti-store and anti-ECC, and anti-etc. It's the same pipelines with the same variability due to on-chip networking, different clock domain crossing, etc.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1869437450399170852
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 (5.) Good GPUs have multiple ALUs doing the atomic by the last level cache. So it scales very well as a function of line collisions. Meaning if all lanes access separate addresses on a cacheline, those go in parallel.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1869437815936979150
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 (6.) Atomics and regular stores have the same memory controller base-camping behavior. If all SIMDs store to addresses that hash to the same last level cache partition, they will drop efficiency just like doing all atomics to the same address.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1869438257983062074
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 (7.) Anyway, while CPU atomics are serious design fail, GPU atomics on good GPUs are your best friend. They are actually a fantastic tool for getting more regular performance in many parallel algorithms.
 
-**6/** @SebAaltonen
+**6/** **@SebAaltonen** ^1869438915679338644
 
-@NOTimothyLottes @AgileJebrim @munohikari
+**@NOTimothyLottes** **@AgileJebrim** **@munohikari**
 
 Indeed. Many CPU programmers have the wrong belief that GPU atomics are slow and unusable. They are fantastic. Bump allocator is your best friend on CPU side. On GPU you do atomic add to implement a bump allocator. As simple as that. It's super fast.
 
-**7/** @AgileJebrim
+**7/** **@AgileJebrim** ^1869455007025946954
 
-@SebAaltonen @NOTimothyLottes @munohikari
+**@SebAaltonen** **@NOTimothyLottes** **@munohikari**
 
 I know NVIDIA did a really good atomicAdd, especially if you don’t use the result of the atomicAdd(). If you use it, then it forces it down a significantly slower path. But it’s all implementation-specific and different vendors will do different things yes?
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1869461633267032141
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 Atomics come in two forms
 (1.) fire-and-forget (aka you don't use the return) - the compiler will flag it for no-return, so it behaves like a store
 (2.) read the return - it behaves like a {store, and read} simultaneously with layout "coherent"
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1869462116689981465
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 Good GPUs have address coalescing on writes and atomics. So a wave wide store is reduced to a cost that scales with the number of total cachelines all waves touch, with byte-write-mask so there is no read-modify-write
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1869462778270085478
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 ... atomics have the same but if any wave lane's addresses collide it will bump those to another request (for the same cacheline). Possible that some HW implements a HW reduction for collisions of some kinds of atomics locally before the requests go out, but don't assume that
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1869463101361504275
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 ... it's more likely that some compilers try to fix stupid behavior by doing a wave-reduction in software, and that causes hell for those of us who already write good code
 
-**12/** @AgileJebrim
+**12/** **@AgileJebrim** ^1869463390944629143
 
-@NOTimothyLottes @SebAaltonen @munohikari
+**@NOTimothyLottes** **@SebAaltonen** **@munohikari**
 
 Thoughts on atomic compare exchange? I use similar functionality on CPUs to globally synchronize threads and I figured I’d give it a shot attempting to do that on GPUs.
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1869464512191238438
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 Compare and exchange since it takes 2 values, it could have half the peak rate through on-chip network. Personally I have always used algorithms that do better things without the cmpswap atomic. You always can get the return (value pre-atomic), so cmpswap utility is less
 
-**14/** @AgileJebrim
+**14/** **@AgileJebrim** ^1869465848211230840
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 My CPU sync mechanism works by stalling each thread until it reaches a multiple of the total number of threads to be synced, only incrementing an integer (swapping) when it reaches its specific thread index.
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1869467172495655049
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 I assume you are using a futex then on Linux to block? But the GPU doesn't have such a thing exposed in software. Instead you'd be effectively polling using serial global memory atomic latency as your rate limiter and 'blocking'
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1869467614407541225
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 Serializing workgroups on the GPU in this way has a very high latency granularity. There is also the issue of preemption on PCs, there is no guarantee of forward progress due to no guarantee all workgroups get restored
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1869467785010762160
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 So you can deadlock post preemption if the workgroup that needs to do the atomic to unblock those spinning cannot get back on the machine
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1869468049176506634
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 Now, the important part, there is one compromise rule that has the highest chance of being possible, that is an ask that if there is a partial restore, that it restores the oldest launched workgroups first ...
 
-**19/** @NOTimothyLottes
+**19/** **@NOTimothyLottes** ^1869468322003317098
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 And with that you can have some forward progress if an algorithm only has dependencies on workgroups launched before it (like lower kernel global workgroup index), food for thought for algorithm design
 
-**20/** @NOTimothyLottes
+**20/** **@NOTimothyLottes** ^1869469045357158663
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 on the CPU side, you'd futex block to get the thread off being scheduled so the dependent one could get on the machine to avoid deadlock, it isn't efficient by any means but works, the GPU's exposed only voluntary method to get off the machine is to exit the workgroup ...
 
-**21/** @NOTimothyLottes
+**21/** **@NOTimothyLottes** ^1869469471892795511
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 So if you uber-task, meaning just keep launching the same dispatch, and the workgroup finds what it needs to do (instead of working off kernel global index), then you can workaround preemption that way too ...
 
-**22/** @NOTimothyLottes
+**22/** **@NOTimothyLottes** ^1869469740726734946
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 Blocking becomes just workgroup exit. And the next workgroup gets lower schedule priority than existing active workgroups which helps solve of the scheduling issues
 
-**23/** @AgileJebrim
+**23/** **@AgileJebrim** ^1869470170613461399
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 I’m not using a Linux futex. Could you look over my code here?
 
-**24/** @simplex_fx
+**24/** **@simplex_fx** ^1869471291973214394
 
-@AgileJebrim @NOTimothyLottes @SebAaltonen
+**@AgileJebrim** **@NOTimothyLottes** **@SebAaltonen**
 
 Hey Jeb, have you considered hitting the funny L shaped button on the right of your keyboard more frequently? 😅
 
-**25/** @AgileJebrim
+**25/** **@AgileJebrim** ^1869472284156834117
 
-@simplex_fx @NOTimothyLottes @SebAaltonen
+**@simplex_fx** **@NOTimothyLottes** **@SebAaltonen**
 
 Enter? Nah
 
-**26/** @simplex_fx
+**26/** **@simplex_fx** ^1869474818384670790
 
-@AgileJebrim @NOTimothyLottes @SebAaltonen
+**@AgileJebrim** **@NOTimothyLottes** **@SebAaltonen**
 
 ![](https://pbs.twimg.com/media/GfG1cCJW8AAXcDg?format=jpg&name=orig)
 
-**27/** @AgileJebrim
+**27/** **@AgileJebrim** ^1869479130993234191
 
-@simplex_fx @NOTimothyLottes @SebAaltonen
+**@simplex_fx** **@NOTimothyLottes** **@SebAaltonen**
 
 If I don’t have to scroll right…
 
-**28/** @simplex_fx
+**28/** **@simplex_fx** ^1869486350074020173
 
-@AgileJebrim @NOTimothyLottes @SebAaltonen
+**@AgileJebrim** **@NOTimothyLottes** **@SebAaltonen**
 
 Dude, stop with that WQHD bullshit, buy a proper tv and limit yourself to 80-120
 
-**29/** @AgileJebrim
+**29/** **@AgileJebrim** ^1869486638877004115
 
-@simplex_fx @NOTimothyLottes @SebAaltonen
+**@simplex_fx** **@NOTimothyLottes** **@SebAaltonen**
 
 Nty. The hell do I need a tv for? I have several monitors.
 
-**30/** @simplex_fx
+**30/** **@simplex_fx** ^1869486998249185767
 
-@AgileJebrim @NOTimothyLottes @SebAaltonen
+**@AgileJebrim** **@NOTimothyLottes** **@SebAaltonen**
 
 How big?
 
-**31/** @AgileJebrim
+**31/** **@AgileJebrim** ^1869487741052023113
 
-@simplex_fx @NOTimothyLottes @SebAaltonen
+**@simplex_fx** **@NOTimothyLottes** **@SebAaltonen**
 
 Big enough to maximize a window on each.
 
-**32/** @simplex_fx
+**32/** **@simplex_fx** ^1869518005237112922
 
-@AgileJebrim @NOTimothyLottes @SebAaltonen
+**@AgileJebrim** **@NOTimothyLottes** **@SebAaltonen**
 
 If you go too wide, you will just kill your neck on the long run
 
-**33/** @AgileJebrim
+**33/** **@AgileJebrim** ^1869523900687864185
 
-@simplex_fx @NOTimothyLottes @SebAaltonen
+**@simplex_fx** **@NOTimothyLottes** **@SebAaltonen**
 
 I have 4 monitors
 
-**34/** @simplex_fx
+**34/** **@simplex_fx** ^1869529828082541035
 
-@AgileJebrim @NOTimothyLottes @SebAaltonen
+**@AgileJebrim** **@NOTimothyLottes** **@SebAaltonen**
 
 How big?
 
-**35/** @NOTimothyLottes
+**35/** **@NOTimothyLottes** ^1869530109096669269
 
-@simplex_fx @AgileJebrim @SebAaltonen
+**@simplex_fx** **@AgileJebrim** **@SebAaltonen**
 
 Ideally one of these
 
 ![](https://pbs.twimg.com/media/GfHntpaWYAAGnOk?format=png&name=orig)
 
-**36/** @AgileJebrim
+**36/** **@AgileJebrim** ^1869530951480717429
 
-@NOTimothyLottes @simplex_fx @SebAaltonen
+**@NOTimothyLottes** **@simplex_fx** **@SebAaltonen**
 
 Not big enough. Evans & Sutherland still makes planetariums. We have smaller scale 360 degree domes. I think they’re about 14ft high.
 
-**37/** @SebAaltonen
+**37/** **@SebAaltonen** ^1869808696366379155
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 Same is true for everything. All memory loads on GPUs are highly vendor specific. On GTX 1080 (Pascal) your memory load goes through sampler, which is around 85 cycles of latency. While on Turing your raw load is only 28 cycles of latency (CUDA benchmarks).
 
-**38/** @AgileJebrim
+**38/** **@AgileJebrim** ^1869809446437957837
 
-@SebAaltonen @NOTimothyLottes
+**@SebAaltonen** **@NOTimothyLottes**
 
 For sure, but my focus is more on how deterministic and predictable these are. I’ll take 85 if it’s always 85 over something that might vary unpredictably between 28 and 100.
 
-**39/** @SebAaltonen
+**39/** **@SebAaltonen** ^1869810947512250536
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 Nvidia has big L1$, so they are more predictable. Texture samplers are shared with all waves running on the same compute unit. They are not really predictable. You wait until the unit is ready. There's quite a lot of fluctuation. That's why you have 8x-10x hyperthreading per CU.
 
-**40/** @SebAaltonen
+**40/** **@SebAaltonen** ^1869811242954830281
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 The idea is to keep the SIMD running all the time. Wave execution time variance hasn't been a big optimization goal. There's always more work coming, so it's not a problem if some wave takes 10x time to execute compared to others.
 
-**41/** @SebAaltonen
+**41/** **@SebAaltonen** ^1869811536547721585
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 Basically if the SIMD is executing instructions all the time, then your workload runs at predictable amount of instructions per cycle. The problem is barriers. You wait for longest wave to finish. You can't to batch barriers to avoid turning latency into real lost SIMD cycles.
 
-**42/** @AgileJebrim
+**42/** **@AgileJebrim** ^1869811840433496316
 
-@SebAaltonen @NOTimothyLottes
+**@SebAaltonen** **@NOTimothyLottes**
 
 If they all take the same amount of time then there shouldn’t be much idling of hardware for waiting on the longest wave.
 
-**43/** @SebAaltonen
+**43/** **@SebAaltonen** ^1870002011753578827
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 That's true. But they don't take the same amount of time due to caches. That's where the 10x hyper-threading kicks in. As long as the SIMD is fed all the time, there's no visible issue with fluctuating wave lengths. Barriers make that visible. Minimal amount of barriers = good.
 
-**44/** @AgileJebrim
+**44/** **@AgileJebrim** ^1869454583191494967
 
-@NOTimothyLottes @SebAaltonen @munohikari
+**@NOTimothyLottes** **@SebAaltonen** **@munohikari**
 
 Would you implement a prefix sum compaction algorithm using atomicAdd?
 
-**45/** @NOTimothyLottes
+**45/** **@NOTimothyLottes** ^1869460449194037720
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 Standard optimizations apply, like doing wave-reductions first.
 
-**46/** @AgileJebrim
+**46/** **@AgileJebrim** ^1869460608246239720
 
-@NOTimothyLottes @SebAaltonen @munohikari
+**@NOTimothyLottes** **@SebAaltonen** **@munohikari**
 
 Okay so you don’t just blanket throw an atomicAdd on it then.
 
-**47/** @NOTimothyLottes
+**47/** **@NOTimothyLottes** ^1869463962322149607
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 No. For things like scanning a 1-bit value, it's a wave masked bit count op in software, followed by predicating the atomic to just lane 0 of the wave. For scanning uint32s it's a log2 wave reduction, then predicating the add to lane 0. And so on
 
diff --git a/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-SebAaltonen-yes-but-its-going-to-be-much-slower-you-can-do.md b/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-SebAaltonen-yes-but-its-going-to-be-much-slower-you-can-do.md
index ffd422f..07e3dd3 100644
--- a/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-SebAaltonen-yes-but-its-going-to-be-much-slower-you-can-do.md
+++ b/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-SebAaltonen-yes-but-its-going-to-be-much-slower-you-can-do.md
@@ -26,17 +26,17 @@ parent_post_id: "1869424048607993895"
 
 ## Branch
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1869425726128304359
 
-@AgileJebrim @NOTimothyLottes @munohikari
+**@AgileJebrim** **@NOTimothyLottes** **@munohikari**
 
 Yes, but it's going to be MUCH slower. You can do sums and reductions in groupshared memory, but if that mobile GPU doesn't have real groupshared memory, it's going to be very slow. For example GMEM based groupshared is this slow on Qualcomm (and 730 is much better than 610):
 
 ![](https://pbs.twimg.com/media/GfGISwfWgAI6UuY?format=jpg&name=orig)
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1869426053002997774
 
-@AgileJebrim @NOTimothyLottes @munohikari
+**@AgileJebrim** **@NOTimothyLottes** **@munohikari**
 
 X1 is the brand new laptop chip. This architecture is only on latest mobile phones. Low end is Adreno 610 and similar.
 
diff --git a/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/index.md b/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/index.md
index de3d4c7..3dc3a61 100644
--- a/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/index.md
+++ b/archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/index.md
@@ -25,80 +25,80 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1869397269956673662
 
-@munohikari @SebAaltonen
+**@munohikari** **@SebAaltonen**
 
 You left out the bit where I also said no graphics pipeline. :P
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1869401190653730862
 
-@AgileJebrim @munohikari
+**@AgileJebrim** **@munohikari**
 
 Computer shaders are a can of worms for old mobile GPUs too. Some have fast groupshared memory (could be tiny), some emulate it. Some have wave intrinsics, some don't. 64-bit atomic support is nonexistent (for MM Dreams / Native style Z+payload packing).
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1869401541570179083
 
-@AgileJebrim @munohikari
+**@AgileJebrim** **@munohikari**
 
 Also compute shader writes are not compressed (pixel shader framebuffer writes have HW lossless compressor). You pay full memory bandwidth cost, which causes phone to heat (drain battery) and eventually throttle.
 
-**4/** @AgileJebrim
+**4/** **@AgileJebrim** ^1869402067724615899
 
-@SebAaltonen @munohikari
+**@SebAaltonen** **@munohikari**
 
 Alternative approach is to do all rendering in screen space in a fragment shader.
 
-**5/** @SebAaltonen
+**5/** **@SebAaltonen** ^1869403157530550660
 
-@AgileJebrim @munohikari
+**@AgileJebrim** **@munohikari**
 
 If you intend to do distance field ray-tracing using volume textures, worth noting that most mobile GPUs don't do proper 3d tiling layout for volume textures. Instead they use legacy 2d sliced layout, which results in significantly more L1$ trashing. Can 5x your mem BW use.
 
-**6/** @AgileJebrim
+**6/** **@AgileJebrim** ^1869406913676660898
 
-@SebAaltonen @munohikari
+**@SebAaltonen** **@munohikari**
 
 Raycasting, no bouncing, using cubic textured bricks that emulate voxel surfaces via a parallax occlusion map approach measuring distances to each voxel surface.
 
 If I’m writing something for an avionics cockpit, I’d be either using an Arm Mali-G78AE or NVIDIA DRIVE AGX Thor GPU.
 
-**7/** @AgileJebrim
+**7/** **@AgileJebrim** ^1869408574910423473
 
-@SebAaltonen @munohikari
+**@SebAaltonen** **@munohikari**
 
 I’d also be using Vulkan SC, which I believe disables atomics entirely. :P
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1869423853761614046
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 Disabling atomics is like chopping off both legs because someone thinks one tow has a blister when it actually doesn't.
 
-**9/** @AgileJebrim
+**9/** **@AgileJebrim** ^1869424048607993895
 
-@NOTimothyLottes @SebAaltonen @munohikari
+**@NOTimothyLottes** **@SebAaltonen** **@munohikari**
 
 You can still implement a comparable feature yourself.
 
 Branches: [[archive/threads/AgileJebrim/2024-12-18-you-left-out-the-bit-where-i-also-said-no/2024-12-18-SebAaltonen-yes-but-its-going-to-be-much-slower-you-can-do]]
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1869434807228461111
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 No actually you cannot. No method of software (or even HW) implemented lock-line algorithm survives the kind of latency in the GPU memory system. There is a big reason atomics on GPUs are done right by the last level of cache (the coherent memory domain)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1869435419244527644
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 Something you really need to understand for your own benefit:
 (1.) There are a lot of more expensive things happening in the GPU memory system than atomics. For instance DCC compression. It requires metadata access (to get the state of memory just to do the compression on store).
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1869436199884222515
 
-@AgileJebrim @SebAaltonen @munohikari
+**@AgileJebrim** **@SebAaltonen** **@munohikari**
 
 (2.) Think of GPU atomics as a read-modify-write op. It's effectively the same behavior as a partial cacheline write-through STORE operation on HW using ECC. Because ECC eats the bits used for byte-write-mask.
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-HQuarterma43504-gamemaker-introduced-me-to-the-entity-paradigm.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-HQuarterma43504-gamemaker-introduced-me-to-the-entity-paradigm.md
index f754f76..fc262bc 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-HQuarterma43504-gamemaker-introduced-me-to-the-entity-paradigm.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-HQuarterma43504-gamemaker-introduced-me-to-the-entity-paradigm.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @HQuarterma43504
+**1/** **@HQuarterma43504** ^2036819288124985764
 
-@BOENSAW
+**@BOENSAW**
 
 GameMaker introduced me to the Entity paradigm. Each entity has "events" like On Create, On Destroy, Every Step, On Draw, On Collision, Timer, and so on. And you write code for these events.
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Jonathan_Blow-entities-dont-have-to-go-but-having-a-mental.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Jonathan_Blow-entities-dont-have-to-go-but-having-a-mental.md
index 68cbe8d..9a17a27 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Jonathan_Blow-entities-dont-have-to-go-but-having-a-mental.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Jonathan_Blow-entities-dont-have-to-go-but-having-a-mental.md
@@ -26,15 +26,15 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @Jonathan_Blow
+**1/** **@Jonathan_Blow** ^2036815488173703237
 
-@BOENSAW
+**@BOENSAW**
 
 Entities don’t have to go but having a mental framework where entities run functions is probably not helpful.
 
-**2/** @anicic_filip
+**2/** **@anicic_filip** ^2037079338512769397
 
-@Jonathan_Blow @BOENSAW
+**@Jonathan_Blow** **@BOENSAW**
 
 Could you expand on that? 
 I've seen:
@@ -44,31 +44,31 @@ I've seen:
 
 Is this what you are describing as a mental framework?
 
-**3/** @Jonathan_Blow
+**3/** **@Jonathan_Blow** ^2037294870939972085
 
-@anicic_filip @BOENSAW
+**@anicic_filip** **@BOENSAW**
 
 My game code has evolved toward "iterate over all entities of type X, do Y on them, at the place in the code where this needs to happen". The entity does not own the function, the game engine owns the function.
 
-**4/** @Jonathan_Blow
+**4/** **@Jonathan_Blow** ^2037295493085319580
 
 (So instead of having a generic tick function where you switch on entity type, and then a generic pre-tick because of course you need that, and pre-pre-tick, and post-tick, etc, you just have small bits of code where you iterate over things by type and do what that type needs. If you store the entities by type in the first place (which is a very efficient way to do it due to uniform size), then these iterations are much faster than iterating over randomly-typed entities in random order.
 
-**5/** @Jonathan_Blow
+**5/** **@Jonathan_Blow** ^2037295938583314583
 
-@anicic_filip @BOENSAW
+**@anicic_filip** **@BOENSAW**
 
 A real-world example (but most loops have more in the body; this one is chosen for readability):
 
 ![](https://pbs.twimg.com/media/HEXt2j_bUAAxPLa?format=png&name=orig)
 
-**6/** @Jonathan_Blow
+**6/** **@Jonathan_Blow** ^2037296285506822315
 
-@anicic_filip @BOENSAW
+**@anicic_filip** **@BOENSAW**
 
 The idea of a generic tick function for entities is really not great to begin with, because in a complex game you end up caring a great deal about what order things happen in, then you need to go to great pain to impose this order. Instead, you can just say "do A, then B, ..."
 
-**7/** @iquilezles
+**7/** **@iquilezles** ^2037321785008668834
 
 Once I saw a project where everything was entities with a .tick(), plus a gigantic priority table intended to orchestrate the mess. Because reasoning the flow was still too hard, developers had added yield() for_rand_number_of_frames everywhere, "to give other entities some time to run their tick()s". Naturally all actions took multiple frames to execute, and they still had flow/synch bugs everywhere anyways.
 
@@ -76,15 +76,15 @@ I advised them to burn thing down and move on to just an app loop with { do_thin
 
 You could say the problem was that particular team of coders, not the design per-se. But, I mean, I've seen this story repeat with different teams repeat 3 or 4 times by now...
 
-**8/** @Jonathan_Blow
+**8/** **@Jonathan_Blow** ^2037322309502185845
 
-@iquilezles @anicic_filip @BOENSAW
+**@iquilezles** **@anicic_filip** **@BOENSAW**
 
 Everyone wants to think they are in the Matrix and doing some super cool entity simulation reality engine. In reality it is just clumsy code failing to do something simple, at great cost in complexity, speed and reliability.
 
-**9/** @BOENSAW
+**9/** **@BOENSAW** ^2037340571690471473
 
-@Jonathan_Blow @iquilezles @anicic_filip
+**@Jonathan_Blow** **@iquilezles** **@anicic_filip**
 
 I think part of the appeal is also hiding code so that it appears simpler because you can't see all of it at once. not that that's good, lol
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-KnightOfTh3Wind-how-do-you-even-have-a-functioning-game-without.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-KnightOfTh3Wind-how-do-you-even-have-a-functioning-game-without.md
index 19a11dc..79debbd 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-KnightOfTh3Wind-how-do-you-even-have-a-functioning-game-without.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-KnightOfTh3Wind-how-do-you-even-have-a-functioning-game-without.md
@@ -26,33 +26,33 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @KnightOfTh3Wind
+**1/** **@KnightOfTh3Wind** ^2036777757875581351
 
-@BOENSAW
+**@BOENSAW**
 
 How do you even have a functioning game without entities
 
-**2/** @BOENSAW
+**2/** **@BOENSAW** ^2036779389757894720
 
-@KnightOfTh3Wind
+**@KnightOfTh3Wind**
 
 I'm just guessing, but over time I've realized less and less things actually need to be compartmentalized into boxes and can just be managed as a part of global state
 
-**3/** @SagelessRanger
+**3/** **@SagelessRanger** ^2036781762752205009
 
-@BOENSAW @KnightOfTh3Wind
+**@BOENSAW** **@KnightOfTh3Wind**
 
 Can you make this expand on this idea this sounds very interesting and potentially more clear to manage
 
-**4/** @BOENSAW
+**4/** **@BOENSAW** ^2036786837029863443
 
-@SagelessRanger @KnightOfTh3Wind
+**@SagelessRanger** **@KnightOfTh3Wind**
 
 Take a cutscene for a simple example. A naive approach might be something like "npc object spawns a textbox object and sends text from its text variable". Doesn't sound so bad but what if two NPCs activate at once, what if the textbox or npc gets destroyed somehow... error prone
 
-**5/** @BOENSAW
+**5/** **@BOENSAW** ^2036787552238342282
 
-@SagelessRanger @KnightOfTh3Wind
+**@SagelessRanger** **@KnightOfTh3Wind**
 
 Something more along this line of thinking would be like "interaction system detects conditions to begin the cutscene state which reads from a script and draws textboxes automatically". less interdependence, no reliance on external objects, no way to muddy the state
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MelinShioto-object-data-stuff-function-stuff.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MelinShioto-object-data-stuff-function-stuff.md
index 62122b2..9e42384 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MelinShioto-object-data-stuff-function-stuff.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MelinShioto-object-data-stuff-function-stuff.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @MelinShioto
+**1/** **@MelinShioto** ^2036791325593379203
 
-@BOENSAW
+**@BOENSAW**
 
 Object { data stuff; function stuff }
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MildlyNuclear-everything-is-just-functions-and-variables-its.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MildlyNuclear-everything-is-just-functions-and-variables-its.md
index dee655f..2383170 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MildlyNuclear-everything-is-just-functions-and-variables-its.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MildlyNuclear-everything-is-just-functions-and-variables-its.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @MildlyNuclear
+**1/** **@MildlyNuclear** ^2036815667723166017
 
-@BOENSAW
+**@BOENSAW**
 
 everything is just functions and variables, it's functions all the way down
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-NotHenryFonda-theres-a-whole-book-about-this-https-www.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-NotHenryFonda-theres-a-whole-book-about-this-https-www.md
index 1538ac1..e02569e 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-NotHenryFonda-theres-a-whole-book-about-this-https-www.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-NotHenryFonda-theres-a-whole-book-about-this-https-www.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @NotHenryFonda
+**1/** **@NotHenryFonda** ^2036657302204260461
 
-@BOENSAW
+**@BOENSAW**
 
 there's a whole book about this https://www.dataorienteddesign.com/dodbook/
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-RaykiruS-so-not-an-ecs-but-only-a-es.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-RaykiruS-so-not-an-ecs-but-only-a-es.md
index 0e02c93..a291cda 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-RaykiruS-so-not-an-ecs-but-only-a-es.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-RaykiruS-so-not-an-ecs-but-only-a-es.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @RaykiruS
+**1/** **@RaykiruS** ^2036787677765288054
 
-@BOENSAW
+**@BOENSAW**
 
 So, not an ecs but only a es
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Ryunocore-patterns-are-guidelines-but-coding-is-a-holistic.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Ryunocore-patterns-are-guidelines-but-coding-is-a-holistic.md
index 0794184..263fdaa 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Ryunocore-patterns-are-guidelines-but-coding-is-a-holistic.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Ryunocore-patterns-are-guidelines-but-coding-is-a-holistic.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @Ryunocore
+**1/** **@Ryunocore** ^2036858460520755594
 
-@BOENSAW
+**@BOENSAW**
 
 Patterns are guidelines, but coding is a holistic and spiritual activity. Unironically follow your heart.
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-TheWireWhiz-the-only-thing-you-ever-need-to-think-about-is.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-TheWireWhiz-the-only-thing-you-ever-need-to-think-about-is.md
index bbef87d..55b691b 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-TheWireWhiz-the-only-thing-you-ever-need-to-think-about-is.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-TheWireWhiz-the-only-thing-you-ever-need-to-think-about-is.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @TheWireWhiz
+**1/** **@TheWireWhiz** ^2036795872302739892
 
-@BOENSAW
+**@BOENSAW**
 
 The only thing you ever need to think about is how the data flows, and sometimes when it flows if the paths leak. Everything else is an abstraction over that.
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_Detrend_-thats-because-entities-and-ecs-are-the-new-shiny.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_Detrend_-thats-because-entities-and-ecs-are-the-new-shiny.md
index 4362f64..6d226c1 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_Detrend_-thats-because-entities-and-ecs-are-the-new-shiny.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_Detrend_-thats-because-entities-and-ecs-are-the-new-shiny.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @_Detrend_
+**1/** **@_Detrend_** ^2036773206984470619
 
-@BOENSAW
+**@BOENSAW**
 
 Thats because entities and ECS are the new shiny thing and everyone loves to jump on the cool train.
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_flashman_harry-finding-out-being-turing-complete-just-requires.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_flashman_harry-finding-out-being-turing-complete-just-requires.md
index 9f5e3cd..3a56f2a 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_flashman_harry-finding-out-being-turing-complete-just-requires.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_flashman_harry-finding-out-being-turing-complete-just-requires.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @_flashman_harry
+**1/** **@_flashman_harry** ^2036755293187592636
 
-@BOENSAW
+**@BOENSAW**
 
 Finding out being Turing complete just requires less and not more?
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-ccallac7-all-that-matters-is-memory-and-logic-everything.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-ccallac7-all-that-matters-is-memory-and-logic-everything.md
index 5d3a986..c99b49b 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-ccallac7-all-that-matters-is-memory-and-logic-everything.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-ccallac7-all-that-matters-is-memory-and-logic-everything.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @ccallac7
+**1/** **@ccallac7** ^2036802494194729189
 
-@BOENSAW
+**@BOENSAW**
 
 All that matters is memory and logic, everything else is a made up abstraction
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-galactix____-there-are-no-universal-pattern-common-to-every.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-galactix____-there-are-no-universal-pattern-common-to-every.md
index c6b7a37..9ffdc18 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-galactix____-there-are-no-universal-pattern-common-to-every.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-galactix____-there-are-no-universal-pattern-common-to-every.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @galactix____
+**1/** **@galactix____** ^2036789325338194102
 
-@BOENSAW
+**@BOENSAW**
 
 There are no universal pattern common to every game, especially if you are searching for efficiency. Each game have its own optimization specifics
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-mcnabbd-thread.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-mcnabbd-thread.md
index 456c6ab..5fe57ea 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-mcnabbd-thread.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-mcnabbd-thread.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @mcnabbd
+**1/** **@mcnabbd** ^2036803466698674505
 
-@BOENSAW
+**@BOENSAW**
 
 <video controls src="https://video.twimg.com/tweet_video/HEQt9MWb0AEyGm2.mp4"></video>
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-neverworksgames-objects-arrays-singletons-thats-it.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-neverworksgames-objects-arrays-singletons-thats-it.md
index 946b78d..a219605 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-neverworksgames-objects-arrays-singletons-thats-it.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-neverworksgames-objects-arrays-singletons-thats-it.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @neverworksgames
+**1/** **@neverworksgames** ^2036777865643991443
 
-@BOENSAW
+**@BOENSAW**
 
 Objects, arrays, singletons. That's it.
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-nouriosplpolska-i-feel-like-the-actually-useful-patterns-just.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-nouriosplpolska-i-feel-like-the-actually-useful-patterns-just.md
index c2a2783..e63647b 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-nouriosplpolska-i-feel-like-the-actually-useful-patterns-just.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-nouriosplpolska-i-feel-like-the-actually-useful-patterns-just.md
@@ -26,15 +26,15 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @nouriosplpolska
+**1/** **@nouriosplpolska** ^2036762408027316597
 
-@BOENSAW
+**@BOENSAW**
 
 I feel like the actually useful patterns just emerge by themselves if you try doing something that needs them.
 
-**2/** @BOENSAW
+**2/** **@BOENSAW** ^2036778414791909453
 
-@nouriosplpolska
+**@nouriosplpolska**
 
 That's very much been my experience. it's not that they aren't useful under certain scenarios, but they're just as often not and rather than following a rigid structure it's better just to use the right tool for the situation
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-samloeschen-team-fat-struct.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-samloeschen-team-fat-struct.md
index 4ee7572..1ffe6a0 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-samloeschen-team-fat-struct.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-samloeschen-team-fat-struct.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @samloeschen
+**1/** **@samloeschen** ^2036835437797396644
 
-@BOENSAW
+**@BOENSAW**
 
 team fat struct!
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-struc_ture-eventually-you-realize-literally-nothing-matters.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-struc_ture-eventually-you-realize-literally-nothing-matters.md
index afea037..50b1054 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-struc_ture-eventually-you-realize-literally-nothing-matters.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-struc_ture-eventually-you-realize-literally-nothing-matters.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @struc_ture
+**1/** **@struc_ture** ^2036758034144510171
 
-@BOENSAW
+**@BOENSAW**
 
 Eventually you realize literally nothing matters except for love and friendship!!!!
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-HaskellEnjoyer-just-go-full-haskell-and-realize-that-everything.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-HaskellEnjoyer-just-go-full-haskell-and-realize-that-everything.md
index 182cf13..449a7ce 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-HaskellEnjoyer-just-go-full-haskell-and-realize-that-everything.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-HaskellEnjoyer-just-go-full-haskell-and-realize-that-everything.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @HaskellEnjoyer
+**1/** **@HaskellEnjoyer** ^2036997821379822035
 
-@BOENSAW
+**@BOENSAW**
 
 Just go full haskell and realize that everything is a function
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-RafaAsor-this-is-a-take-for-the-whole-software-industry.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-RafaAsor-this-is-a-take-for-the-whole-software-industry.md
index 3d7bfe2..b5e8984 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-RafaAsor-this-is-a-take-for-the-whole-software-industry.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-RafaAsor-this-is-a-take-for-the-whole-software-industry.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @RafaAsor
+**1/** **@RafaAsor** ^2037115807667232798
 
-@BOENSAW
+**@BOENSAW**
 
 This is a take for the whole software industry
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-angus_mang-functions-that-operate-on-structs-classes.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-angus_mang-functions-that-operate-on-structs-classes.md
index 7683cd7..9505ef6 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-angus_mang-functions-that-operate-on-structs-classes.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-angus_mang-functions-that-operate-on-structs-classes.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @angus_mang
+**1/** **@angus_mang** ^2037008038134006163
 
-@BOENSAW
+**@BOENSAW**
 
 Functions that Operate on Structs/Classes/Entities/Objects makes things simple. C++ or heavy, container-ized / encapsulated Class/Structs muddies. Serves for poor organization and juggling abstract ideas instead of. 
 Big ass block thing
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-eta9499-you-are-almost-there-unc.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-eta9499-you-are-almost-there-unc.md
index 135870a..a6d25b4 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-eta9499-you-are-almost-there-unc.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-eta9499-you-are-almost-there-unc.md
@@ -26,9 +26,9 @@ parent_post_id: "2036653149948424230"
 
 ## Branch
 
-**1/** @eta9499
+**1/** **@eta9499** ^2037038809129394422
 
-@BOENSAW
+**@BOENSAW**
 
 you are almost there unc
 
diff --git a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/index.md b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/index.md
index a68216f..dbb21ee 100644
--- a/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/index.md
+++ b/archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/index.md
@@ -25,14 +25,14 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @BOENSAW
+**1/** **@BOENSAW** ^2036653149948424230
 
 the more experienced I get programming games the more that I realize patterns like inheritance and components don't matter, the only thing that matters is functions and entities which run functions... entities might be the next thing to go
 
 Branches: [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-NotHenryFonda-theres-a-whole-book-about-this-https-www]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_flashman_harry-finding-out-being-turing-complete-just-requires]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-struc_ture-eventually-you-realize-literally-nothing-matters]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-nouriosplpolska-i-feel-like-the-actually-useful-patterns-just]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-_Detrend_-thats-because-entities-and-ecs-are-the-new-shiny]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-KnightOfTh3Wind-how-do-you-even-have-a-functioning-game-without]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-neverworksgames-objects-arrays-singletons-thats-it]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-RaykiruS-so-not-an-ecs-but-only-a-es]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-galactix____-there-are-no-universal-pattern-common-to-every]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MelinShioto-object-data-stuff-function-stuff]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-TheWireWhiz-the-only-thing-you-ever-need-to-think-about-is]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-ccallac7-all-that-matters-is-memory-and-logic-everything]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-mcnabbd-thread]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Jonathan_Blow-entities-dont-have-to-go-but-having-a-mental]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-MildlyNuclear-everything-is-just-functions-and-variables-its]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-HQuarterma43504-gamemaker-introduced-me-to-the-entity-paradigm]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-samloeschen-team-fat-struct]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-25-Ryunocore-patterns-are-guidelines-but-coding-is-a-holistic]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-HaskellEnjoyer-just-go-full-haskell-and-realize-that-everything]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-angus_mang-functions-that-operate-on-structs-classes]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-eta9499-you-are-almost-there-unc]], [[archive/threads/BOENSAW/2026-03-25-the-more-experienced-i-get-programming-games-the/2026-03-26-RafaAsor-this-is-a-take-for-the-whole-software-industry]]
 
-**2/** @BenboQuest
+**2/** **@BenboQuest** ^2036656311367266745
 
-@BOENSAW
+**@BOENSAW**
 
 i only been saying this
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-Alecazam123-hard-to-believe-im-still-writing-games-in-win32.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-Alecazam123-hard-to-believe-im-still-writing-games-in-win32.md
index 548c295..d02c914 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-Alecazam123-hard-to-believe-im-still-writing-games-in-win32.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-Alecazam123-hard-to-believe-im-still-writing-games-in-win32.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @Alecazam123
+**1/** **@Alecazam123** ^2010391151208251442
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Hard to believe I’m still writing games in Win32 25 years later.  But it runs on SteamOS, so can never be replaced now.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-BowTiedTails-yep-win32-is-heaven-when-you-see-what-else-is-out.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-BowTiedTails-yep-win32-is-heaven-when-you-see-what-else-is-out.md
index 42f5152..f11fc60 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-BowTiedTails-yep-win32-is-heaven-when-you-see-what-else-is-out.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-BowTiedTails-yep-win32-is-heaven-when-you-see-what-else-is-out.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @BowTiedTails
+**1/** **@BowTiedTails** ^2010494359062327682
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Yep. Win32 is heaven when you see what else is out there.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-coincidentally-i-made-a-vulkan-wayland-compute.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-coincidentally-i-made-a-vulkan-wayland-compute.md
index a294574..81c093c 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-coincidentally-i-made-a-vulkan-wayland-compute.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-coincidentally-i-made-a-vulkan-wayland-compute.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @VPCOMPRESSB
+**1/** **@VPCOMPRESSB** ^2010378880209871041
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 coincidentally, i made a Vulkan Wayland compute engine yesterday in ~600 LoC.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-yeah-i-actually-prefer-wayland-because-if-you.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-yeah-i-actually-prefer-wayland-because-if-you.md
index 03ea77e..779c9dd 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-yeah-i-actually-prefer-wayland-because-if-you.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-yeah-i-actually-prefer-wayland-because-if-you.md
@@ -26,42 +26,42 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @VPCOMPRESSB
+**1/** **@VPCOMPRESSB** ^2010385913541546282
 
 yeah. i actually prefer Wayland because if you implement something super simple, you get something super simple back (e.g., if i create a window, i get the bare minimum window - no decorations, no resizing, no keyboard or mouse input). with Win32, i'd have fight it and move through its weeds to force it to make something simple.
 another problem with Win32 is that it modularizes too much, and make everything seem irrelevant from each other. in Wayland, it's all unified, where if just learn 1 pattern from 1 thing, you can apply that pattern to everything else, from windows to input (e.g., all interfaces are just a simple server-client messaging model). basically, you can take a step back and look at everything as a whole, and clearly see a pattern.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2010396312651649276
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 You didn't get the true Wayland experience until you try interfacing to Wayland without the Wayland user-space library. Meaning do it with just the kernel calls required. Then you will have taken the gold off the poop, and understood how bad it actually is.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2010398147617640535
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 WIN32 base system DLLs are a substantially cleaner interface. I only do non-decorated full-screen (foreground or background) window. Majority of WIN32 code fits on screen grab with mostly comments. I'm not a fan of their "WndProc" but at least it is simple.
 
 ![](https://pbs.twimg.com/media/G-Zd9wLWUAE9kZj?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2010398743422709770
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 Some like to hate on X11, but for what it was designed to do (support both local and remote displays), it is at least very well documented and actually quite easy to roll an interface for with just Linux kernel calls (no external libraries). Docs here: https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2010404729633829180
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 Duckduckgo Wayland protocol and you get this garbage as documentation (below). Nothing there actually explains how it works, it's just high-level OOP obfustication speak. My vomit translator cannot even process this stuff.
 
 ![](https://pbs.twimg.com/media/G-Zjy3uXgAETWbE?format=jpg&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2010407422272160202
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 Lets continue. It's built over unix domain sockets and doesn't support remote rendering. Haha, WFT. Just because they want to transfer file descriptors between processes for "bulk data". Wayland looses network displays and is SLOWER (fail): https://www.dedoimedo.com/computers/plasma-6-4-performance-wayland-x11-power-cpu-kernel.html
 
@@ -69,47 +69,47 @@ Lets continue. It's built over unix domain sockets and doesn't support remote re
 ![](https://pbs.twimg.com/media/G-Zla8PXYAAdRoE?format=png&name=orig)
 ![](https://pbs.twimg.com/media/G-ZmyPCWQAAKtYR?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2010411498729046449
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 Don't understand why Linux people had to take what was working, X11, and instead of just improving it, they had to make something that {removed the remote desktop, made it slower, and forces an OOP garbage design}. There is nothing good here.
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^2010412846845473278
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 Another great thing about X11, is that it was trivial to both write and use your own window manager, using the same stable system for DECADES. I had a 350 line minwm.c window manager. Dead easy.
 
 ![](https://pbs.twimg.com/media/G-ZrxUJXwAAINS7?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^2010418524376981598
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 Unix was about KISS (keep it simple stupid) then Linux user-space people transformed that into MISC {make it stupid complex}. Seen this trend with Audio, from OSS to ALSA, and so on.
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^2010420107630330273
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 I worked in the {SunOS,Solaris,HPUX,SGI,AXI,etc} workstation era and started on Linux before ELF and before pthreads. Meaning I build things based on fork() [instead of pthreads] and SHM (shared page mappings) when doing local-only interfaces (no high kernel call granularity).
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^2010421431105093819
 
-@VPCOMPRESSB @Dispatch_Graph
+**@VPCOMPRESSB** **@Dispatch_Graph**
 
 If Linux people wanted to replace X11 with a local only interface, at a minimum it should have been simple SHM for the majority, and then only go outside SHM when needing to say kick a doorbell (make wake another process), etc.
 
-**12/** @o__boga
+**12/** **@o__boga** ^2010504713867870403
 
-@NOTimothyLottes @VPCOMPRESSB @Dispatch_Graph
+**@NOTimothyLottes** **@VPCOMPRESSB** **@Dispatch_Graph**
 
 Obfuscation is the secret for its "security!"!
 
-**13/** @VPCOMPRESSB
+**13/** **@VPCOMPRESSB** ^2010498624157782265
 
-@NOTimothyLottes @Dispatch_Graph
+**@NOTimothyLottes** **@Dispatch_Graph**
 
 i've never actually used X11. this is much easier.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-hadal101dev-yea-windows-makes-some-interesting-choices-lol.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-hadal101dev-yea-windows-makes-some-interesting-choices-lol.md
index 0307163..54f9fa3 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-hadal101dev-yea-windows-makes-some-interesting-choices-lol.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-hadal101dev-yea-windows-makes-some-interesting-choices-lol.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @hadal101dev
+**1/** **@hadal101dev** ^2010378989022622068
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Yea windows makes some interesting choices lol. Calling CreateFile when you want to OPEN a file? very weird lol.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-smolus-one-thing-i-appreciate-about-wayland-is-that-its.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-smolus-one-thing-i-appreciate-about-wayland-is-that-its.md
index 0898315..70bb502 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-smolus-one-thing-i-appreciate-about-wayland-is-that-its.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-smolus-one-thing-i-appreciate-about-wayland-is-that-its.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @smolus
+**1/** **@smolus** ^2010450157222154626
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 one thing I appreciate about wayland is that it's just a simple protocol spec so you are not married to any particular API/library but yeah it can be a lot of work to get basic things working
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Chris_Linux-apples-and-oranges-comparison-here.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Chris_Linux-apples-and-oranges-comparison-here.md
index 66e78ef..b43a5ed 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Chris_Linux-apples-and-oranges-comparison-here.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Chris_Linux-apples-and-oranges-comparison-here.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @Chris_Linux
+**1/** **@Chris_Linux** ^2010676815128301753
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Apples and oranges comparison here
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-FoundryOfLies-its-kwin.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-FoundryOfLies-its-kwin.md
index 04b0166..0fa456a 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-FoundryOfLies-its-kwin.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-FoundryOfLies-its-kwin.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @FoundryOfLies
+**1/** **@FoundryOfLies** ^2010725798114979912
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 It's KWin
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-JoaoBapt-i-suggest-you-to-stick-with-glfw-if-youre-only.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-JoaoBapt-i-suggest-you-to-stick-with-glfw-if-youre-only.md
index 5812192..c08c562 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-JoaoBapt-i-suggest-you-to-stick-with-glfw-if-youre-only.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-JoaoBapt-i-suggest-you-to-stick-with-glfw-if-youre-only.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @JoaoBapt
+**1/** **@JoaoBapt** ^2010753110805979471
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 I suggest you to stick with GLFW if you’re only doing Vulkan.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Oka7071-thread.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Oka7071-thread.md
index 8e69ff8..8cd4665 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Oka7071-thread.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Oka7071-thread.md
@@ -26,15 +26,15 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @Oka7071
+**1/** **@Oka7071** ^2010799896866255168
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 ![](https://pbs.twimg.com/media/G-fL2X9WAAARbpz?format=jpg&name=orig)
 
-**2/** @Dispatch_Graph
+**2/** **@Dispatch_Graph** ^2010808986619298248
 
-@Oka4902
+**@Oka4902**
 
 if you give me 3 trillion dollars I can elaborate
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-PervWizz-well-win32-began-as-a-bad-api-and-then.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-PervWizz-well-win32-began-as-a-bad-api-and-then.md
index 374aa2e..a426b99 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-PervWizz-well-win32-began-as-a-bad-api-and-then.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-PervWizz-well-win32-began-as-a-bad-api-and-then.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @PervWizz
+**1/** **@PervWizz** ^2010750206237651067
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Well. Win32 began as a bad API and then organically got reshaped into a worse one. Same goes for X11
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Rami36217810-what-about-x11.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Rami36217810-what-about-x11.md
index 7e0bd97..573f076 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Rami36217810-what-about-x11.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Rami36217810-what-about-x11.md
@@ -26,15 +26,15 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @Rami36217810
+**1/** **@Rami36217810** ^2010799138712273238
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 What about x11
 
-**2/** @Dispatch_Graph
+**2/** **@Dispatch_Graph** ^2010808862623027217
 
-@Rami36217810
+**@Rami36217810**
 
 its aight
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-SyntaxError2505-why-sdl-works-great.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-SyntaxError2505-why-sdl-works-great.md
index 41416dc..69ba2a7 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-SyntaxError2505-why-sdl-works-great.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-SyntaxError2505-why-sdl-works-great.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @SyntaxError2505
+**1/** **@SyntaxError2505** ^2010700042080862455
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Why? Sdl works great
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-f82james-fuck-x11.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-f82james-fuck-x11.md
index 539096f..1e73409 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-f82james-fuck-x11.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-f82james-fuck-x11.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @f82james
+**1/** **@f82james** ^2010735384750334453
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 fuck x11
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-linux_version-oddly-enough-with-how-old-the-wine-project-is.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-linux_version-oddly-enough-with-how-old-the-wine-project-is.md
index eaa69f9..4740f28 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-linux_version-oddly-enough-with-how-old-the-wine-project-is.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-linux_version-oddly-enough-with-how-old-the-wine-project-is.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @linux_version
+**1/** **@linux_version** ^2010740512769404946
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Oddly enough, with how old the wine project is, Win32 might be the most stable API on Linux.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-mizanyx-elaborate-please-im-still-an-x11-user.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-mizanyx-elaborate-please-im-still-an-x11-user.md
index 2aaa051..4eb095c 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-mizanyx-elaborate-please-im-still-an-x11-user.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-mizanyx-elaborate-please-im-still-an-x11-user.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @mizanyx
+**1/** **@mizanyx** ^2010686383954800643
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Elaborate please, I'm still an X11 user
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-platonvin-windows-h-is-like-a-nightmare-but-real-it-is-so.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-platonvin-windows-h-is-like-a-nightmare-but-real-it-is-so.md
index c78cd00..5c46b29 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-platonvin-windows-h-is-like-a-nightmare-but-real-it-is-so.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-platonvin-windows-h-is-like-a-nightmare-but-real-it-is-so.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @platonvin
+**1/** **@platonvin** ^2010728789396050001
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 windows.h is like a nightmare but real. It is so bad, that many people manually paste parts of it to avoid including entire thing
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-ruminaik-and-let-us-say-amen.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-ruminaik-and-let-us-say-amen.md
index 9b9aa0c..8c4d2dc 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-ruminaik-and-let-us-say-amen.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-ruminaik-and-let-us-say-amen.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @ruminaik
+**1/** **@ruminaik** ^2010733158996865131
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 And let us say Amen
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-thedarkhog-get-xlibre-instead-if-youre-using-arch-btw-its-in.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-thedarkhog-get-xlibre-instead-if-youre-using-arch-btw-its-in.md
index 7a36ab8..c18287f 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-thedarkhog-get-xlibre-instead-if-youre-using-arch-btw-its-in.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-thedarkhog-get-xlibre-instead-if-youre-using-arch-btw-its-in.md
@@ -26,9 +26,9 @@ parent_post_id: "2010303501851877740"
 
 ## Branch
 
-**1/** @thedarkhog
+**1/** **@thedarkhog** ^2010669573427884393
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 Get Xlibre instead. If you're using arch, btw., it's in the AUR.
 
diff --git a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/index.md b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/index.md
index c6b3189..e418ed7 100644
--- a/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/index.md
+++ b/archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/index.md
@@ -25,20 +25,20 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @Dispatch_Graph
+**1/** **@Dispatch_Graph** ^2010303501851877740
 
 Ok, the Win32 API sure is something, but WOW wayland is awful
 
 Branches: [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-coincidentally-i-made-a-vulkan-wayland-compute]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-hadal101dev-yea-windows-makes-some-interesting-choices-lol]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-VPCOMPRESSB-yeah-i-actually-prefer-wayland-because-if-you]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-Alecazam123-hard-to-believe-im-still-writing-games-in-win32]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-smolus-one-thing-i-appreciate-about-wayland-is-that-its]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-11-BowTiedTails-yep-win32-is-heaven-when-you-see-what-else-is-out]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-thedarkhog-get-xlibre-instead-if-youre-using-arch-btw-its-in]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Chris_Linux-apples-and-oranges-comparison-here]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-mizanyx-elaborate-please-im-still-an-x11-user]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-SyntaxError2505-why-sdl-works-great]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-FoundryOfLies-its-kwin]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-platonvin-windows-h-is-like-a-nightmare-but-real-it-is-so]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-ruminaik-and-let-us-say-amen]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-f82james-fuck-x11]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-linux_version-oddly-enough-with-how-old-the-wine-project-is]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-PervWizz-well-win32-began-as-a-bad-api-and-then]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-JoaoBapt-i-suggest-you-to-stick-with-glfw-if-youre-only]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Rami36217810-what-about-x11]], [[archive/threads/Dispatch_Graph/2026-01-11-ok-the-win32-api-sure-is-something-but-wow/2026-01-12-Oka7071-thread]]
 
-**2/** @ocarina588
+**2/** **@ocarina588** ^2010305588580974622
 
-@Dispatch_Graph
+**@Dispatch_Graph**
 
 😂😂😂, what are you using? Hyprland ?
 
-**3/** @Dispatch_Graph
+**3/** **@Dispatch_Graph** ^2010319408045183333
 
-@ocarina588
+**@ocarina588**
 
 KDE Plasma
diff --git a/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/2025-01-29-mu_chrinovic-i-know-a-person-with-a-phd-that-might-disagree.md b/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/2025-01-29-mu_chrinovic-i-know-a-person-with-a-phd-that-might-disagree.md
index 5fe383b..55b007a 100644
--- a/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/2025-01-29-mu_chrinovic-i-know-a-person-with-a-phd-that-might-disagree.md
+++ b/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/2025-01-29-mu_chrinovic-i-know-a-person-with-a-phd-that-might-disagree.md
@@ -26,39 +26,39 @@ parent_post_id: "1884730404587909544"
 
 ## Branch
 
-**1/** @mu_chrinovic
+**1/** **@mu_chrinovic** ^1884733082474775028
 
-@FFmpeg
+**@FFmpeg**
 
 I know a person with a PhD that might disagree with you
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1884744335385608455
 
-@mu_chrinovic @FFmpeg
+**@mu_chrinovic** **@FFmpeg**
 
 Yeah PTX is not assembly, it's a mid level language that is closer to a 1:1 match for the HW ISA --- BUT --- the actual register allocation and management is still done by a high-level compiler ...
 
-**3/** @janekm
+**3/** **@janekm** ^1884925339589038179
 
-@NOTimothyLottes @mu_chrinovic @FFmpeg
+**@NOTimothyLottes** **@mu_chrinovic** **@FFmpeg**
 
 That's almost semantics at this point though? If you're writing x86 assembly it gets translated to microcode in the CPU as well, and will do register remapping etc. Only difference in Nvidia case that's happening in the driver, right?
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1884980252822188188
 
-@janekm @mu_chrinovic @FFmpeg
+**@janekm** **@mu_chrinovic** **@FFmpeg**
 
 Sounds like you are trying to claim software compiler register allocation is the same as HW runtime register renaming? No. CPU register renaming maps a small set of registers to a larger set to get IPC. Compiler GPU reg allocation maps a massive SSA mess to a small set.
 
-**5/** @janekm
+**5/** **@janekm** ^1884981121089257481
 
-@NOTimothyLottes @mu_chrinovic @FFmpeg
+**@NOTimothyLottes** **@mu_chrinovic** **@FFmpeg**
 
 Fair point, my argument was merely that both cases of assembly language are really an intermediate language that gets translated to the final instructions executed by the CPU/GPU. Feels quite pedantic to claim that PTX assembly is not assembly, merely because of reg allocation 🤷‍♂️
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1884985388327977299
 
-@janekm @mu_chrinovic @FFmpeg
+**@janekm** **@mu_chrinovic** **@FFmpeg**
 
 SOFTWARE
 Assembler = human writes the physical HW instructions
@@ -68,15 +68,15 @@ HW
 Instruction-reordering / wave-scheduling
 Register renaming
 
-**7/** @janekm
+**7/** **@janekm** ^1884987565910204489
 
-@NOTimothyLottes @mu_chrinovic @FFmpeg
+**@NOTimothyLottes** **@mu_chrinovic** **@FFmpeg**
 
 We've been calling it Assembly since at least when JVM byte code was first a thing. Doesn't matter that a JIT compiler will still do register allocation.
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1884988325049561580
 
-@janekm @mu_chrinovic @FFmpeg
+**@janekm** **@mu_chrinovic** **@FFmpeg**
 
 Sure people have been incorrectly labeling stuff for a long time
 
diff --git a/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/index.md b/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/index.md
index 27a3ef6..0f8d5dd 100644
--- a/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/index.md
+++ b/archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/index.md
@@ -25,12 +25,12 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @FFmpeg
+**1/** **@FFmpeg** ^1884730404587909544
 
 PTX is a form of assembly language
 
 Branches: [[archive/threads/FFmpeg/2025-01-29-ptx-is-a-form-of-assembly-language/2025-01-29-mu_chrinovic-i-know-a-person-with-a-phd-that-might-disagree]]
 
-**2/** @FFmpeg
+**2/** **@FFmpeg** ^1884750918396051612
 
 https://docs.nvidia.com/cuda/inline-ptx-assembly/index.html
diff --git a/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-jaap_null-its-a-silly-thing-on-many-levels-the-entire-arch.md b/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-jaap_null-its-a-silly-thing-on-many-levels-the-entire-arch.md
index d863d3f..42ab7b2 100644
--- a/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-jaap_null-its-a-silly-thing-on-many-levels-the-entire-arch.md
+++ b/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-jaap_null-its-a-silly-thing-on-many-levels-the-entire-arch.md
@@ -26,9 +26,9 @@ parent_post_id: "1781724279798686001"
 
 ## Branch
 
-**1/** @jaap_null
+**1/** **@jaap_null** ^1783039982560784428
 
-@KostasAAA
+**@KostasAAA**
 
 It's a silly thing on many levels. The entire arch. limitation is awkward, then the way compilers deal (or not deal) with it is just broken. Sad to see it's still around.
 
diff --git a/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-matiasgoldberg-whats-the-value-of.md b/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-matiasgoldberg-whats-the-value-of.md
index 3aa7014..3a12324 100644
--- a/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-matiasgoldberg-whats-the-value-of.md
+++ b/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/2024-04-24-matiasgoldberg-whats-the-value-of.md
@@ -26,9 +26,9 @@ parent_post_id: "1781724279798686001"
 
 ## Branch
 
-**1/** @matiasgoldberg
+**1/** **@matiasgoldberg** ^1783166450733113360
 
-@KostasAAA
+**@KostasAAA**
 
 What's the value of shaderSampledImageArrayDynamicIndexing?
 
diff --git a/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/index.md b/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/index.md
index 7b1f7ed..44bb4fe 100644
--- a/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/index.md
+++ b/archive/threads/KostasAAA/2024-04-20-when-using-arrays-of-resources-bindless-its-worth/index.md
@@ -25,19 +25,19 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @KostasAAA
+**1/** **@KostasAAA** ^1781724275159728279
 
 When using arrays of resources/bindless, it's worth paying attention to index divergence. Even if using thread divergent indices, the compiler will use the index from the first active thread to access a resource, for all threads in the wave, which can cause hard to find bugs 1/3
 
 ![](https://pbs.twimg.com/media/GLnsaWeWoAA0c-x?format=jpg&name=orig)
 
-**2/** @KostasAAA
+**2/** **@KostasAAA** ^1781724277747613724
 
 This happens even when compiler knows that the index varies per thread. To fix this you need to use the NonUniformResourceIndex qualifier. The compiler will then add a waterfall loop to batch wave threads by resource index and ensure that each thread accesses the correct one. 2/3
 
 ![](https://pbs.twimg.com/media/GLntvM6W0AEVe0L?format=jpg&name=orig)
 
-**3/** @KostasAAA
+**3/** **@KostasAAA** ^1781724279798686001
 
 This can have a performance impact though, with the worst case being each thread indexing a different resource, both in terms of thread coherence (looping over each thread individually) and texture cache. For more info https://www.asawicki.info/news_1734_which_values_are_scalar_in_a_shader 3/3
 
diff --git a/archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md b/archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md
index f3d7372..ceb6345 100644
--- a/archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md
+++ b/archive/threads/MyNameIsMJP/2024-04-23-apparently-uniformity-analysis-is-hard/index.md
@@ -25,101 +25,101 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @MyNameIsMJP
+**1/** **@MyNameIsMJP** ^1782636381720006711
 
-@BelgianRenderer @KostasAAA @Nicolas_Lopez_
+**@BelgianRenderer** **@KostasAAA** **@Nicolas_Lopez_**
 
 Apparently uniformity analysis is hard. 🙁
 
-**2/** @KostasAAA
+**2/** **@KostasAAA** ^1782729117093253403
 
-@MyNameIsMJP @BelgianRenderer @Nicolas_Lopez_
+**@MyNameIsMJP** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 If uniformity can't be deduced, the compiler could be conservative and assume divergence. If it guessed wrong, the waterfall loop won't be executed and all threads will use the same index. Also, the shader author could help the compiler with a UniformResourceIndex qualifier.
 
-**3/** @MyNameIsMJP
+**3/** **@MyNameIsMJP** ^1782892139220766922
 
-@KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 Yeah I tend to agree that assuming non-uniformity by default for descriptor indexing would have been a better path, with some better language support for explicit tagging of uniform variables. Maybe in HLSL 2027. 🙂
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1782898526512378177
 
-@MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 Uniformity is the fast path, it would be horrible to tax the fast path for the sake of things designed to be slow (aka using resource divergence). The right thing to do is place in explicit uniform/nonuniform qualifiers into the languages so it's explicit.
 
-**5/** @JasperBekkers
+**5/** **@JasperBekkers** ^1783022121565778346
 
-@NOTimothyLottes @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@NOTimothyLottes** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 We do nuri for almost all our access (we sometimes turn it off because of badly readable Isa on amd). However the performance impact is in the noise, not all hw resolves this in the shader cores.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1783117204612935966
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 NV doesn't advertise this: 32-byte sector size (even with 128-byte lines) mixed with per lane IPs (so you can pipeline latency of divergent accesses) is all about shifting the perf cliff of bad behavior enough to win benchmarks, it is still a cliff (look at ALU utilization) ...
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1783118039287771353
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 AMD never invested in pipelining divergent latency, and their compiler compounds this by serializing a lot of other things that shouldn't be serialized ...
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1783118781503459544
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 If one is already into the perf cliff, it's easy on AMD to compound perf debt to the point something can never be optimized, and maybe that's ok if time-to-market/ease-of-use/etc is the primary goal ...
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1783121085875077596
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 There are cases where AMD's compiler is still failing hard on UNIFORM (aka wave coherent) multi-resource access: zero latency hiding -> every resource is a worst case serialization of {fetch descriptor, wait, sample} with zero pipelining ... example below
 
 ![](https://pbs.twimg.com/media/GL7p5vJXUAECnVi?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1783121769546580452
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 Or this case where the images get batched, but the descriptors accesses are serialized (below) ... so it's easy sometimes to assume NURI is not that expensive because the compiler already shot itself in the face (which is quite common in high complexity material shading).
 
 ![](https://pbs.twimg.com/media/GL7rS7uWsAEebjc?format=png&name=orig)
 
-**11/** @JasperBekkers
+**11/** **@JasperBekkers** ^1783123388375998776
 
-@NOTimothyLottes @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@NOTimothyLottes** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 Most of the time for us the resource access is uniform,  so the overhead is just a few waves to test this though.
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1783124026954506679
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 If the whole shader coherently branches into uniform vs non-uniform material paths, sure that can work if the non-uniform path is almost never used, and the compiler doesn't choak on the register pressure of the non-uniform code path.
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1783124921905778900
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 At least for the sake of learnings for others, I'll continue down the compiler rabbit hole a little more ... even serialized latency of K$ (constant) HITs (all in the cache) will destroy shader perf (a single hit is like 30 some clocks). This pattern happens on AMD today still.
 
 ![](https://pbs.twimg.com/media/GL7uT1wXoAA7CQj?format=png&name=orig)
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1783126767290487066
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 And as for 'fixing' bad programmer behavior via the compiler, lets look at atomicAdd() behavior. First the compiler will burn the overhead to elect an active lane even when the compiler statically knows lane zero is active (simple example below).
 
 ![](https://pbs.twimg.com/media/GL7wLb8WgAEicQD?format=png&name=orig)
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1783128096800981138
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 Try to out smart it like this,
 
@@ -130,16 +130,16 @@ It fights back, and makes something even worse. [RED] ... see the multiply by ac
 
 ![](https://pbs.twimg.com/media/GL7xh8ZWsAArlkO?format=png&name=orig)
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1783128648481951751
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 And sometimes it gets really squirrly and throws in a full wave reduction (see the DPP ops). When the good dev is just trying to do an already predicated to lane zero atomic ADD ...
 
 ![](https://pbs.twimg.com/media/GL7yB5cXIAACo5E?format=png&name=orig)
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1783129176158937434
 
-@JasperBekkers @MyNameIsMJP @KostasAAA @BelgianRenderer @Nicolas_Lopez_
+**@JasperBekkers** **@MyNameIsMJP** **@KostasAAA** **@BelgianRenderer** **@Nicolas_Lopez_**
 
 So if any solution depends on trusting a compiler to implicitly do the right thing, I'd be very very concerned, because they don't. Compiler size perf 'fixes' are brittle, break easy, and become massive nightmares for programmers who know what they are doing.
diff --git a/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/2022-11-04-rianflo-welcome-not-back.md b/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/2022-11-04-rianflo-welcome-not-back.md
index 66a3c6a..90111a5 100644
--- a/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/2022-11-04-rianflo-welcome-not-back.md
+++ b/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/2022-11-04-rianflo-welcome-not-back.md
@@ -26,9 +26,9 @@ parent_post_id: "1588515348223254528"
 
 ## Branch
 
-**1/** @rianflo
+**1/** **@rianflo** ^1588561182730113025
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Welcome Not Back! 🤘🏻♥️
 
diff --git a/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/index.md b/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/index.md
index 772ee6b..af16e64 100644
--- a/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/index.md
+++ b/archive/threads/NOTimothyLottes/2022-11-04-vulkan-1500-lines-of-overhead-including-header/index.md
@@ -28,9 +28,9 @@ in_reply_to: "1588331007622930432"
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1588515348223254528
 
-@rianflo
+**@rianflo**
 
 Vulkan: ~1500 lines of overhead (including header src, as I don't include) for complete hotrod bind-everything-only-once compute-only gfx engine. Not a fan of VK bloatware API complexity, but frankly it can be minimized, and exposes enough to do wonderfull things to the hardware.
 
diff --git a/archive/threads/NOTimothyLottes/2022-11-05-gpu-programming-tip-line-thread/index.md b/archive/threads/NOTimothyLottes/2022-11-05-gpu-programming-tip-line-thread/index.md
index 36cca31..2c632a7 100644
--- a/archive/threads/NOTimothyLottes/2022-11-05-gpu-programming-tip-line-thread/index.md
+++ b/archive/threads/NOTimothyLottes/2022-11-05-gpu-programming-tip-line-thread/index.md
@@ -25,86 +25,86 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1588902081502797826
 
 GPU Programming Tip Line Thread /
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1588902190034620417
 
 [0] Normalization fail case is 'rsq(0)=INF*0=NaN', trim out intermediate INF to fix, 'normalize_safe(x){return x*min(MAX_FLOAT,rsq(dot(x,x)));}'
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1588902600686329857
 
 [1] PC FP16 1/denormals generates INFs which can easily eventually result in NaNs, fix positives with 'rcp(max(x,SMALLEST_NORMAL))'
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1588903127549607936
 
 [2] 'spirv-opt -Os' (optimize for size) is your weapon against "back-before-its-done--getting-groceries" IHV compile times
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1588903378952007680
 
 [3] Driver ignoring your '[[dont_unroll]]', 'int eatThisBuddy=1+/*hidden-zero*/constantBuffer.zero[0];for(i=0;i<1024;i+=eatThisBuddy){...'
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1588903586721042432
 
 [4] 'Ship-One-Shader' = One SPIR-V binary, use specialization constants to select shader at PSO generation time, minimizes released shader binary size
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1588903663468437508
 
 [5] 'Ship-One-Shader' requires 'spirv-opt -Os'
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1588903725783220224
 
 [6] Use signed 'mask=bitfieldExtract(int(v),bit,1)' to turn bit into all 0's or 1's mask
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1588903926510014467
 
 [7] On PC for AMD's native V_BFI_B32 (to select bits based on mask) use 'Bfi(int src,int ins,int mask){return (ins&mask)|(src&(~mask));}'
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1588904013239844870
 
 [8] Use 'bitfieldInsert(,,0,compileTimeImmediate)' hits fast V_BFI_B32 on AMD, and portable to other vendors
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1588904166269005824
 
 [9] AMD ONLY: clamp(a,b,c) is implemented as med3(a,b,c), so can get V_MED3_* without an extension (in a non-portable way)
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1588904259265114112
 
 [10] Bools as 0|1 floats '(a&b)|c' can be done via 'saturate(a*b+c)'
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1588904325543493633
 
 [11] Bools as 0|1 floats '!(a&b)' can be done via '(-a)*b+1.0'
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1588904434268262400
 
 [12] Convert INFs to NaNs via 'x*0.0+x'
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1588904891707424768
 
 [13] Semi-persistent workgroup opt = reusing the workgroup for more work before exit (ie processing four 8x8 tiles in a 16x16 footprint using a 64-wide group)
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1588905179449282560
 
 [14] Semi-persistent workgroups can be good for up to 10% perf on AMD (YMMV) ... assuming compiler doesn't fail VGPR allocation, check your disassembly
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1588905286697639936
 
 [15] Semi-persistent workgroups gain by keeping more local work on the same L0, by factoring out wait for store on wave exit, and better scheduling
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1588905339122257921
 
 [16] Merge passes to avoid round trip through DRAM, often huge wins there
 
-**19/** @NOTimothyLottes
+**19/** **@NOTimothyLottes** ^1588905491027341312
 
 [17] Sometimes serial dependent passes can be merged into one shader to keep work in L2 for >10% gains, requires "unsafe you-shouldnt-do-that" logic that works
 
-**20/** @NOTimothyLottes
+**20/** **@NOTimothyLottes** ^1588905764005216258
 
 [18] Proper double rate "packed" 16-bit can provides gains up to 30% depending on workload/platform (except NV)
 
-**21/** @NOTimothyLottes
+**21/** **@NOTimothyLottes** ^1588906002212323328
 
 [19] Even without double rate 16-bit, 16-bit is the most important tool for managing register pressure problems, esp with smaller HW register limits or compiler troubles
diff --git a/archive/threads/NOTimothyLottes/2022-11-08-example-of-bind-everything-once-layout-aliasing/index.md b/archive/threads/NOTimothyLottes/2022-11-08-example-of-bind-everything-once-layout-aliasing/index.md
index 6ca5fd1..48b9beb 100644
--- a/archive/threads/NOTimothyLottes/2022-11-08-example-of-bind-everything-once-layout-aliasing/index.md
+++ b/archive/threads/NOTimothyLottes/2022-11-08-example-of-bind-everything-once-layout-aliasing/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1589810282104524800
 
 Example of "Bind-Everything-Once" Layout Aliasing in Vulkan. Storage image format by aliased name, also bound as sampled image. Choose buffer {readonly,writeonly,volatile (read uncached),atomic} access by aliased name, as either {uint,uint4,float,float4}.
 
diff --git a/archive/threads/NOTimothyLottes/2022-11-09-if-only-pc-vendors-with-open-isas/index.md b/archive/threads/NOTimothyLottes/2022-11-09-if-only-pc-vendors-with-open-isas/index.md
index 2e60ee8..061c768 100644
--- a/archive/threads/NOTimothyLottes/2022-11-09-if-only-pc-vendors-with-open-isas/index.md
+++ b/archive/threads/NOTimothyLottes/2022-11-09-if-only-pc-vendors-with-open-isas/index.md
@@ -25,8 +25,8 @@ in_reply_to: "1590003266129383424"
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1590241107317002240
 
-@olson_dan
+**@olson_dan**
 
 If only PC vendors with open ISAs (AMD/Intel) would allow loading binary compute shaders in VK built using non-driver toolchains. If Valve enabled binary shaders on Steam Deck in Linux, that would be my new exclusive dev platform, instead of just a possible porting target
diff --git a/archive/threads/NOTimothyLottes/2022-11-13-my-prefered-method-of-managing-application-data/index.md b/archive/threads/NOTimothyLottes/2022-11-13-my-prefered-method-of-managing-application-data/index.md
index f0696c0..e49365d 100644
--- a/archive/threads/NOTimothyLottes/2022-11-13-my-prefered-method-of-managing-application-data/index.md
+++ b/archive/threads/NOTimothyLottes/2022-11-13-my-prefered-method-of-managing-application-data/index.md
@@ -25,6 +25,6 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1591646625692553216
 
 My prefered method of managing application data was the 'self-modifying-binary': (a.) on launch copy binary to temp file, (b.) launch temp file, (c.) exit, (d.) now temp file execution can freely modify origional binary :)
diff --git a/archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md b/archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md
index 22cf260..afe9b05 100644
--- a/archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md
+++ b/archive/threads/NOTimothyLottes/2023-04-28-https-gpuopen-com-learn-rgp-1-15-enhanced-isa/index.md
@@ -25,22 +25,22 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1651938781610508288
 
 https://gpuopen.com/learn/rgp-1-15-enhanced-isa-view/ Nice Disasm View :) - However op  latency isn't useful. Need to see multiwave instruction trace across time, colored by instruction type, enhanced with mark if wave is waiting to issue a given functional unit. Only then will great optimization be possible.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1651939770350678019
 
 It would also be best to see overlay of board power (because !/W is the end goal), and an overlay of exactly where there are bubbles in DRAM traffic. Because anything memory bound, the goal is to minimize DRAM bubbles. Need to see how they form dynamically over time to fix ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1651941119075164162
 
 For GPU profilers, might see say {92% ALU, 50% TEX, 21% L2}, then wonder, where is 8% I'm missing. And only way to start to understand that, is to be seeing how waves are executing instruction wise against each other. CPU-profiler-like averages per disassembly line won't cut it.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1651945376847392769
 
 Parallel machines can only be understood by seeing the parallel execution. I still have examples today of taking a vanila 32-bit shader (already designed to be fast) and getting 30% returns on all micro optimizations.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1651946306737250304
 
 Lastly, side with enabling. Remember people can learn too. And there is typically super skilled people seeded at all companies that teach others how to use advanced tools when they are available.
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrianKaris-great-to-see-these-return-still-have-any-of-the.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrianKaris-great-to-see-these-return-still-have-any-of-the.md
index 53202cb..eecab6f 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrianKaris-great-to-see-these-return-still-have-any-of-the.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrianKaris-great-to-see-these-return-still-have-any-of-the.md
@@ -26,15 +26,15 @@ parent_post_id: "1653556990302470151"
 
 ## Branch
 
-**1/** @BrianKaris
+**1/** **@BrianKaris** ^1653593003368546304
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Great to see these return. Still have any of the videos?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1653742549066973185
 
-@BrianKaris
+**@BrianKaris**
 
 I might, but will have to build a machine to attach the old drives. Too busy making new stuff
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrookeHodgman-i-remember-watching-all-of-these-blog-entries.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrookeHodgman-i-remember-watching-all-of-these-blog-entries.md
index b0b1d50..86e1347 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrookeHodgman-i-remember-watching-all-of-these-blog-entries.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrookeHodgman-i-remember-watching-all-of-these-blog-entries.md
@@ -26,9 +26,9 @@ parent_post_id: "1653556990302470151"
 
 ## Branch
 
-**1/** @BrookeHodgman
+**1/** **@BrookeHodgman** ^1653666232749682689
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I remember watching all of these blog entries fondly ❤
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-Karyuutensei-is-the-blog-still-up-somewhere.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-Karyuutensei-is-the-blog-still-up-somewhere.md
index b00e58b..9c1c126 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-Karyuutensei-is-the-blog-still-up-somewhere.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-Karyuutensei-is-the-blog-still-up-somewhere.md
@@ -26,21 +26,21 @@ parent_post_id: "1653556990302470151"
 
 ## Branch
 
-**1/** @Karyuutensei
+**1/** **@Karyuutensei** ^1653661020026466307
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Is the blog still up somewhere?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1653743479032250373
 
-@Karyuutensei
+**@Karyuutensei**
 
 No but I have archives in pieces on old hard drives. So there is a chance I might restore it some day.
 
-**3/** @Karyuutensei
+**3/** **@Karyuutensei** ^1653746161050693634
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Speaking of archives, http://archive.org  has some from the blogspot here https://web.archive.org/web/20160427173127/http://timothylottes.blogspot.com/ but basically nothing from the github page :S
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-oconnorkg-did-you-write-an-engine-called-atom-talked-about.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-oconnorkg-did-you-write-an-engine-called-atom-talked-about.md
index 714ca80..f77d851 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-oconnorkg-did-you-write-an-engine-called-atom-talked-about.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-oconnorkg-did-you-write-an-engine-called-atom-talked-about.md
@@ -26,15 +26,15 @@ parent_post_id: "1653556990302470151"
 
 ## Branch
 
-**1/** @oconnorkg
+**1/** **@oconnorkg** ^1653842852210782209
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Did you write an engine called Atom? Talked about it on the http://OpenGL.org forum?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1653872960455823363
 
-@oconnorkg
+**@oconnorkg**
 
 There was also Atomontage or something like that by another person. I had a project called Atom, but I don't remember if I was on the OGL message board
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-i-remember-all-those-fondly-i-also-remembered-the.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-i-remember-all-those-fondly-i-also-remembered-the.md
index eda1e26..480b552 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-i-remember-all-those-fondly-i-also-remembered-the.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-i-remember-all-those-fondly-i-also-remembered-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1653556990302470151"
 
 ## Branch
 
-**1/** @won3d
+**1/** **@won3d** ^1653557420805767170
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I remember all those fondly. I also remembered the trick you did to batch logical draw calls with branching in the shader
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-my-former-thesis-advisor-was-a-big-proponent-of.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-my-former-thesis-advisor-was-a-big-proponent-of.md
index 85ba428..23b23a3 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-my-former-thesis-advisor-was-a-big-proponent-of.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-my-former-thesis-advisor-was-a-big-proponent-of.md
@@ -26,21 +26,21 @@ parent_post_id: "1653559205360553985"
 
 ## Branch
 
-**1/** @won3d
+**1/** **@won3d** ^1653573851643625480
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 My former thesis advisor was a big proponent of forth. Apparently SunOS used forth in preboot and you could do all sorts of wacky things. He interfaced with custom compute accelerators this way. I agree that concatenantive programming languages are underexplored
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1653577630229098497
 
-@won3d
+**@won3d**
 
 I think it is less the exact form of the language but more 'the way to make things simple' that truely important now.
 
-**3/** @won3d
+**3/** **@won3d** ^1653585212628951047
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 There's something about Forth-style composition that is has a very nice appeal. It really seems to marry syntax and semantics very directly (but I can appreciate it at a distance, having not done any real work in it as you have)
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-04-Laxer3A-this-is-when-i-learned-about-your-work-and-found.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-04-Laxer3A-this-is-when-i-learned-about-your-work-and-found.md
index dbed188..ffc2de9 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-04-Laxer3A-this-is-when-i-learned-about-your-work-and-found.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-04-Laxer3A-this-is-when-i-learned-about-your-work-and-found.md
@@ -26,9 +26,9 @@ parent_post_id: "1653570742762479620"
 
 ## Branch
 
-**1/** @Laxer3A
+**1/** **@Laxer3A** ^1654169796328423450
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 This is when I learned about your work and found it incredible. Nowadays with 4K / 8K, people are really craving for a very good shader/model to emulate as close as possible the CRT feel for arcade / old console etc. (I am serious)
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-06-arm1n-thanks-for-digging-those-up-great-stuff-very.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-06-arm1n-thanks-for-digging-those-up-great-stuff-very.md
index 876a100..520ba07 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-06-arm1n-thanks-for-digging-those-up-great-stuff-very.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-06-arm1n-thanks-for-digging-those-up-great-stuff-very.md
@@ -26,9 +26,9 @@ parent_post_id: "1653556990302470151"
 
 ## Branch
 
-**1/** @arm1n
+**1/** **@arm1n** ^1654835157789016064
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Thanks for digging those up! Great stuff, very inspiring.
 
diff --git a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/index.md b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/index.md
index 7d311c4..d785ea3 100644
--- a/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/index.md
+++ b/archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1653556990302470151
 
 Found some of my old blogs: thread looking back an image at a time. 2007, ellipsoid l-system sprites with temporal feedback, yes temporal reprojection in 2007.
 
@@ -33,13 +33,13 @@ Found some of my old blogs: thread looking back an image at a time. 2007, ellips
 
 Branches: [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-i-remember-all-those-fondly-i-also-remembered-the]], [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrianKaris-great-to-see-these-return-still-have-any-of-the]], [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-Karyuutensei-is-the-blog-still-up-somewhere]], [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-BrookeHodgman-i-remember-watching-all-of-these-blog-entries]], [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-oconnorkg-did-you-write-an-engine-called-atom-talked-about]], [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-06-arm1n-thanks-for-digging-those-up-great-stuff-very]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1653558383415271424
 
 2007 particle based fluid sim mixed with spring model, this was 2D to work out ideas for later 3D implementation, rastered particle properties along particle paths into mip tree to enable high-speed collision
 
 ![](https://pbs.twimg.com/media/FvKd2pZWcAArMRq?format=jpg&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1653559205360553985
 
 2007 crazy custom language and live editor for x86-64, color forth is like a virus of the mind, no going back once the understanding is there, and the evolutions of those ideas are ground breaking
 
@@ -47,7 +47,7 @@ Branches: [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blog
 
 Branches: [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blogs-thread-looking-back-an/2023-05-03-won3d-my-former-thesis-advisor-was-a-big-proponent-of]]
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1653561084429713408
 
 2010 digital photography, was compositing exposure brackets to get 16-bit tiffs with good dynamic range and did my own development tools (which had some major flaws I'd only learn about much later in life)
 
@@ -56,51 +56,51 @@ Branches: [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blog
 ![](https://pbs.twimg.com/media/FvKgJSwWIAIUavB?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/FvKgU0NXoAAaXK4?format=jpg&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1653563093106974728
 
 2011 Was using temporal reprojection in my own engines for a while. Posted TSSAA source, an early TAA using viewport jitter for tri raster. I was mostly convinved this was a tech dead end due to the challenges of thin flicker. Decade+ later, and this story has a lot more to it ..
 
 ![](https://pbs.twimg.com/media/FvKhxrpXgAEmVaS?format=png&name=orig)
 ![](https://pbs.twimg.com/media/FvKhzBoXgAABF7I?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1653564005888274432
 
 2011 A simple GIF showing the challenges of {perceptual vs linear} filtering with temporal aliasing high frequency content with {small to large kernel windows}. No negative lobes here.
 
 <video controls src="https://video.twimg.com/tweet_video/FvKi92TWcAA19un.mp4"></video>
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1653564728440942592
 
 2014 simple anti-aliased point based CS rendering engine with fisheye output using stocastic/stratified visiblity and GPU-side scene graph
 
 ![](https://pbs.twimg.com/media/FvKj76BXwAEDBNO?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1653565160605270016
 
 2014 simple non-temporal spatial AA using rotated viewport to provide a good sample distribution with standard non-AA triangle rendering
 
 ![](https://pbs.twimg.com/media/FvKkiT4WAAU2Z3a?format=jpg&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1653566080235761669
 
 2014 monochrome 120 hz laptop ray marcher desiged for VR, fixed cost trace, leaving scene with holes, temporal holefilling reprojection, faked 'lighting' using hierarchical + directional distance probing in lower LOD scene representations, was amazing to just fly around in there
 
 ![](https://pbs.twimg.com/media/FvKk3NoXwAApx-w?format=png&name=orig)
 ![](https://pbs.twimg.com/media/FvKk42ZXoAInjtk?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1653566551818207232
 
 2014 was amazing how nice it was possible to get the geometry even when tracing only 1/8 the screen pixels per frame, stratified sample pattern really does wonders to neighborhood stability, no flicker at all
 
 ![](https://pbs.twimg.com/media/FvKltaSWcAMg5ke?format=jpg&name=orig)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1653566948897062914
 
 2014 still distracted by custom code generation and languages, running stuff on CRTs with custom live editors (color forth like), generating binaries with ELF header generation inside the code itself
 
 ![](https://pbs.twimg.com/media/FvKmJ1aXgAI9Qt9?format=png&name=orig)
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1653567451315986432
 
 2015 some more images inside the live fractal tracer
 
@@ -108,13 +108,13 @@ Branches: [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blog
 ![](https://pbs.twimg.com/media/FvKmtisXsAIC4v-?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/FvKmu0XXsAEP-PW?format=jpg&name=orig)
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1653568279271682052
 
 2015 crazy mini x86 OS project (bootloader source below), using codeless binary editor with annotation. Everyone should try generating binaries with no assembler, learn alot in the process
 
 ![](https://pbs.twimg.com/media/FvKnKcEXoAA-pjq?format=png&name=orig)
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1653569285048918018
 
 2015 live realtime 120+ hz on laptop tracer now with spatial/temporal reconstruction on 1 shaded/sample per ray for 'fake' lit fog, did a lot of z based logic in the spatial/temporal reconstruction, realized later I was relying on the 120 Hz to hide perceptual artifacts
 
@@ -123,14 +123,14 @@ Branches: [[archive/threads/NOTimothyLottes/2023-05-03-found-some-of-my-old-blog
 ![](https://pbs.twimg.com/media/FvKoL0ZXoAAkwWj?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/FvKoNDuXgAAbXBM?format=jpg&name=orig)
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1653570073288757253
 
 2015 still doing the crazy custom languages and tiny OS projects. I feel like there is a real loss in computer evolution, imagine a machine with C64 simplicity that evolved to have a massively parallel vector machine. It would be amazing. It would be approachable by one person.
 
 ![](https://pbs.twimg.com/media/FvKotj4XwAEO-pU?format=png&name=orig)
 ![](https://pbs.twimg.com/media/FvKovAaWcAADk-H?format=png&name=orig)
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1653570742762479620
 
 2015 did some custom CPU-side CRT shader tools for high resolution physical paper prints for someone's book. Wasn't trying to be physically accurate, but rather provide the feeling you'd get from a CRT in paper print form
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-NOTimothyLottes-or-for-an-apu-a-way-to-have-the-storage-device.md b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-NOTimothyLottes-or-for-an-apu-a-way-to-have-the-storage-device.md
index fc1b24e..e0032a7 100644
--- a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-NOTimothyLottes-or-for-an-apu-a-way-to-have-the-storage-device.md
+++ b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-NOTimothyLottes-or-for-an-apu-a-way-to-have-the-storage-device.md
@@ -26,69 +26,69 @@ parent_post_id: "1671276990987370501"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1671279693104914434
 
 Or for an APU, a way to have the storage device write direct to DRAM in pages setup for use on the GPU, because anything the CPU writes that the GPU reads is stuck on the strangled snooping bus or the strangled WC buffer limit on store.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1671288062817517570
 
 If the app tried to manage GPU memory oversubscription via these strangled CPU mappings you'd literally see many second stalls. One can only assume the kernel can do storage<->DRAM DMA for managing GPU DRAM oversubscription?
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1671290467453943810
 
 Even if could fill VRAM in 1 sec, just 2x oversubscription of VRAM implies 1 sec delay to context switch (assuming 2 apps accessing all meM). So classic VM multitasking is useless. Only single app focus model with pinned memory makes any useful sense. Release pin on focus change.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1671291093860728834
 
 The trend is massive res massive VRAM paired with tiny IO bus. So the case for pinned memory and bus master transfers only grows importance as things evolve.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1671343857353515010
 
 Back to SteamDeck numbers: GTT (HOST_VISIBLE) + USWC (non-HOST_CACHED) takes 1 sec for 1st 4 GiB BO alloc, but *30 sec* for 2nd 4 GiB alloc. Kernel driver time for memory allocation (maybe page table related) can be brutal (general comment for PCs too).
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1671345575805984769
 
 Related, I think Chips&Cheese CPU/GPU link DMA and Compute Bandwidths are only measured to a GTT+USWC buffer (only supporting useless uncached CPU reads). Bandwidth exceeds the CPU's bus capacity, implies it is 'garlic' or GPU bus only accesses, direct to DRAM ...
 
 ![](https://pbs.twimg.com/media/FzHOnZ_X0AEW7CE?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1671346590731104257
 
 Since RADV+AMDVLK don't support user-space CPU mapped flush | invalidate, this implies the only supported mapping to read from DRAM direct is USWC (uncached R and write+combine W) ...
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1671347663655018501
 
 Doing GPU stores to a CPU mapped GTT without USWC would be crippingly slow (limited by the snooping bus rate). But this is unfortunately the only option available for CPU read back. So if doing a shader store, it better be only a few waves and running in parallel.
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1671349224871436288
 
 "Use GTT because it's as fast as VRAM on the Deck", could only work if GTT+USWC, as that would be only way to get Garlic (direct to DRAM high bandwidth bus). GTT without USWC would need Onion (slow snooping bus) because AMDgpu's only no-CPU map option is for VRAM!
 
 ![](https://pbs.twimg.com/media/FzHTDxCX0AADoM1?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1671357732413210629
 
 Summary of the theory on best Steam Deck practices. This is the plan for my deck-compute-only driver too. Theory -> as in I haven't yet verified the GPU-side parts (my driver isn't that far along yet).
 
 ![](https://pbs.twimg.com/media/FzHZ_ZiWwAAdEkd?format=png&name=orig)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1671483638435725312
 
 Possible to do better? MAYBE! CPU readback actually has 2 problems, 1st the slow GPU-side copy (4 GiB copy via snooping bus could be almost 4 sec, but direct to DRAM via USWC might be just 160 ms). Also CPU only has 4 MiB of L3, so the majority of 4 GiB will be uncached later ...
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1671484591314464768
 
 Believe UC MTYPE (uncached) forces the CPU into serialized behavior. My test was single thread 8-byte/access reads. https://uops.info/html-instr/VMOVDQA_M256_YMM.html#ZEN2 Looks like Zen2 might be able to get 32-byte/access via VMOVDQA, and going multi-threaded (8 thread), that might be a 32x speed up ..
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1671485760141246464
 
 If so might be able to approach under a GB/s for the CPU-side part (UC multithread via VMOVDQA), which would be close enough to the non-USWC running single threaded using the cache.
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1671486912668880896
 
 What you'd really want here as a band-aid workaround is ability for the GPU to act as if the CPU map was USWC (so go direct to DRAM), but have the CPU map act as non-USWC, so it goes through the cache. Then some kind of hack to flush the tiny 4 MiB L3 and lower caches on the CPU.
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1671500657767903238
 
 CPU readback (reading and summing 8-byte) GTT without USWC:
 
@@ -98,7 +98,7 @@ CPU readback (reading and summing 8-byte) GTT without USWC:
 
 Going multi-core on cached readback doesn't really help much. Proper test, parked threads waiting on futex, signal, last-1st active core timing.
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1671519831424729088
 
 Now CPU readback GTT+USWC
 
@@ -108,11 +108,11 @@ Now CPU readback GTT+USWC
 
 So measurements match theory, going multi-core with MOVNTDQA uncached read on GTT+USWC can be made to match 1 thread GTT (without USWC)
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1671521432495443968
 
 Both those results above had been using a pair of 4 GiB allocations. The GTT+USWC one used one 4 GiB GTT+USWC for timing, and one 4 GiB GTT (unused). And that test suffered from a 30 sec GTT BO allocation. So something was going very wrong in the page mapping ...
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1671523195382374407
 
 When I rerun same test with just one 4 GiB GTT+USWC allocation, the 30 sec stall is gone, and the performance also changes:
 
@@ -122,38 +122,38 @@ Oh!
 
 Perhaps there is some resource limit that kills perf if too much memory gets mapped, page faults?
 
-**19/** @NOTimothyLottes
+**19/** **@NOTimothyLottes** ^1671536279958302720
 
 Top with thread cumulative results doesn't show anything significantly different between the 4 GiB and 8 GiB runs in terms of page faults ... suggests it must be something else
 
 ![](https://pbs.twimg.com/media/FzJ9YrHXsAIfCOg?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/FzJ9Y5LWwAYyyjt?format=jpg&name=orig)
 
-**20/** @NOTimothyLottes
+**20/** **@NOTimothyLottes** ^1671550049359101954
 
 And yet there is obviously a bug in my multi-core tests, you can tell directly from the page fault numbers, only one thread is taking all the faults. So it is back to finding my coding error (fail).
 
-**21/** @NOTimothyLottes
+**21/** **@NOTimothyLottes** ^1671556087479189504
 
 Lunch break and fixed the bug. Two runs now and leaving threads open to get TOP results. First run definitely soaks up the page faults, second run is page fault free (expected). Both around only 7 GB/s.
 
 ![](https://pbs.twimg.com/media/FzKPZxUWABQ6oQJ?format=jpg&name=orig)
 
-**22/** @NOTimothyLottes
+**22/** **@NOTimothyLottes** ^1671557944402378756
 
 And the 8 GiB of BO mapped, but only 4 GiB used run. The first pass gets only 1 GiB/s and the second gets 7 GiB/s. Page fault number is similar to last run, can only conclude page fault costs exploded?
 
 ![](https://pbs.twimg.com/media/FzKRF1OXsAE7c0-?format=jpg&name=orig)
 
-**23/** @NOTimothyLottes
+**23/** **@NOTimothyLottes** ^1671562574859468823
 
 30 sec BO alloc time + super low bandwidth on 1st pass only (where page faults happen) suggest that Linux Kernel logic explodes in cost if too many pages are used in this way ...
 
-**24/** @NOTimothyLottes
+**24/** **@NOTimothyLottes** ^1671563212368519168
 
 ~8K faults for 512 MiB accessed / thread = 64 KiB/fault ... X86-64 has either 4 KiB or 2 MiB for page size. So not using large pages (fail). Probably mapping 16 pages per fault. Not sure if this implies anything about GPU page size (but certainly hoping it isn't 4 KiB, ouch).
 
-**25/** @NOTimothyLottes
+**25/** **@NOTimothyLottes** ^1671563873315323905
 
 Some other very rough measured numbers of GTT+USWC with 8 cores splitting 4 GiB of BO.
 
@@ -163,11 +163,11 @@ Some other very rough measured numbers of GTT+USWC with 8 cores splitting 4 GiB
 
 I think these seem plausable now (so maybe no more code bugs).
 
-**26/** @NOTimothyLottes
+**26/** **@NOTimothyLottes** ^1671564648141684749
 
 One takeaways of all this, is that you need to pre-warm the page tables for large mapped buffers (by touching all pages) when the user isn't waiting on results. And if you are doing batch jobs that {open device, send data to GPU, get data back, close device} you are screwed!
 
-**27/** @NOTimothyLottes
+**27/** **@NOTimothyLottes** ^1671574993581350914
 
 And lastly (maybe) comparison of GTT and GTT+USWC both 8 threads splitting streaming through 4 GiB of mapping (second pass, no page fault issues):
 
@@ -175,61 +175,61 @@ R> ~14 GiB/s (GTT) and ~7 GiB/s (GTT+USWC)
 W+R> ~14 GiB/s (GTT) and ~10 GiB/s (GTT+USWC)
 W> ~13 GiB/s (GTT) and ~15 GiB/s (GTT+USWC)
 
-**28/** @NOTimothyLottes
+**28/** **@NOTimothyLottes** ^1671580078008934402
 
 So an alternative option summary for those who don't want the extra GPU-side GPU to CPU mapped buffer copy step.
 
 ![](https://pbs.twimg.com/media/FzKlE0NXoAI74IA?format=png&name=orig)
 
-**29/** @NOTimothyLottes
+**29/** **@NOTimothyLottes** ^1671841381759832066
 
 If anyone is looking to repro the 30 sec stall: amdgpu_bo_alloc() one 4 GiB GTT+USWC, then one 4 GiB GTT buffer, the second alloc causes the Deck to become unresponsive for 30 seconds
 
-**30/** @NOTimothyLottes
+**30/** **@NOTimothyLottes** ^1671842511826952194
 
 madvise() with MADV_HUGEPAGE on mapped 4 GiB region doesn't do anything (still faults at 64 KiB granularity), and none of these MADV_{WILLNEED|POPULATE_READ|POPULATE_WRITE} have any effect either (still waits until use before faulting, causing low initial effective bandwidth)
 
-**31/** @NOTimothyLottes
+**31/** **@NOTimothyLottes** ^1671846815082094593
 
 64KiB strided write through 4 GiB GTT+USWC (to pre-fault) costs the same as writing full 4 GiB, roughly 3 seconds. So it is quite literally massive page fault overhead for 1st access. No possible workaround found at this time for initial load time problems.
 
-**32/** @NOTimothyLottes
+**32/** **@NOTimothyLottes** ^1671852339399909377
 
 If doing two 4 GiB GTT+USWC allocations, there is also a 30 second BO allocate cost on the 2nd one. And this makes the initial page fault cost for access to the first 4 GiB take another 30 seconds. Effectively hangs the machine for a full minute.
 
-**33/** @NOTimothyLottes
+**33/** **@NOTimothyLottes** ^1671855582632976386
 
 Doing two 4 GiB GTT allocations (without USWC), doesn't incure any of the 30 second stalls. So that problem is specific to big USWC allocations. However the initial access page fault problem (extra 3 seconds) is there, so a 2ndary problem with just mapping lots of APU memory.
 
-**34/** @NOTimothyLottes
+**34/** **@NOTimothyLottes** ^1671863862214250500
 
 Allocation of one 4 GiB GTT first then a 4 GiB GTT+USWC doesn't see the 30 second allocation stall. Almost like anything post a big USWC alloc is poisioned. And after mapping both, then accessing the GTT only, the 30 second time for page faulting comes back.
 
-**35/** @NOTimothyLottes
+**35/** **@NOTimothyLottes** ^1671864699820834821
 
 Continuing from before, even if you don't map the 2nd GTT+USWC, the 30 second initial page faulting time is still there, so the act of mapping doesn't matter, simply doing the BO allocation had already doomed the Linux page management.
 
-**36/** @NOTimothyLottes
+**36/** **@NOTimothyLottes** ^1671868301008314368
 
 Despite header docs which imply flag only works on DOMAIN_VRAM, using DOMAIN_GTT+AMDGPU_GEM_CREATE_NO_CPU_ACCESS is apparently what you want for non-mapped GTT allocations. Mapped 4 GiB GTT with 4 GiB GTT+NO_CPU, drops the initial page fault time from 30 seconds to 3 sec.
 
 ![](https://pbs.twimg.com/media/FzOqwUfXsAEsmC9?format=png&name=orig)
 
-**37/** @DaveAirlie
+**37/** **@DaveAirlie** ^1671288133680529408
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 the problem there is usually tiling, GPUs expect graphicy things in VRAM to be tiled in very specific ways, it's hard to have a storage device do that. Using a transfer engine that can tile/detile makes a lot more sense.
 
-**38/** @NOTimothyLottes
+**38/** **@NOTimothyLottes** ^1671292871440314368
 
-@DaveAirlie
+**@DaveAirlie**
 
 The obvious elephant is an engine using only buffers for resource streaming and doing its own GPU-side decompression. This is practical NOW and portable too. But the lack of a bus master no-CPU direct storage transfer is a serious problem for throughput.
 
-**39/** @NOTimothyLottes
+**39/** **@NOTimothyLottes** ^1671301204176146432
 
-@DaveAirlie
+**@DaveAirlie**
 
 See raw texture streaming (even with lossless compression) is way less interesting now given modern massive data tech direction, u want substantially better lossy compression simply to fit in launch constraints. So really, buffers are the way to go anyway :)
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-SheriefFYI-great-thread.md b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-SheriefFYI-great-thread.md
index f23332d..6763119 100644
--- a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-SheriefFYI-great-thread.md
+++ b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-SheriefFYI-great-thread.md
@@ -26,9 +26,9 @@ parent_post_id: "1671276990987370501"
 
 ## Branch
 
-**1/** @SheriefFYI
+**1/** **@SheriefFYI** ^1671279374622924802
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Great thread!
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-never_released-on-linux-nvidia-has-a-very-good-uvm-however-the.md b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-never_released-on-linux-nvidia-has-a-very-good-uvm-however-the.md
index 2f18727..c2ce29a 100644
--- a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-never_released-on-linux-nvidia-has-a-very-good-uvm-however-the.md
+++ b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/2023-06-20-never_released-on-linux-nvidia-has-a-very-good-uvm-however-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1671276990987370501"
 
 ## Branch
 
-**1/** @never_released
+**1/** **@never_released** ^1671278880219447298
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 On Linux, NVIDIA has a very good UVM.
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/index.md b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/index.md
index cec7597..334e7ce 100644
--- a/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/index.md
+++ b/archive/threads/NOTimothyLottes/2023-06-20-how-about-a-mega-thread-on-the-mechanics-of-cpu/index.md
@@ -25,55 +25,55 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1671264312516829184
 
 How about a mega thread on the mechanics of CPU/GPU communication. Using AMDgpu based timing  results on the SteamDeck an example, but relating to the larger picture of PC GFX APIs like Vulkan/etc. I don't claim to know all, so experts feel free to add your wisdom :)
 
 ![](https://pbs.twimg.com/media/FzGF4owWwAMsc2I?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1671266934980063239
 
 Both RADV and AMDVLK: Flush/invalidate mapped memory ranges is a NOP. So bus-crossing dGPU traffic to HOST_VISIBLE is automatically snooping CPU caches. The one without HOST_CACHED, is Write+Combined [WC] on store, and Uncached [UC] on read.  The one with HOST_CACHED is non-WC/UC
 
 ![](https://pbs.twimg.com/media/FzGG4OnWwAEu19H?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1671268879484571649
 
 In AMDgpu (the kernel driver), likely DEVICE_LOCAL maps to AMDGPU_GEM_DOMAIN_VRAM (also the carve out on APUs) and the non-DEVICE_LOCAL maps to AMDGPU_GEM_DOMAIN_GTT
 
 ![](https://pbs.twimg.com/media/FzGJkkFWwAEBowR?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1671269986588041216
 
 AMD+RADV added {DEVICE_COHERENT_BIT_AMD,
 DEVICE_UNCACHED_BIT_AMD} variations to the core 4 memory types. Likely to support GPU crash debug. But also provides a way to avoid needing to write-back (flush) GPU caches before CPU read. Likely AMDgpu kernel flag mapping below.
 
 ![](https://pbs.twimg.com/media/FzGKZ_bWcAE3cGh?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1671271559636426754
 
 This AMDGPU_GEM_CREATE_CPU_GTT_USWC appear to toggle on WriteCombine [WC] for CPU store, and Uncached [US] for CPU reads (cases of HOST_VISIBLE without HOST_CACHED)
 
 ![](https://pbs.twimg.com/media/FzGL03LXgAEeO0K?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1671273600974766081
 
 For review from https://chipsandcheese.com/2023/03/05/van-gogh-amds-steam-deck-apu/ Deck bandwidths: ~71 GB/s GPU, ~43 GB/s DMA, ~34 GB/s shader copy CPU<->GPU, ~25 GB/s CPU/CPU, and damn, brutal 0.27 GB/s CPU mapped GPU buffer reads, 0.71 GB/s CPU mapped GPU buffer writes
 
 ![](https://pbs.twimg.com/media/FzGNGBuWAAA6wlr?format=png&name=orig)
 ![](https://pbs.twimg.com/media/FzGNlFvWwAANhH4?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1671275003499757575
 
 And going direct to AMDgpu instead of VK on the Deck shows these kinds of bandwidths (non-DEVICE_LOCAL,  HOST_VISIBLE with HOST_CACHED and without). So using Write-Combined is amazingly painful for stores.
 
 ![](https://pbs.twimg.com/media/FzGO3XdWIAAQl3V?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1671275745283301376
 
 Implies that the choices one might make on dGPU PC don't necessarily port over to APUs at all. Another challenge: it takes almost 7 seconds to zero-fill using a 64-bit store for() loop the 8-GiB of mapped memory. Hints at why load times are such a challenge even in the best case.
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1671276990987370501
 
 This all hints at why PC OS derived systems are lacking in stuffing GPU VRAM. Really need some kind of bus mastered DMA (zero-copy) between non-volatile storage (disk) and GPU DRAM to avoid this CPU-touching performance tax.
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-SebAaltonen-would-be-nice-to-talk-a-full-presentation-about.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-SebAaltonen-would-be-nice-to-talk-a-full-presentation-about.md
index 5135c75..e360de3 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-SebAaltonen-would-be-nice-to-talk-a-full-presentation-about.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-SebAaltonen-would-be-nice-to-talk-a-full-presentation-about.md
@@ -26,17 +26,17 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1674768757867020289
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Would be nice to talk a full presentation about this topic, but people want me to show cool tech and pretty pixels instead. Maybe one day.
 
 I will save your image for that day (if I get approval to use it), since Twitter search is super bad.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1674776150671781888
 
-@SebAaltonen
+**@SebAaltonen**
 
 "Approval", haha, sure it's covered under my favorite license
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-_spolsh-once-in-a-while-people-need-to-be-reminded-to.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-_spolsh-once-in-a-while-people-need-to-be-reminded-to.md
index e51e968..f480240 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-_spolsh-once-in-a-while-people-need-to-be-reminded-to.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-_spolsh-once-in-a-while-people-need-to-be-reminded-to.md
@@ -26,16 +26,16 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @_spolsh
+**1/** **@_spolsh** ^1674839597853835285
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Once in a while people need to be reminded to stop the bloat, understand the machine guts and be self aware about productive process
 https://tonsky.me/blog/disenchantment/
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1674886711707418624
 
-@_spolsh
+**@_spolsh**
 
 That was a fantastic read, thanks
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-domipheus-i-like-this-given-i-never-write-code-any-more.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-domipheus-i-like-this-given-i-never-write-code-any-more.md
index 04139a6..8d14d8f 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-domipheus-i-like-this-given-i-never-write-code-any-more.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-domipheus-i-like-this-given-i-never-write-code-any-more.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @domipheus
+**1/** **@domipheus** ^1674777379414179840
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I like this, given I never write code any more.
 sadly i am still a grumpy git.
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-leonard_coder-4e71-if-you-know-you-know.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-leonard_coder-4e71-if-you-know-you-know.md
index d9dfd4a..4dafcb7 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-leonard_coder-4e71-if-you-know-you-know.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-06-30-leonard_coder-4e71-if-you-know-you-know.md
@@ -26,16 +26,16 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @leonard_coder
+**1/** **@leonard_coder** ^1674771452799614976
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 $4e71
 if you know, you know
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1674774881093689346
 
-@leonard_coder
+**@leonard_coder**
 
 ${EA, 1A, 3A, 5A, 7A, DA, or FA}
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-CodingFiend-i-designed-a-language-beads-which-uses-a-graph-db.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-CodingFiend-i-designed-a-language-beads-which-uses-a-graph-db.md
index cba521c..52766f7 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-CodingFiend-i-designed-a-language-beads-which-uses-a-graph-db.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-CodingFiend-i-designed-a-language-beads-which-uses-a-graph-db.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @CodingFiend
+**1/** **@CodingFiend** ^1675149939759017987
 
-@NOTimothyLottes @Jonathan_Blow
+**@NOTimothyLottes** **@Jonathan_Blow**
 
 i designed a language Beads, which uses a graph DB, has no memory allocation, super modular, approaches this minimalism as close as humanly possible, but billable hour / job security seeking programmers refuse to try it
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-DefenceForceOrg-many-games-used-to-be-like-that-at-least-the-ones.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-DefenceForceOrg-many-games-used-to-be-like-that-at-least-the-ones.md
index d5ef8fd..0c2a5ef 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-DefenceForceOrg-many-games-used-to-be-like-that-at-least-the-ones.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-DefenceForceOrg-many-games-used-to-be-like-that-at-least-the-ones.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @DefenceForceOrg
+**1/** **@DefenceForceOrg** ^1675059402280251395
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Many games used to be like that, at least the ones without dynamic content, mods, etc...
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-PierreTerdiman-i-was-calling-it-disoriented-programming-just-the.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-PierreTerdiman-i-was-calling-it-disoriented-programming-just-the.md
index c077d0a..d6b82db 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-PierreTerdiman-i-was-calling-it-disoriented-programming-just-the.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-PierreTerdiman-i-was-calling-it-disoriented-programming-just-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @PierreTerdiman
+**1/** **@PierreTerdiman** ^1675088736621559808
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I was calling it "disoriented programming" just the other day.
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-SimonNordon-nop-is-ideal.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-SimonNordon-nop-is-ideal.md
index 9036d56..4ab06ca 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-SimonNordon-nop-is-ideal.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-SimonNordon-nop-is-ideal.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @SimonNordon
+**1/** **@SimonNordon** ^1674970938234875907
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 NOP is ideal.
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-TimSweeneyEpic-can-teach-it-in-abstinence-only-programming.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-TimSweeneyEpic-can-teach-it-in-abstinence-only-programming.md
index 7ce0395..da8f5f0 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-TimSweeneyEpic-can-teach-it-in-abstinence-only-programming.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-TimSweeneyEpic-can-teach-it-in-abstinence-only-programming.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @TimSweeneyEpic
+**1/** **@TimSweeneyEpic** ^1675248176498987009
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Can teach it in abstinence-only programming classes!
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-asparagiii-looks-like-a-koala.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-asparagiii-looks-like-a-koala.md
index 66631cf..23dbde5 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-asparagiii-looks-like-a-koala.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-asparagiii-looks-like-a-koala.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @asparagiii
+**1/** **@asparagiii** ^1675123653162196992
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Looks like a koala
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-azeke1984-best-software-is-absense-of-it-https-en-wikipedia.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-azeke1984-best-software-is-absense-of-it-https-en-wikipedia.md
index 6929677..43bc7c7 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-azeke1984-best-software-is-absense-of-it-https-en-wikipedia.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-azeke1984-best-software-is-absense-of-it-https-en-wikipedia.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @azeke1984
+**1/** **@azeke1984** ^1674996094265163782
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Best software is absense of it:
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-claudiogonzalo-c-to-c.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-claudiogonzalo-c-to-c.md
index eb26b37..1f895e6 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-claudiogonzalo-c-to-c.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-claudiogonzalo-c-to-c.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @claudiogonzalo
+**1/** **@claudiogonzalo** ^1675054802265423872
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 c++ to √c
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-helpful_signage-folks-theyre-calling-it-computer-oriented.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-helpful_signage-folks-theyre-calling-it-computer-oriented.md
index ead010c..99d6de7 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-helpful_signage-folks-theyre-calling-it-computer-oriented.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-helpful_signage-folks-theyre-calling-it-computer-oriented.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @helpful_signage
+**1/** **@helpful_signage** ^1675020853862359041
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Folks, they're calling it "computer oriented programming". It's where you stop trying to impress peers and just tell the computer the best way to do things
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-mike_acton-thread.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-mike_acton-thread.md
index 0101be7..1758cc0 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-mike_acton-thread.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-01-mike_acton-thread.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @mike_acton
+**1/** **@mike_acton** ^1674962613506297857
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 ![](https://pbs.twimg.com/media/Fz6pnsBaQAEtMIZ?format=jpg&name=orig)
 ## Related
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-09-wyattscarpenter-https-github-com-wyattscarpenter-wu.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-09-wyattscarpenter-https-github-com-wyattscarpenter-wu.md
index 7c753ca..9e7cf2b 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-09-wyattscarpenter-https-github-com-wyattscarpenter-wu.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/2023-07-09-wyattscarpenter-https-github-com-wyattscarpenter-wu.md
@@ -26,9 +26,9 @@ parent_post_id: "1674757854471806977"
 
 ## Branch
 
-**1/** @wyattscarpenter
+**1/** **@wyattscarpenter** ^1678087686404595712
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 https://github.com/wyattscarpenter/wu
 
diff --git a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/index.md b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/index.md
index da2b862..760d6c9 100644
--- a/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/index.md
+++ b/archive/threads/NOTimothyLottes/2023-06-30-nothing-oriented-programming-nop/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1674757854471806977
 
 "Nothing Oriented Programming" (NOP). Where the goal is to achieve minimal enlightenment by writing as little possible code: no dynamic memory allocation, no thousand files of glue, no includes, no objects. Write nothing, be happy. Even applied it to the logo, zero effort.
 
diff --git a/archive/threads/NOTimothyLottes/2023-08-03-spc-left-off-with-key-and-gamepad-input-gpu/index.md b/archive/threads/NOTimothyLottes/2023-08-03-spc-left-off-with-key-and-gamepad-input-gpu/index.md
index 4b75fb9..1fc4951 100644
--- a/archive/threads/NOTimothyLottes/2023-08-03-spc-left-off-with-key-and-gamepad-input-gpu/index.md
+++ b/archive/threads/NOTimothyLottes/2023-08-03-spc-left-off-with-key-and-gamepad-input-gpu/index.md
@@ -25,38 +25,38 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1687250591813079041
 
 SPC: Left off with KEY and GAMEPAD input GPU-accessable. NOP design, no functions, no API, just a fixed VA address and data format to read, dead easy.
 
 ![](https://pbs.twimg.com/media/F2pRdu9WgAABCLE?format=jpg&name=orig)
 
 ![](https://pbs.twimg.com/media/F2pReKsXoAAPvow?format=jpg&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1687251721032978432
 
 Wrote some console data dumping to aid in bringing up HID parsers for Deck and three generations of PlayStation controllers. Apparently XBox controllers aren't HIDs so not sure how one is supposed to access those.
 
 ![](https://pbs.twimg.com/media/F2pSfIHXcAMI-IQ?format=jpg&name=orig)
 
 ![](https://pbs.twimg.com/media/F2pSfzAWcAMo6t7?format=jpg&name=orig)
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1687252813468852225
 
 Supporting hot plug was a bit of a mess, just trying to open devices every second. Adding open devices to an epoll. {Product, vendor} isn't enough to ID a device, too much aliasing, so I use packet size as well.
 
 ![](https://pbs.twimg.com/media/F2pTfekWYAAAwSi?format=jpg&name=orig)
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1687253442643755008
 
 Open devices with matching packet size get set in a bit array, and I collect up to 4 of those device outputs to sent to the GPU. Special logic to always place Steam Deck controls last to make docking work well.
 
 ![](https://pbs.twimg.com/media/F2pUEG0XwAEwYvP?format=jpg&name=orig)
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1687254511239221249
 
 I'll have to tackle audio at some point, but I'm skipping networking for version 1. But otherwise SPC is good to move on to the next step, which is to build out the GPU side assembler & data editor. Which will be written in binary at first.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1687255546372493313
 
 Project is roughly 2000 lines of C at this point. With no includes. Anyone have any suggestions for hosting let me know. Source will be released.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1687257354490818561
 
 For anyone tuning in now, SPC is kind of like a Pico8, but instead of being a portable fantasy console, SPC turns the Steam Deck into an actual console for exclusive GPU assembly projects. The way consoles had been done before silly portability became the only focus.
diff --git a/archive/threads/NOTimothyLottes/2023-08-03-spc-using-8-deep-swap-all-aliasing-same-bo-image/index.md b/archive/threads/NOTimothyLottes/2023-08-03-spc-using-8-deep-swap-all-aliasing-same-bo-image/index.md
index c040578..c6a9707 100644
--- a/archive/threads/NOTimothyLottes/2023-08-03-spc-using-8-deep-swap-all-aliasing-same-bo-image/index.md
+++ b/archive/threads/NOTimothyLottes/2023-08-03-spc-using-8-deep-swap-all-aliasing-same-bo-image/index.md
@@ -25,26 +25,26 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1687062786273062912
 
 SPC: Using 8 deep swap all aliasing same BO (image) fixes Game Mode crash with external display. Pipelined load gets to black screen in 2 ms. Takes 460 ms to allocate 4 GiB GTT video ram, 558 ms to copy 256 MiB cart from page cache to USWC (page faults), all in parallel.
 
 ![](https://pbs.twimg.com/media/F2mmqYXWoAAG3fj?format=jpg&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1687065863512285185
 
 Clearing page cache to simulate a cold launch: Takes 1.5 sec to read 256 MiB from the stock SSD. This is worst case load time in desktop mode. Won't be any compile/etc after this. So literally in game at this point. Speed of light. This is how it is done.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1687066126268674048
 
 Forgot the timing capture ... Load from SSD.
 
 ![](https://pbs.twimg.com/media/F2mpszoXMAE00Hy?format=jpg&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1687068433584738304
 
 There are only 3 threads on load: (1.) to open X11 then spin doing present/keyboard, (2.) to open the AMDgpu device, SDMA copy after CART read, and then eventually spin doing dispatchs, (3.) one to load the CART from disk to mapped USWC GTT via read().
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1687069108355866625
 
 Something I don't know: does read() since it's kernel- side automatically get some multi-core parallelism? Not a good idea to manually thread the read() because SSD needs linear reads to be fast. Not possible to know if the reads are page cache hits in advance either ...
diff --git a/archive/threads/NOTimothyLottes/2023-08-06-1st-spc-project-to-be-based-on-vintage-640x480/index.md b/archive/threads/NOTimothyLottes/2023-08-06-1st-spc-project-to-be-based-on-vintage-640x480/index.md
index e7b7801..ab30777 100644
--- a/archive/threads/NOTimothyLottes/2023-08-06-1st-spc-project-to-be-based-on-vintage-640x480/index.md
+++ b/archive/threads/NOTimothyLottes/2023-08-06-1st-spc-project-to-be-based-on-vintage-640x480/index.md
@@ -25,22 +25,22 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1688018382543597568
 
 1st SPC project: to be based on vintage 640x480 render (VGA style), +fallback to 640x240 for 15 KHz arcade CRTs (PGM-esk), and CRT shader scaling on Deck and OLED/LCD. Use mix of render pixel aspect changes, running less than 480 lines, and letter-box to keep integer Y scaling.
 
 ![](https://pbs.twimg.com/media/F20LgFtWQAAMtcv?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1688019698904969216
 
 My 15 KHz CRT output path when docked is HD Fury Nano (won't do <480p) doing HDMI to VGA, with a sync combiner (to workaround GBS-C bug), into GBS-C which line drops 480p ~60Hz to 240p ~60Hz and outputs component. The 640 width gets maintained even if some CRTs cannot resolve it.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1688021533904510976
 
 Presents issues for UI, namely that my bitmap fonts need to look good in both 480p and 240p modes, so for editor (assembler) I'm going with a font that uses right angles and designed around 2x2 stroke width, in a 8x16 (pow2) bitmap, so 640x240p still gets a readable 8x8 (below)
 
 ![](https://pbs.twimg.com/media/F20Ogh8XoAAq7hR?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1688022114962374656
 
 The next challenge is overscan safety, since real non-VGA CRTs will be used in development. The Y axis has an easy fix, simply keep cursor pinned in the 'safe' zone, but still print lines in the overscan area (so they can be seen when attached to non-overscan CRTs/etc too).
diff --git a/archive/threads/NOTimothyLottes/2023-08-06-spc-rdna2-assembler-thread/index.md b/archive/threads/NOTimothyLottes/2023-08-06-spc-rdna2-assembler-thread/index.md
index 35fb116..12827c9 100644
--- a/archive/threads/NOTimothyLottes/2023-08-06-spc-rdna2-assembler-thread/index.md
+++ b/archive/threads/NOTimothyLottes/2023-08-06-spc-rdna2-assembler-thread/index.md
@@ -25,75 +25,75 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1688275737692815360
 
 SPC: RDNA2 ASSEMBLER [thread] ... Did initial design plan this weekend. The aim is a GPU-side assembler+editor, building RDNA2 binary images for Steam Deck. Live edit, live data view, etc. Assembler and editor running in massive vectorized shader code.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1688276271619248129
 
 Good reason not to use text input for assembler, instead will use a custom binary format, and treat all 32-bit words in the binary the exact same way (so massively parallel assembly step). This is parallel design 101.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1688277538571755520
 
 Some basics: RDNA2 instructions are 1-N 32-bit words. Each of the 32-bit components have a bunch of fields. Will typically need 1-6 fields per 32-bit word, as will be joining some fields into one argument (like DLC/GLC) below.
 
 ![](https://pbs.twimg.com/media/F232wWkX0AAZWPh?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/F233F_sWMAAqHBo?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1688278083684421632
 
 Could argue that MIMG has the most fields, but in practice many of those fields will be joined (see example), and I'm not likely to be using NSA encoding. So still will only need maximum 6 arguments to build a 32-bit value.
 
 ![](https://pbs.twimg.com/media/F233qJyWQAAjmOo?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/F2333WKXEAAc2fZ?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1688278959711272960
 
 Custom editor, using a custom font, designed for vintage CRTs. Wanted 5-character symbol names for easy packing in 30-bit values. So setup a 6-bit character table. This is using a modified 'right-angle-only' font (like the one below). So some glyphs alias, and only upper case.
 
 ![](https://pbs.twimg.com/media/F234Y1IXcAECWTB?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1688280670764756992
 
 Will need some kind of symbol table, what ends up providing the arguments to the rules that build the 32-bit words that comprise the final binary. The symbol indirection provides a way to name registers for example, and then change the register mapping later.
 
 ![](https://pbs.twimg.com/media/F2357mwXUAAC6O6?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1688281231954161664
 
 Notice SMEM ops have 21-bit immediate offsets. I'll use 20-bits of that for an absolute positive offset from KART base. 1 MiB of easy data. The editor will relink tagged symbols that represent offsets automatically.
 
 ![](https://pbs.twimg.com/media/F236eA_XkAAc8-_?format=jpg&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1688281975210041344
 
 Next will need a collection of rules, how to join the 6 possible symbol arguments together. Rules for example for each of the RDNA2 instruction encodings (VOPC, etc). This reduces to just a 6 entry 5-bit left shift amount associated with each argument.
 
 ![](https://pbs.twimg.com/media/F237AEiWgAAkzD0?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1688282613914492928
 
 But will need a 7th argument, hard coded to a signed 16-bit *4 relative offset as this is how RDNA2 does all it's relative branches. This will be setup inside the editor to auto relink as source is edited.
 
 ![](https://pbs.twimg.com/media/F237uqaXAAAKAFl?format=jpg&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1688283094049021952
 
 Source then is simple, two 128-bit values per 32-bit word in the binary. One to select {RULE, SYMBOLS, RELATIVE BRANCH}, and another for {LABEL, COMMENT}.
 
 ![](https://pbs.twimg.com/media/F238Q-zXYAAO1Eo?format=png&name=orig)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1688284090129084417
 
 And then the source editor, shows a line per 32-bit value (so VOP3's for example would take 2 lines). So the 'assembler' is deceptively simple, but powerful enough to do everything required to generate GPU binary code. And all the opcode generation is in the data itself :)
 
 ![](https://pbs.twimg.com/media/F238wJ8WoAAtEfw?format=png&name=orig)
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1688284962288537600
 
 The editor itself will have 3 views {symbol table, rule table, source table}. The editor itself will use 2 copies of everything, so each edit, it's one entry/lane, reading prior state and updating to the new. Dead simple, dead parallel (not necessarily efficient) :)
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1688286623375454208
 
 Yeah, perhaps wildly alien. But for those who grew up with MOD-like trackers (like Impulse Tracker below), the interface will almost feel like home (those had simple {instrument, pattern, arangement} editors, with a very spreadsheet feel).
 
diff --git a/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/2023-08-10-BlurBusters-very-interesting-crosstalk-from-voltage-inversion.md b/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/2023-08-10-BlurBusters-very-interesting-crosstalk-from-voltage-inversion.md
index bbdfba9..68cf580 100644
--- a/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/2023-08-10-BlurBusters-very-interesting-crosstalk-from-voltage-inversion.md
+++ b/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/2023-08-10-BlurBusters-very-interesting-crosstalk-from-voltage-inversion.md
@@ -26,45 +26,45 @@ parent_post_id: "1688491417109196800"
 
 ## Branch
 
-**1/** @BlurBusters
+**1/** **@BlurBusters** ^1689479056448684032
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Very interesting "crosstalk from voltage inversion" artifact. Some repeating patterns or flicker patterns can trigger crosstalk artifacts too. Behavior varies a lot between TN, IPS, and VA, but all of them have to alternate voltage polarity spatially and temporally.
 
 ![](https://pbs.twimg.com/media/F3I8AZmW0AEy6jn?format=png&name=orig)
 ![](https://pbs.twimg.com/media/F3I8BVlXoAAnuJB?format=png&name=orig)
 
-**2/** @BlurBusters
+**2/** **@BlurBusters** ^1689480058950356993
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Related reads:
 https://www.lagom.nl/lcd-test/inversion.php
 https://forums.blurbusters.com/viewtopic.php?t=7539
 http://www.techmind.org/lcd/#:~:text=Inversion
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1689625885958127616
 
-@BlurBusters
+**@BlurBusters**
 
 I appreciate the links. Came to the same conclusion, for LCDs when doing low scaling like 1:2x2 'CRT' emulation, I'll have to do a stylized blue noise phosphor pattern instead.
 
-**4/** @Ak4115x
+**4/** **@Ak4115x** ^1689773902241599488
 
-@NOTimothyLottes @BlurBusters
+**@NOTimothyLottes** **@BlurBusters**
 
 "VCOM inversion" -if wasn't line2line but frame2frame that'd "flicker" instead at half the refresh rate so that's why it's preferred& there's also another peculiarity of this scheme. Worth looking into, spent a few hours afternoon,it's late evening now maybe share another time.
 
-**5/** @BlurBusters
+**5/** **@BlurBusters** ^1689815188025839616
 
-@Ak4115x @NOTimothyLottes
+**@Ak4115x** **@NOTimothyLottes**
 
 Inversion algorithm is both spatial and temporal on all of them, regardless of spatial pattern of voltage inversion. Line to line is also frame to frame. (lines swaps voltage polarity in next frame)
 
-**6/** @Ak4115x
+**6/** **@Ak4115x** ^1689817477029535744
 
-@BlurBusters @NOTimothyLottes
+**@BlurBusters** **@NOTimothyLottes**
 
 LCOS has singular VCOM there's no pattern to it and no such artifact.
 
diff --git a/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/index.md b/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/index.md
index 3d45731..ab545da 100644
--- a/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/index.md
+++ b/archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1688491417109196800
 
 CRT emulation on LCDs can be hard. For example it's often easy to generate a pattern that causes a LCD hardware bug. NOT joking. Here is an example on the Steam Deck. The pattern in the window affects the scan (Deck scan is rotated) outside the window.
 
@@ -34,22 +34,22 @@ CRT emulation on LCDs can be hard. For example it's often easy to generate a pat
 
 Branches: [[archive/threads/NOTimothyLottes/2023-08-07-crt-emulation-on-lcds-can-be-hard/2023-08-10-BlurBusters-very-interesting-crosstalk-from-voltage-inversion]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1688492237775142912
 
 The actual pattern is this (it's a 2x1 pixel checker of {G,RB}).
 
 ![](https://pbs.twimg.com/media/F266epnW4AAdCiK?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1688493686554849280
 
 The theory: Deck's 90deg scan results in {(bottom)R, G, B (top)} sub-pixel components. So could alternate {G,RB} only per pixel in a checker pattern to generate a new sub-pixel pattern at a different resolution. In this case trying for 640x400 virtual resolution.
 
 ![](https://pbs.twimg.com/media/F267UYuXAAAO50A?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1688494811366506496
 
 For virtual pixel, shift energy into masked virtual phosphor. So 50% brightness red, would be {100%, 0%} for {in, out} of phosphor pixels. Over 50% one starts to increase non-phosphor pixels until some maximum so mask is still visible, but brightness isn't too compromised.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1688496100460605442
 
 Of course this is done in linear, so it's energy conserving in theory. But when the panel fails, it breaks down and doesn't work. I see this problem on a bunch of different devices. My personal AMD laptop has the exact same fail case (but rotated differently).
diff --git a/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/2023-08-18-tomcr2100-i-am-not-quite-sure-what-do-you-mean-by-subpixel.md b/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/2023-08-18-tomcr2100-i-am-not-quite-sure-what-do-you-mean-by-subpixel.md
index 1ecf8db..fb54268 100644
--- a/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/2023-08-18-tomcr2100-i-am-not-quite-sure-what-do-you-mean-by-subpixel.md
+++ b/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/2023-08-18-tomcr2100-i-am-not-quite-sure-what-do-you-mean-by-subpixel.md
@@ -26,21 +26,21 @@ parent_post_id: "1692560907988029769"
 
 ## Branch
 
-**1/** @tomcr2100
+**1/** **@tomcr2100** ^1692650176102449532
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 i am not quite sure what do you mean by subpixel scan? do you override the normal (refresh) scanout process?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1692659851925606495
 
-@tomcr2100
+**@tomcr2100**
 
 It's like "clear-type" font rendering where if you know the LCD sub-pixel configuration for the RGB components of a pixel, you can do a much better job of computing and outputing the value at the specific RGB sub-pixel element. So i'm doing this for CRT-like emulation on the Deck
 
-**3/** @tomcr2100
+**3/** **@tomcr2100** ^1692681369602679237
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 just curious, i started doing something similar, but this year i have focused more on rest&recover. i went with a trilinear style aperture grill approximation, and just allow prim components to leak into the two others.
 
diff --git a/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/index.md b/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/index.md
index 62e23b4..e5ba4ef 100644
--- a/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/index.md
+++ b/archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/index.md
@@ -25,14 +25,14 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1692559239116406864
 
 SPC: CRT shader on the Deck. This time not doing subpix render. Yet RGB vs BGR order matters still. One way it becomes possible to simulate even spaced aperture grill (removing scan fx), and the other more of the scan effect.
 
 ![](https://pbs.twimg.com/media/F30tppDWwAAA-8J?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/F30tqE8XYAAgrFv?format=jpg&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1692559798254858259
 
 Comparing all methods (grille, bad convergence scan, subpix scan)
 
@@ -40,13 +40,13 @@ Comparing all methods (grille, bad convergence scan, subpix scan)
 ![](https://pbs.twimg.com/media/F30uKJdXkAA4PV8?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/F30uKouWQAAvY0q?format=jpg&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1692560907988029769
 
 The non-subpix scan has 1-pixel separation of RGB (intentional bad convergence) to help hide scaling. The subpix scan uses 1/3-pixel separation (less visible misaligned convergence). Pixel as in output pixel.
 
 Branches: [[archive/threads/NOTimothyLottes/2023-08-18-spc-crt-shader-on-the-deck/2023-08-18-tomcr2100-i-am-not-quite-sure-what-do-you-mean-by-subpixel]]
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1692565070583136348
 
 The subpix version is definitely better. Because of the almost 3x doubling of scanline width detail, it just perceptually feels a lot cleaner and easier to reconstruct in the mind.
 
diff --git a/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/2023-08-18-Karyuutensei-how-many-passes-do-you-need-to-produce-this-result.md b/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/2023-08-18-Karyuutensei-how-many-passes-do-you-need-to-produce-this-result.md
index d53f280..0138344 100644
--- a/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/2023-08-18-Karyuutensei-how-many-passes-do-you-need-to-produce-this-result.md
+++ b/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/2023-08-18-Karyuutensei-how-many-passes-do-you-need-to-produce-this-result.md
@@ -26,15 +26,15 @@ parent_post_id: "1692397318471926054"
 
 ## Branch
 
-**1/** @Karyuutensei
+**1/** **@Karyuutensei** ^1692558954935550353
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 How many passes do you need to produce this result?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1692566718307021059
 
-@Karyuutensei
+**@Karyuutensei**
 
 1 pass: 12 fetches/outpix, in 2 batches. I use 6 gather4's to grab a 4-wide(x)2-line region for the {R,G,B} channels. Then 6 more fetches to do energy conserving computation of output for each {nearest 2 lines}x{R,G,B} channel based {intensity, position vertically on scan}.
 
diff --git a/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/index.md b/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/index.md
index d4b11dd..f942966 100644
--- a/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/index.md
+++ b/archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1692395128739057844
 
 SPC: Last CRT shader was broken. Corrected it. It's energy conserving now, and correctly doing sub-pixel line width raster using the individual channels. Cell camera  shots below at different zooms.
 
@@ -33,16 +33,16 @@ SPC: Last CRT shader was broken. Corrected it. It's energy conserving now, and c
 ![](https://pbs.twimg.com/media/F3yYZQwXcAABFvi?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/F3yYZo5WAAA0aRS?format=jpg&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1692396538629095592
 
 Each scan line is simulated with only 3 pixels. But you get 9 sub-pixels to play with, so that is where the quality comes from. It reaches 7/8th of the display peak brightness, this compromise was so there is always some amount of perceptual scan effect.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1692397318471926054
 
 The scan line thickness is adaptive proportional to linear brightness. When the scan thins out it is energy conserving and increases the thin pixel brightness to compensate. When it needs to go bright, it blooms the line. Lines have some overlap in bloom.
 
 Branches: [[archive/threads/NOTimothyLottes/2023-08-18-spc-last-crt-shader-was-broken/2023-08-18-Karyuutensei-how-many-passes-do-you-need-to-produce-this-result]]
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1692397964151378028
 
 One human perceptual reason CRTs feel like they have more contrast than they do, is because an individual scan line is super bright when in focus. So the black surround feels darker to the mind.
diff --git a/archive/threads/NOTimothyLottes/2023-12-15-long-thread/2023-12-15-SebAaltonen-they-design-one-api-for-each-separate-use-case.md b/archive/threads/NOTimothyLottes/2023-12-15-long-thread/2023-12-15-SebAaltonen-they-design-one-api-for-each-separate-use-case.md
index 2f9d810..ebd04ac 100644
--- a/archive/threads/NOTimothyLottes/2023-12-15-long-thread/2023-12-15-SebAaltonen-they-design-one-api-for-each-separate-use-case.md
+++ b/archive/threads/NOTimothyLottes/2023-12-15-long-thread/2023-12-15-SebAaltonen-they-design-one-api-for-each-separate-use-case.md
@@ -26,15 +26,15 @@ parent_post_id: "1735631826427732305"
 
 ## Branch
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1735671969947803827
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 They design one API for each separate use case instead of making general purpose flexible SIMD hardware and API for the developers to implement what ever algorithm they need. CPU side got this right. PS2 had correct design, but Nvidia choose hardware T&L for desktop :(
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1735672402992943607
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I kind of understand hardware T&L back then because it was a new field and programmable hardware didn't exist. But now we have massive amount of wide SIMDs and bandwidth and big caches too. We can do better!
 
diff --git a/archive/threads/NOTimothyLottes/2023-12-15-long-thread/index.md b/archive/threads/NOTimothyLottes/2023-12-15-long-thread/index.md
index 962bd74..477aa3d 100644
--- a/archive/threads/NOTimothyLottes/2023-12-15-long-thread/index.md
+++ b/archive/threads/NOTimothyLottes/2023-12-15-long-thread/index.md
@@ -25,106 +25,106 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1735622924571201674
 
 <long thread> 
 Holiday GPU thoughts as a recovering pc/mobile/etc cross platform dev-holic ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1735623225860583609
 
 [0] Early STP prototypes: had standard-PC-practice multi-dispatch 32-bit version, and hyper-optimized packed-16-bit semi-persistent single-dispatch-ubershader that got L2 reuse. Optimized one was 40% faster in profiling (VK RNDA2 GPU)! Industry has huge untapped opt potential
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1735623600344813976
 
 [1] Even for PC, 16-bit is required for optimization because: almost double the amount of register state a shader can leverage. Holds true even when platform lacks double rate 16-bit. Top optimization is pass merging, PC went bandwidth starved. Mobile is actually ALU starved ...
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1735623707001753932
 
 [2] Double rate 16-bit done right, is typically good for the smaller of {30% perf, return to non-ALU bound}, can make a GPU feel at least one HW generation faster.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1735623832549916904
 
 [3] For PC, I'd personally draw my compatibility line where platforms support 16-bit, and only ship explicit packed 16-bit shaders instead of a separate 32-bit/16-bit shader permutation. AMD it's Vega up, for NV note Maxwell/Pascal's HFMA2: https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#maxwell-and-pascal-instruction-set
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1735623992961081680
 
 [4] Suggest doing dev work on a platform with great packed 16-bit support: AMD PC Vulkan on RDNA2, and don't filter through the DXC deoptimizer, so it is actually possible to see the value. Then hammer on vendors who still have spotty compiler related issues.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1735624151283478999
 
 [5] Gather4 is the hot optimization for packed 16-bit because data is returned in SoA form. Always explicitly pack 16-bit and alias to/from UINT32 when passing constants to shader (best to alias eight 16-bit values as uint4). Etc.
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1735624428581429681
 
 [6] Trick for good 16-bit is range management. Sometimes pre-scaling is needed to avoid overflow,
 and make sure to bring max values out of denormal before using rcp.
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1735624590997573967
 
 [7] Power is a function of data movement. "Touch it Once" is the top optimization, all the "Split it into a Graph, Pipeline Stage it" people are walking themselves towards high-power.
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1735624799378923763
 
 [8] Majority of GPU workloads are whole-pass serially dependent, but in practice temporally independent with exception of small localized serial dependency. If you "stick it into a frame graph" you cut off your ability to optimize.
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1735624946414501895
 
 [9] Resolution growth is slowing. Mobile's high DPI is beyond good enough. 8k won't be successfull because of the extra 4x scaling TAA tax, or it won't matter because people will just integer scale on scanout.
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1735625312350642210
 
 [10] Scaling TAA will converge to consistent higher quality over time, thus PC is likely to locally converge to 720p|1080p rendering for 4k (for high|med FPS). This implies that the industry should hit a point where large L3 can hold full render targets ...
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1735625572040994994
 
 [11] TAA scaling, full render targets in L3: Maybe RDNA2 128 MiB L3 was spot on actually, and RNDA3's L3 drop in capacity, and the no L3 consoles had this wrong Tracing and big nets probably need that L3 too.
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1735625818288558341
 
 [12] Lots of value getting a good 8x area scale for 4K 120 Hz. Yet devs won't see value until they make the non-pixel costs scale well, and move post before scaling.
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1735626224188243980
 
 [13] Triangles are not needed any more. Hint 8x area scaling doesn't know any connectivity. Connectivity is inferred by likeness to accumulated feedback. Shaded samples from non-triangles -> scaling TAA still works. Hint 2: scaling TAA raster is mostly just tri culling.
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1735626424956895544
 
 [14] TAA gets quality limited at high scaling because it can only infer correct behavior from geometry similar to what is rendered. Geometric aliasing drops too much thin geo. Fix for that is to change the standard practice, which will obsolete all black boxes.
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1735626636509208780
 
 [15] Stratified sampling is good for at least 2x the geo density compared to regular grid ... frame viewport jitter is end-of-life for quality.
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1735626794491949057
 
 [16] TAA's ability to correctly infer reprojection validity on skinned objects is crippled by lack of correct forward projection. Fixing that will break the black boxes.
 
-**19/** @NOTimothyLottes
+**19/** **@NOTimothyLottes** ^1735627033844085045
 
 [17] Shading density will end up variable, TAA's disocclusion and convergence logic needs to be out of the black box, and deeply integrated into shading systems too (because it points where to shade more). This evolution will break all the black boxes.
 
-**20/** @NOTimothyLottes
+**20/** **@NOTimothyLottes** ^1735627294377456031
 
 [18] Per-pixel ML people have it wrong, your net is multi-pass, all the top optimizations require less passes. Don't matter if you optimize the matrix math, power is burned in the bandwidth, and you cannot reduce your bandwidth enough to compete with the better options.
 
-**21/** @NOTimothyLottes
+**21/** **@NOTimothyLottes** ^1735627982763385283
 
 [19] GI needs a surface shade cache, might as well object space shade at that point, which enables NUMA, which enables more HW scaling.
 
-**22/** @NOTimothyLottes
+**22/** **@NOTimothyLottes** ^1735628284979777660
 
 [20] HW RT people had it very wrong, top optimization is non-ray-traversal ordered access. Follows: occlusion testing is neighbor-coherent, no trace, just test shared occluders. GI reduces to high frequency occlusion of some lower frequency probe domain.
 
-**23/** @NOTimothyLottes
+**23/** **@NOTimothyLottes** ^1735628590094385329
 
 [21] HW RT's skin-all re-tree before trace won't scale ever. Only stratified visibility gets log scaling on animated geo. HW RT has no system for bounding costs, while stratified visibility does. Think out of the black box, GPU got programmability decade back now.
 
-**24/** @NOTimothyLottes
+**24/** **@NOTimothyLottes** ^1735631826427732305
 
 [22] Love HW people, but they opt for a $ train even as it is derailing: they need to build HW, make it faster, it's what they do. But leave a trail of back-compat debris TS/ROV/GS/etc after each gfx fad. Vote with your engineering, general purpose CS, just say no to black boxes.
 
 Branches: [[archive/threads/NOTimothyLottes/2023-12-15-long-thread/2023-12-15-SebAaltonen-they-design-one-api-for-each-separate-use-case]]
 
-**25/** @NOTimothyLottes
+**25/** **@NOTimothyLottes** ^1735650294552203454
 
 [23] Scaling TAAs want sparse data each frame, more like a low-frequency pixel control cage displacing a high-frequency reprojected feedback. No pixel centers any more, no need to interpolate before shading. Rather want striped data, so the cachelines group spaced-out samples ...
diff --git a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-AgileJebrim-yep-put-the-whole-game-logic-in-a-game-glsl.md b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-AgileJebrim-yep-put-the-whole-game-logic-in-a-game-glsl.md
index 3bee52f..d5c42ac 100644
--- a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-AgileJebrim-yep-put-the-whole-game-logic-in-a-game-glsl.md
+++ b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-AgileJebrim-yep-put-the-whole-game-logic-in-a-game-glsl.md
@@ -26,13 +26,13 @@ parent_post_id: "1736157335058300999"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1736232422528709002
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Yep put the whole game logic in a game.glsl compute shader.
 
-**2/** @AgileJebrim
+**2/** **@AgileJebrim** ^1736233142002860372
 
 If doing a large open world game, set up a paging system to stream data to the GPU in tiles, particularly static data. All dynamic data should be handled on the GPU. If leveraging  server, you can pass along the network packets as they are. CPU shouldn’t really be doing much for a game client. It certainly shouldn’t be varying due to scene complexity.
 
diff --git a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-SheriefFYI-two-point-six-seconds-d3d12createdevice-on-my.md b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-SheriefFYI-two-point-six-seconds-d3d12createdevice-on-my.md
index 85c6193..58cc81f 100644
--- a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-SheriefFYI-two-point-six-seconds-d3d12createdevice-on-my.md
+++ b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-SheriefFYI-two-point-six-seconds-d3d12createdevice-on-my.md
@@ -26,35 +26,35 @@ parent_post_id: "1736147815829565624"
 
 ## Branch
 
-**1/** @SheriefFYI
+**1/** **@SheriefFYI** ^1736217482682138685
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 two point six seconds?!! D3D12CreateDevice() on my machine is ~300ms..
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1736220920635670883
 
-@SheriefFYI
+**@SheriefFYI**
 
 Yeah and that's a warm second run too. I dev on crippled laptops so when the handicaps are removed the stuff really flies.
 
-**3/** @SheriefFYI
+**3/** **@SheriefFYI** ^1736222787184795787
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 still that sounds like a lot, what specs / driver? Any weird vk layers loading?
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1736228132489736602
 
-@SheriefFYI
+**@SheriefFYI**
 
 Ok, yeah just reprofiled, and it's down to 269 ms. Best part of the Win10 experience, never know what is actually happening in the background.
 
 ![](https://pbs.twimg.com/media/GBhSG-XXMAAT0FS?format=png&name=orig)
 
-**5/** @SheriefFYI
+**5/** **@SheriefFYI** ^1736229279246004251
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 *whew* that sounds more normal
 
diff --git a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2025-08-08-VPCOMPRESSB-so-youre-preallocating-every-type-of-descriptor.md b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2025-08-08-VPCOMPRESSB-so-youre-preallocating-every-type-of-descriptor.md
index ac77a14..fc05e8d 100644
--- a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2025-08-08-VPCOMPRESSB-so-youre-preallocating-every-type-of-descriptor.md
+++ b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2025-08-08-VPCOMPRESSB-so-youre-preallocating-every-type-of-descriptor.md
@@ -26,21 +26,21 @@ parent_post_id: "1736154923408953499"
 
 ## Branch
 
-**1/** @VPCOMPRESSB
+**1/** **@VPCOMPRESSB** ^1953820468697317627
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 so you're preallocating every type of descriptor to a max count and aliasing them with various qualifiers/attributes? all that in a single memory layout?
 
 if this is the case, the program identifier makes sense. you can just swap out the code, leaving the data untouched.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1953842045136621727
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 I use the layout aliasing to choose things like {read-only K$ reads, vs read-write texture cache access} for buffers, for making sure GLC=1 (write through to coherent cache domain) is enabled for stores (image and buffer), as well as selecting the texel format for image access :)
 
-**3/** @VPCOMPRESSB
+**3/** **@VPCOMPRESSB** ^1956125618161995890
 
 i revisited last night.
 
@@ -52,39 +52,39 @@ i assume your code is laid in stages. each stage corresponds to a specific image
 
 aliasing supports this even further, with explicit intentions for resources.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1956135942265430037
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 On modern desktop GPUs it is very efficient to have everything bound all the time (bind everything once/frame). On AMD on use the descriptor is loaded into SGPRs. You only pay for what is used. And ideally group descriptors used together near so they share same cache lines.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1956136412211708145
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 Merging independent shaders is then easy. Merging dependent shaders is more complex. You can both do it an unsafe way or a safe way (too long for one tweet)...
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1956138948347994517
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 The unsafe way: launch a N+M sized 1D dispatch. Bank on having enough work in N such that when the dependent M starts that enough of N is finished in practice. This can work when early M depends on only early N workgroups.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1956141082032660650
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 There are various safe ways. For instance  if the dependent work isn't done, one can conditionally duplicate the work. Or conditionally use a fallback. Or only use the pre task if it had finished to accelerate the second, for example hierarchical empty space skipping ...
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1956141576662511764
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 The challenge of course is that the  obvious stuff like spin waiting isn't safe because of bad API and driver design : no forward progress guarantee (on preemption, etc)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1956142377451610437
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 Quite literally they just need to put in a guarantee that workgroups with lower coords in scan order are launched first and restored first in a partial preemption restore. Then you could safely spin on work in a prior numbered workgroup
 
diff --git a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/index.md b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/index.md
index 1e007c1..ce8ad4e 100644
--- a/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/index.md
+++ b/archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1736147815829565624
 
 Inspecting my old VK engines. On start I would warm all the pages. Code pages get a read, and data pages got an atomic add of a non-compiler known zero. An attempt to improve initial load time. But in the end nothing helps the 2.6 seconds or so required to just open the VK device
 
@@ -33,25 +33,25 @@ Inspecting my old VK engines. On start I would warm all the pages. Code pages ge
 
 Branches: [[archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-SheriefFYI-two-point-six-seconds-d3d12createdevice-on-my]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1736149104269344962
 
 Since I almost never get crashes I forgot about this, but had written a system to auto relaunch the app on crash or special case exit. No complex error handling, just bank on fast relaunch instead.
 
 ![](https://pbs.twimg.com/media/GBgJ1y5W0AArwSt?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1736151406703214631
 
 The hope of single PSO in VK was scrapped because IHV compile times explode. However I did maintain single SPIR-V file, and use spec constants to choose individual shaders. The threads doing compile dump compile times and disassembly in DEV mode.
 
 ![](https://pbs.twimg.com/media/GBgMbMEWkAAOd_d?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1736153352096882847
 
 I'm a fan of single file applications. So when not in DEV mode the one SPIR-V file gets pulled from the EXE. Compiling PSOs is always the critical path, the moment the "bind everything once" layout is done, PSO compile goes wide on the machine.
 
 ![](https://pbs.twimg.com/media/GBgOQRiXoAAX2k6?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1736154923408953499
 
 "Bind-Everything-Once" in Vulkan looks like this. Bindings {1}=CPU pushing to GPU, {2}=buffer (more on that next), {3}=as UAVs, {4}=as TEX ... No binding logic at runtime ever. Access anything in the most efficient way any time.
 
@@ -59,13 +59,13 @@ I'm a fan of single file applications. So when not in DEV mode the one SPIR-V fi
 
 Branches: [[archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2025-08-08-VPCOMPRESSB-so-youre-preallocating-every-type-of-descriptor]]
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1736156478354903216
 
 Did something silly but fast for buffers. Here is an example from a dummy test app. The main SSBO gets aliased as 4 structures, each with the same data accessable with four types {uint, uint4, float, float4}. So same binding layout aliasing chooses load type and K$ or V$ access.
 
 ![](https://pbs.twimg.com/media/GBgQ0xlWQAA7Yks?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1736157335058300999
 
 Literally the CPU does almost nothing. All game input gets pushed to the GPU for game logic. Some major advantages in input latency to do player logic on the GPU instead. And it's dead easy.
 
@@ -73,16 +73,16 @@ Literally the CPU does almost nothing. All game input gets pushed to the GPU for
 
 Branches: [[archive/threads/NOTimothyLottes/2023-12-16-inspecting-my-old-vk-engines/2023-12-17-AgileJebrim-yep-put-the-whole-game-logic-in-a-game-glsl]]
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1736158727370154157
 
 This requires context, I build programs in a hardware style, fixed resources, fixed shaders, and all logic expressed in the data itself. No code or resource variation, no runtime issues period. So another dummy program example, I can just list my resources on load in a table ...
 
 ![](https://pbs.twimg.com/media/GBgTCgJXsAEPH3W?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1736160027755360495
 
 Radically simplicity is how I roll personally. Easy to confuse the idea that one needs complexity to express a complex system. It's more like one needs complexity to express a complex solution -> abstractions and hierachical meta feeds on itself until tech debt freezes progess.
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1736161886079533186
 
 If there is anything to learn for programming, it is to be more critical of your own ideas than all else, be ruthless, trim until what is left is only what is actually required, question everything constantly.
diff --git a/archive/threads/NOTimothyLottes/2023-12-19-working-towards-a-public-domain-release-of-a/index.md b/archive/threads/NOTimothyLottes/2023-12-19-working-towards-a-public-domain-release-of-a/index.md
index 0e9047d..86800d0 100644
--- a/archive/threads/NOTimothyLottes/2023-12-19-working-towards-a-public-domain-release-of-a/index.md
+++ b/archive/threads/NOTimothyLottes/2023-12-19-working-towards-a-public-domain-release-of-a/index.md
@@ -25,17 +25,17 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1737198887914377512
 
 Working towards a public-domain release of a cleaned version of my Win32 Vulkan NV+AMD compute graphics platform. What I used last for rapid prototyping (which is also IMO fine for releasable software). Won't call it an 'Engine' because it only provides tools to hang yourself ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1737200333338595330
 
 Simplified the error logger today. Memory mapped file is definitely the way to go, one atomic per message, log multiple sessions, fixed size file acts like a message ring buffer. Background thread keeps the last message updating the same line on the console (for easy debug).
 
 ![](https://pbs.twimg.com/media/GBvFvOXXMAAFLXS?format=png&name=orig)
 ![](https://pbs.twimg.com/media/GBvFvOWX0AAxSuU?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1737201090058219980
 
 Multi-session is nice, since the binary auto reloads in some cases (crash, etc), want to see why the reload happened, so don't want to clear the log. Yes, I still don't use debuggers, this logger + runtime shader recompile is all I use personally for dev work.
diff --git a/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/2024-01-05-kenpex-its-what-debuggers-should-be-debuggers-made-zero.md b/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/2024-01-05-kenpex-its-what-debuggers-should-be-debuggers-made-zero.md
index 4364c0b..aa19be2 100644
--- a/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/2024-01-05-kenpex-its-what-debuggers-should-be-debuggers-made-zero.md
+++ b/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/2024-01-05-kenpex-its-what-debuggers-should-be-debuggers-made-zero.md
@@ -26,9 +26,9 @@ parent_post_id: "1742743018929557805"
 
 ## Branch
 
-**1/** @kenpex
+**1/** **@kenpex** ^1743086413736976462
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 It's what debuggers should be. Debuggers made zero progress in the last decade, but fundamentally they patch running code... just they are limited to patch an interrupt instead of allowing us to do... anything. Even tracepoints, while nice, are a castrated version of livecode.
 
diff --git a/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/index.md b/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/index.md
index d6af5e9..6e065b3 100644
--- a/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/index.md
+++ b/archive/threads/NOTimothyLottes/2024-01-04-debug-for-majority-gpu-side-game-dev-run-time/index.md
@@ -25,13 +25,13 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1742742039169573054
 
 Debug for majority-GPU-side game dev? Run-time recompile and hex viewer. If I want to see a value it is 'ramWI1.hxd[pos]=value;' (write to the memory that the hex dump reads from). Everything else is automatic, just save source and the results show up on screen. Zero's not drawn.
 
 ![](https://pbs.twimg.com/media/GC91mNxXEAAaovO?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1742743018929557805
 
 IMO this is preferred to a 'debugger'. I can fill values from all workgroups simply by placing them at different positions, etc. Can get timings via shader clock for profiling even. It is transformative in dev productivity.
 
diff --git a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-06-MartinJIFuller-a-worthwhile-project-knowledge-well-worth-sharing.md b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-06-MartinJIFuller-a-worthwhile-project-knowledge-well-worth-sharing.md
index 1b4a011..6c77ce5 100644
--- a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-06-MartinJIFuller-a-worthwhile-project-knowledge-well-worth-sharing.md
+++ b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-06-MartinJIFuller-a-worthwhile-project-knowledge-well-worth-sharing.md
@@ -26,9 +26,9 @@ parent_post_id: "1776597200073568623"
 
 ## Branch
 
-**1/** @MartinJIFuller
+**1/** **@MartinJIFuller** ^1776703621435933035
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 A worthwhile project, knowledge well worth sharing, but is a book the right format? Perhaps yes, just thinking out loud.
 
diff --git a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-08-RickyAH-ha-that-wont-save-you-from-my-follow.md b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-08-RickyAH-ha-that-wont-save-you-from-my-follow.md
index 647d073..eba442e 100644
--- a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-08-RickyAH-ha-that-wont-save-you-from-my-follow.md
+++ b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-08-RickyAH-ha-that-wont-save-you-from-my-follow.md
@@ -26,9 +26,9 @@ parent_post_id: "1776597200073568623"
 
 ## Branch
 
-**1/** @RickyAH
+**1/** **@RickyAH** ^1777246377824731474
 
-@NOTimothyLottes @SebAaltonen @MartinJIFuller
+**@NOTimothyLottes** **@SebAaltonen** **@MartinJIFuller**
 
 Ha! That won’t save you from my follow
 
diff --git a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-09-BenSimsTech-oh-sick-im-deep-in-optimising-shaders-in-an-aaa.md b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-09-BenSimsTech-oh-sick-im-deep-in-optimising-shaders-in-an-aaa.md
index f545c0e..cd12443 100644
--- a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-09-BenSimsTech-oh-sick-im-deep-in-optimising-shaders-in-an-aaa.md
+++ b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/2024-04-09-BenSimsTech-oh-sick-im-deep-in-optimising-shaders-in-an-aaa.md
@@ -26,9 +26,9 @@ parent_post_id: "1776597200073568623"
 
 ## Branch
 
-**1/** @BenSimsTech
+**1/** **@BenSimsTech** ^1777555708499927142
 
-@NOTimothyLottes @SebAaltonen @MartinJIFuller
+**@NOTimothyLottes** **@SebAaltonen** **@MartinJIFuller**
 
 Oh sick, I'm deep in optimising shaders in an AAA game for GCN hardware right now (You can probably guess the platform(s)) so this is super relevant to me. 😅
 Going to give it all a thorough read, I'm after all the GCN info I can find right now.
diff --git a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/index.md b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/index.md
index e6c51e5..be3314d 100644
--- a/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/index.md
+++ b/archive/threads/NOTimothyLottes/2024-04-06-on-https-mastodon-gamedev-place-notimothylottes/index.md
@@ -27,9 +27,9 @@ in_reply_to: "1776518700230721688"
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1776597200073568623
 
-@MartinJIFuller @SebAaltonen
+**@MartinJIFuller** **@SebAaltonen**
 
 On https://mastodon.gamedev.place/@NOTimothyLottes I'm collecting posts with AMD GPU disassembly dumps for a book on everything the shader compiler 'isn't doing'. Constant AMD GPU compiler perf bug SPAM is a key part of my online strategy to keep a low follower count.
 
diff --git a/archive/threads/NOTimothyLottes/2024-05-04-it-was-only-later-when-systems-forced-c-abi/index.md b/archive/threads/NOTimothyLottes/2024-05-04-it-was-only-later-when-systems-forced-c-abi/index.md
index d4420cd..71640d1 100644
--- a/archive/threads/NOTimothyLottes/2024-05-04-it-was-only-later-when-systems-forced-c-abi/index.md
+++ b/archive/threads/NOTimothyLottes/2024-05-04-it-was-only-later-when-systems-forced-c-abi/index.md
@@ -25,8 +25,8 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1786551881504104518
 
-@Nerfoxingaround @SebAaltonen
+**@Nerfoxingaround** **@SebAaltonen**
 
 It was only later when systems forced C ABI library interfaces with it's stacks and junk that things got messy and only because of the C. Then C++ happened and things got much worse. Pure ASM is easy, its interfacing with the bloat world that got hard.
diff --git a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-bmcnett-so-each-line-is-63-spaces-followed-by-a-n-and.md b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-bmcnett-so-each-line-is-63-spaces-followed-by-a-n-and.md
index e3a2883..9877892 100644
--- a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-bmcnett-so-each-line-is-63-spaces-followed-by-a-n-and.md
+++ b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-bmcnett-so-each-line-is-63-spaces-followed-by-a-n-and.md
@@ -26,27 +26,27 @@ parent_post_id: "1857813028349128825"
 
 ## Branch
 
-**1/** @bmcnett
+**1/** **@bmcnett** ^1857815519166112244
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 So each line is 63 spaces followed by a \n, and those 63 spaces get replaced by printable characters dynamically? I have long dreamed of a text format with a fixed 128 byte line width, and cache line size is gradually switching over from 64 to 128
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1857818622271332607
 
-@bmcnett
+**@bmcnett**
 
 Yes fixed character[63]='\n', string fills until then or spaces out. I did 128-char once, but still sometimes use small VGA resolutions. Also written a source editor a few times with this fixed line size, makes for a very simple implementation ...
 
-**3/** @bmcnett
+**3/** **@bmcnett** ^1857819880600531261
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Variable line width ASCII text files made a lot of sense when storage was 100KB or 100MB or 100GB, but now that it's in the terabytes, why even bother
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1857820858162753661
 
-@bmcnett
+**@bmcnett**
 
 That line of thinking is universal solution to most self-inflicted problems of the modern era.
 
diff --git a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-datenwolf-why-the-heck-do-you-care-about-cache-lines-if-you.md b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-datenwolf-why-the-heck-do-you-care-about-cache-lines-if-you.md
index 08bfc96..285b8df 100644
--- a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-datenwolf-why-the-heck-do-you-care-about-cache-lines-if-you.md
+++ b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-datenwolf-why-the-heck-do-you-care-about-cache-lines-if-you.md
@@ -26,46 +26,46 @@ parent_post_id: "1857805438151983120"
 
 ## Branch
 
-**1/** @datenwolf
+**1/** **@datenwolf** ^1857820149039947846
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Why the heck do you care about cache lines, if you write to a mmaped file? Of course there's overhead: TLBs aren't free. And TLBs matter… at lot in fact. When you map the file, initially the kernel marks some address space, but doesn't populate it with pages. 1/
 
-**2/** @datenwolf
+**2/** **@datenwolf** ^1857820901644882115
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 On the first write to a non-faulted page, the kernel has to find a free page in memory, associate it in the page table, all the while keeping an eye on all threads process, since changes to a process virtual address space must appear atomic. 2/
 
-**3/** @datenwolf
+**3/** **@datenwolf** ^1857821143752749469
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Memory maps aren't free. Simple writes to a file will easily outperform and cause less overhead, than naively implemented mmaped I/O. 3/
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1857824230416470516
 
-@datenwolf
+**@datenwolf**
 
 BTW, I pre-fault my mapped files. Just like I pre-fault the binary and data segments too. But sure the pre-fault could go stale. And yes TLBs are a system perf issue, but atlas you need admin priv on Windows to play 2 MiB pages for data, so it's off the table
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1857824874061828526
 
-@datenwolf
+**@datenwolf**
 
 Why cacheline aligned and sized on the CPU? In theory store the entire line in a short enough timeframe and your Read-Modify-Write becomes just a Write! CPU doesn't have byte-write-mask (I think). If SW+HW is good. And threads keeping to isolated lines means no false sharing. Etc
 
-**6/** @datenwolf
+**6/** **@datenwolf** ^1857825772590731292
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 (That cacheline remark was meant rhetorically; between cache misses and page faults, a page fault will largely overshadow a cache miss in performance overhead.
 But yes, if you prefault, then that problem is mitigated.)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1857827620701761746
 
-@datenwolf
+**@datenwolf**
 
 'Smart' people keep trying to impose (aka force) their will on others through poor system APIs, like not being able to pre-pin pages. Good look buddy, I'll just run a background task that continuously touch walks the pages I want pinned anyway.
 
diff --git a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-static_assert_0-this-is-super-cool-but-why-map-a-file-and-not.md b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-static_assert_0-this-is-super-cool-but-why-map-a-file-and-not.md
index 39ea9b8..b31707b 100644
--- a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-static_assert_0-this-is-super-cool-but-why-map-a-file-and-not.md
+++ b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-static_assert_0-this-is-super-cool-but-why-map-a-file-and-not.md
@@ -26,21 +26,21 @@ parent_post_id: "1857803914604618029"
 
 ## Branch
 
-**1/** @static_assert_0
+**1/** **@static_assert_0** ^1857867668289663108
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 This is super cool, but why map a file and not just stdout?
 
-**2/** @vodangkhoa873
+**2/** **@vodangkhoa873** ^1857882178463608868
 
-@static_assert_0 @NOTimothyLottes
+**@static_assert_0** **@NOTimothyLottes**
 
 The writes can be done concurrently from many threads?
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1857884114403340408
 
-@vodangkhoa873 @static_assert_0
+**@vodangkhoa873** **@static_assert_0**
 
 Yes, one 'atomicAdd(atomAdr,1)&65535' to get the line number (window of 65536 max lines) then write the line individually. Only contention is on that atomicAdd CPU instruction which is as minimal as possible.
 
@@ -48,15 +48,15 @@ I do the atomic add instruction using simple inline ASM (below)
 
 ![](https://pbs.twimg.com/media/GciHgZzXIAAD9by?format=png&name=orig)
 
-**4/** @static_assert_0
+**4/** **@static_assert_0** ^1857885819274453195
 
-@NOTimothyLottes @vodangkhoa873
+**@NOTimothyLottes** **@vodangkhoa873**
 
 I love this, but are you not able to get that codegen with intrinsics or just normal C?
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1857887943261827446
 
-@static_assert_0 @vodangkhoa873
+**@static_assert_0** **@vodangkhoa873**
 
 I've been hand rolling intrinsics CPU-side in GCC with inline asm since the dawn of support for that. So haven't kept up with the high-level-lang mess fire since.
 
diff --git a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-17-HerrUppoHoppa-curious-why-you-memory-map-the-32-bit-counter-to.md b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-17-HerrUppoHoppa-curious-why-you-memory-map-the-32-bit-counter-to.md
index 78bfbc7..9f36581 100644
--- a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-17-HerrUppoHoppa-curious-why-you-memory-map-the-32-bit-counter-to.md
+++ b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-17-HerrUppoHoppa-curious-why-you-memory-map-the-32-bit-counter-to.md
@@ -26,21 +26,21 @@ parent_post_id: "1857804669994565771"
 
 ## Branch
 
-**1/** @HerrUppoHoppa
+**1/** **@HerrUppoHoppa** ^1858039804551663740
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Curious why you memory map the 32 bit counter to the file. Also why does it get half the file as opposed to just the end of the mapped region?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1858152609149804727
 
-@HerrUppoHoppa
+**@HerrUppoHoppa**
 
 It's pow2 message lines so fixing wrap is AND(cnt,lines-1). Counter after that and needs to take a page minimum. So yes I could make the size slightly smaller, but just lazy. Counter in file because then multiple runs accumulate in the file for comparison.
 
-**3/** @HerrUppoHoppa
+**3/** **@HerrUppoHoppa** ^1858226056244899980
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Ah I see, interesting solution!
 
diff --git a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/index.md b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/index.md
index 2d7026f..6d409f5 100644
--- a/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/index.md
+++ b/archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1857803914604618029
 
 [0] What a horrible term 'printf-debugging'
 If you are debugger-free might as well at least be libc-free
@@ -33,7 +33,7 @@ Here is how I work CPU C code without any debugger in my engines, and how it wor
 
 Branches: [[archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-static_assert_0-this-is-super-cool-but-why-map-a-file-and-not]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1857804669994565771
 
 [1] First I map a '.log' file, so there is no other file IO
 (a.) First half of this file (log2 sized file) contains lines of a fixed 64-character size (with the \n at the end)
@@ -41,17 +41,17 @@ Branches: [[archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-pr
 
 Branches: [[archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-17-HerrUppoHoppa-curious-why-you-memory-map-the-32-bit-counter-to]]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1857805438151983120
 
 [2] So writing a line to this log is 100% overhead-free and lock-free, one just increments the atomic counter, and dumps the comment line in the memory mapped file. Note the 64-byte line size matches a cacheline size, so no contention on the write of the line
 
 Branches: [[archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-datenwolf-why-the-heck-do-you-care-about-cache-lines-if-you]]
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1857806110687727898
 
 [3] It's ideal for a multi-thread environment, you get correct temporal ordering captured in the log file without any real effect on the scheduling of threads.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1857806800663244889
 
 [4] Lines are always in a fixed format
 r|sc.milmic|line_|hex_____|0000000000-|string...
@@ -62,14 +62,14 @@ hex ... hex print of number
 000 ... decimal print of the number
 string ... user msg
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1857807155669225900
 
 [5] I write a line with a simple function call
 Tlk(__LINE__,n,"msg");
 Where 'n' is the number, "msg" is a string
 Don't need printf, this is way better
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1857809793550872629
 
 [6] Here is an example with a very simple program, just a few first lines. It's nice to automatically see exact timing. Timing since start
 0.005478 sec ... mapping of the cartridge file
@@ -79,19 +79,19 @@ etc
 
 ![](https://pbs.twimg.com/media/GchC4NwXQAAbDfS?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1857812120823308592
 
 [7] Another simple example of a fully pipelined startup, can instantly know where the primary cost is, 
 "Instance begin" and "Instance end" wrap setup of the Vulkan instance, a process which took 2.4 seconds. The 4 PSOs hit in the shader cache at 3k microseconds each
 
 ![](https://pbs.twimg.com/media/GchFfI5WcAAZ_Al?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1857813028349128825
 
 [8] The log file keeps multiple runs, so it's easy to compare. Notepad2 it's F5 to reload the log file.
 
 Branches: [[archive/threads/NOTimothyLottes/2024-11-16-0-what-a-horrible-term-printf-debugging/2024-11-16-bmcnett-so-each-line-is-63-spaces-followed-by-a-n-and]]
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1857816126295548195
 
 [9] The point: keep it minimal, keep it simple, and keep the number of required things that take human time to the smallest possible. If you don't fall off the 'compile-time' curve, and re-compile/re-start/re-load is 'key-press-time' this works amazingly well (interactive)
diff --git a/archive/threads/NOTimothyLottes/2024-11-19-working-towards-a-new-bring-up-of-front-buffering/index.md b/archive/threads/NOTimothyLottes/2024-11-19-working-towards-a-new-bring-up-of-front-buffering/index.md
index 7a7b1c5..8861541 100644
--- a/archive/threads/NOTimothyLottes/2024-11-19-working-towards-a-new-bring-up-of-front-buffering/index.md
+++ b/archive/threads/NOTimothyLottes/2024-11-19-working-towards-a-new-bring-up-of-front-buffering/index.md
@@ -25,34 +25,34 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1858709400791261630
 
 Working towards a new bring up of front-buffering on NV via VK. My last implementation had been tuned on AMD and didn't work on NV any more. NV does seem to accept a 1-deep swap with IMMEDIATE presentation at least on latest drivers, so that is a good start.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1858710122727391666
 
 Since my image resources are static after init time, only swap images change when the driver kills the swap chain (which once upon a time seemed to happen on ALT+TAB maybe). So it's one descriptor set always bound.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1858710719018979651
 
 Stopped using VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT (god awful naming length people), because I think it could be a perf hit on NV due to extra indirection. NV driver is free to bake down the single set now before the command buffer is sent over.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1858712158004994552
 
 At this stage, to the point of having everything loaded and swap chain created, it's 2700 lines of engine code. That includes embedding headers (no external includes), so it's a one file compile. People claim rolling your own engine is hard? Not really if you keep it focused.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1858713499716694264
 
 So far it's a 0.25 sec hot load time on this NV dGPU laptop. Includes mapping a 4 MiB 'cart' file from pagecache, doing a 512 MiB buffer for GPU usage, hits on all PSOs, allocating some images, and kicking the command buffer that copies in the cart, and clears everything.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1858714108415119495
 
 Everything at load-time is multi-threaded to try to minimize start to in-game time. This is in sharp contrast to runtime where the only multi-threading being used is to separate things that are blocking.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1858714908516381114
 
 I get some utility on parallelizing {vulkan instance creation, mapping the cart file, warming the TLBs by walking all the pages, bringing up the window} it's about 0.08 seconds in at that point
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1858715434436227544
 
 After VK device is open, I signal a background thread to load the SPIR-V module, while building the descriptor set layout, which then unblocks PSO compile on background threads. And the rest of the VK setup runs in parallel. Working towards swap creation.
diff --git a/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/2024-11-20-AgileJebrim-how-reliable-in-your-experience-in-code-like-that.md b/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/2024-11-20-AgileJebrim-how-reliable-in-your-experience-in-code-like-that.md
index bf958a2..78de9bd 100644
--- a/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/2024-11-20-AgileJebrim-how-reliable-in-your-experience-in-code-like-that.md
+++ b/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/2024-11-20-AgileJebrim-how-reliable-in-your-experience-in-code-like-that.md
@@ -26,51 +26,51 @@ parent_post_id: "1859369992355021246"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1859375048550662580
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 How reliable in your experience in code like that is the compilation to avoid branches?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1859396349579407750
 
-@AgileJebrim
+**@AgileJebrim**
 
 Lots of stuff can get mapped by the compiler to V_CNDMASK_B32 instead of branching by using mix(a,b,bool) syntax. I rarely use branching because of how horrible the code generation is. No way to express that the common path stay code linear either, etc.
 
-**3/** @AgileJebrim
+**3/** **@AgileJebrim** ^1859397365310030289
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I know in CUDA-land that it likes to create branches for ternaries if it contains more than 4 total instructions in a statement.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1859398417656451574
 
-@AgileJebrim
+**@AgileJebrim**
 
 But the real problem is lacking of explicit controls, and lacking implicit branch hints (wave-uniform/non-uniform, expected branch hit rate, etc). Better if we could just do explicit ASM style branch instructions and labels.
 
-**5/** @AgileJebrim
+**5/** **@AgileJebrim** ^1859398626025345193
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Well I seek to ban branches entirely, so that’s the exact opposite of what I want.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1859399330488070285
 
-@AgileJebrim
+**@AgileJebrim**
 
 If your shader I$ is say 32 KiB and your instructions average say 8-bytes. You have 4 K instructions before you are streaming the program not just the data. Code size is actually important. And while micro level unroll is needed, macro level duplication is a problem with tiny I$
 
-**7/** @AgileJebrim
+**7/** **@AgileJebrim** ^1859399629978087742
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I avoid the duplication of instruction patterns too. I feel it’s a failure to properly parallelize if you’re repeating the same instructions instead of data parallelizing further.
 
-**8/** @AgileJebrim
+**8/** **@AgileJebrim** ^1859399705584717853
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 One more reason why I avoid functions.
 
diff --git a/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/index.md b/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/index.md
index ecf8c5d..11b30c3 100644
--- a/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/index.md
+++ b/archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/index.md
@@ -25,11 +25,11 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1859368974351274470
 
 [0] Been wanting to do this for a long time, a thread on hard-core shader development. Something that digs into what I've learned and applied over the years. Along with the evolution of the strange syntax I use when writing shaders ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1859369992355021246
 
 [1] Lets start at one of the early ones, FXAA 3.11. Someone is hosting that here: https://gist.github.com/kosua20/0c506b81b3812ac900048059d2383126 ... most lines, it's an easy map to NV's arch which has predicated instructions (red is the predicate). Many lines are 1:1 mappings with physical HW instructions.
 
@@ -37,150 +37,150 @@ in_reply_to: ""
 
 Branches: [[archive/threads/NOTimothyLottes/2024-11-20-0-been-wanting-to-do-this-for-a-long-time-a/2024-11-20-AgileJebrim-how-reliable-in-your-experience-in-code-like-that]]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1859372015670432237
 
 [2] Looking at FSR1: https://github.com/GPUOpen-Effects/FidelityFX-FSR/blob/master/ffx-fsr/ffx_fsr1.h - that had 3 permutations {32-bit, 16-bit unpacked, 16-bit packed}, where the packed one maps to how AMD's packed instructions work (everything explicitly packed)
 
 ![](https://pbs.twimg.com/media/Gc3QjEiWYAADo14?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1859373265380069827
 
 [3] Onto STP: https://github.com/Unity-Technologies/Graphics/blob/27341ce4f5c8853d7f15e9420bff499f1087aceb/Packages/com.unity.render-pipelines.core/Runtime/STP/Stp.hlsl - A different set of permutations {32-bit, packed 16-bit} then {implicit mediump vs explicit} in the 32-bit (generic) permutation via types like StpMF4 which aim to allow a compiler on mobile to get some 16-bit register savings
 
 ![](https://pbs.twimg.com/media/Gc3SFXTXoAEt4tX?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1859373919146213617
 
 [4] Notice for 16-bit path, everything again is explicitly packed (unlike the 32-bit path). And GLSL to SPIR-V would get explicit packing to the IHV driver since SPIR-V has explicit vector types (unlike DX, which was an insane problem). Example, the reprojection filtering below.
 
 ![](https://pbs.twimg.com/media/Gc3SmjPWMAEMX_d?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1859374673953239528
 
 [5] Then STP had defines to work out differences in sampling capability (like supporting MIN/MAX sampling with UINT or not, or supporting immediate offsets or not). Example in the code doing {z,motion} UINT32 packed nearest dilation:
 
 ![](https://pbs.twimg.com/media/Gc3TW0oWIAArDjw?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1859376826709311577
 
 [6] The largest portability nightmare was mixing explicit FP16 with wave ops! So many compiler bugs across vendors = so many permutations in the code. The 32-bit path had to have a conversion from 'StpMF4' (possible implicit medium precision), to 'StpF4' explicit 32-bit.
 
 ![](https://pbs.twimg.com/media/Gc3UTC_WcAAyc5J?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1859377684104536314
 
 [7] Some of perf death problems had been that DXIL didn't have bitfield ops (unlike SPIR-V), HLSL depends on IHV compilers somehow finding and pattern matching stuff like the crap below (which is MANY OPS to 1 OPCODE). So pre-processing through HLSL on non-Xbox platforms = fail!
 
 ![](https://pbs.twimg.com/media/Gc3V5wGW8AADAju?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1859378670105674093
 
 [8] Go into the shader which is doing wave ops, and the true nightmare of platform workarounds becomes apparent https://github.com/Unity-Technologies/Graphics/blob/27341ce4f5c8853d7f15e9420bff499f1087aceb/Packages/com.unity.render-pipelines.core/Runtime/STP/StpSetup.compute - LSD/waveop permutations, 32-bit/16-bit in 16-bit path, etc
 
 ![](https://pbs.twimg.com/media/Gc3W143XEAEq6LS?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1859380404781814109
 
 [9] So yeah, even in modern times you can hit paths in compilers and toolchains that well never got tested because no one had tried it and tried shipping with it. And I think this might hint that relatively few actually do this level of crazy
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1859381304112054632
 
 [10] Part of the formula for getting great gains with 16-bit is simply the register savings. It wouldn't be possible to do good 4x4 kernel lanczos inside a TAA without packed 16-bit support (it's 64 values on load without thinking about all the other mid-algorithm data) ...
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1859381761685221605
 
 [11] Looking at STP again, there is a dering, which works with the {min,max} of the near 2x2. If the HW has MIN/MAX sampling, it can fetch that, which means a lot more than 64 values, and if not they need intermediate ALU min/max, which is extra state ...
 
 ![](https://pbs.twimg.com/media/Gc3Ze31XAAA94Y1?format=png&name=orig)
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1859382640534516057
 
 [12] Mobile hardware is so register starved (probably due to all that SRAM area going to tiles) that it wasn't possible to do good reprojection filtering PERIOD even with FP16. So STP had a crippled compromise that did bilinear in one direction, and lanczos in the other axis
 
 ![](https://pbs.twimg.com/media/Gc3afacXQAAFX-c?format=png&name=orig)
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1859383175849349534
 
 [13] Huge wake up call to mobile HW vendors, if you don't match VGPR capacity of PCs, you can never take on where PC workloads will get to. Now given both NV and AMD have packed 16-bit, it is a great time to push pass merging and avoid DRAM traffic by doing more in one shader
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1859383954551243222
 
 [14] Another part of the 16-bit perf puzzle is to not use 16-bit FP16 in constants explicitly, but only package them up as aliased as UINT32 binary blobs. And for portable systems that still need 32-bit fallbacks, always build both a packed 16-bit and 32-bit set of constants.
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1859384348249608376
 
 [15] So many people tried to 16-bit permute things working from 32-bit float constants, and on PC that is instant perf death. Sure some mobile hardware can do the conversions for lower cost, and some mobile HW could pre-amble the conversions if not, but that isn't perf portable
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1859385131942961199
 
 [16] Switching gears. So STP didn't get the most hardcore way I like to write shaders, and I've had a bunch of different permutations of ideas tried over the years ... specifically how to make the code more like GPU assembly!
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1859385497916932274
 
 [17] Looking like assembly as in making it exactly clear what the lines map to in HW OPCODEs, and what the variable map to in REGISTERS. So you are designing to what the hardware could do, even if the compiler cannot keep up
 
-**19/** @NOTimothyLottes
+**19/** **@NOTimothyLottes** ^1859386143663411375
 
 [18] Now it's true that NV and AMD HW are quite different in some respects (NV is predicated, and has generic 3 op logic ops, etc), so ultimately one has to pick their shader language abstraction based on what they want to target the most https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference (NV ISA docs)
 
-**20/** @NOTimothyLottes
+**20/** **@NOTimothyLottes** ^1859386525982527578
 
 [19] Since AMD's docs are more complete, and I like to make sure a console port is possible and would be as fast as possible, I prefer to think through all my shaders as if they are getting direct mapped to AMD's RDNA2 these days: https://www.amd.com/content/dam/amd/en/documents/radeon-tech-docs/instruction-set-architectures/rdna2-shader-instruction-set-architecture.pdf
 
-**21/** @NOTimothyLottes
+**21/** **@NOTimothyLottes** ^1859387770617110636
 
 [20] So I usually do a define that maps logic directly to what the associated instruction would be. Some of these actually map to shading language intrinsics already like fma() or bitfieldExtract(). Then write all my shader code using these defines. Example below for the defines
 
 ![](https://pbs.twimg.com/media/Gc3fKzqXUAAGnBQ?format=png&name=orig)
 
-**22/** @NOTimothyLottes
+**22/** **@NOTimothyLottes** ^1859388846481322425
 
 [21] Like to use ASM like convention for {signed, unsigned}, that all integers are unsigned, and only get converted to signed when required inside the define for a specific opcode (like signed or unsigned bitfield extract). Bit casting (aliasing) is done via SI1_I1() style macros
 
 ![](https://pbs.twimg.com/media/Gc3gGUTWQAAZwyX?format=png&name=orig)
 
-**23/** @NOTimothyLottes
+**23/** **@NOTimothyLottes** ^1859389468672680384
 
 [22] And I reduce all types to very simple 3 letter macros of which are described below. I use the same naming convention in CPU land as well. This helps keep code compact and easy to read IMO (highly subjective yes)
 
 ![](https://pbs.twimg.com/media/Gc3gna_XcAA7PXx?format=png&name=orig)
 
-**24/** @NOTimothyLottes
+**24/** **@NOTimothyLottes** ^1859390458293547232
 
 [23] One thing I struggle with to this day is compiler bitcast aliasing perf bugs. Meaning once I tried to always only use UINT4 types everywhere, and then wrap all OPCODE defines in bitcasting defines, that didn't go so well (looking at disassembly on AMD PC).
 
-**25/** @NOTimothyLottes
+**25/** **@NOTimothyLottes** ^1859390826054299714
 
 [24] Compilers depend a lot on pattern matching to NOP stuff, and well there are bugs, lots of bugs. So for the sake of portability, with the exception of {unsigned/signed} bitcasting, I use the native types when possible (no packed-16-bit/32-bit aliasing) exception of waveops
 
-**26/** @NOTimothyLottes
+**26/** **@NOTimothyLottes** ^1859391758817247636
 
 [25] Another aspect of compiler problems is argument passing to function calls causing SSA state explosions, because it's "copy semantics" as defined in the langs. Once I did inout uint4[16] (all VGPRs) as my only argument to all functions. Didn't end well!
 
-**27/** @NOTimothyLottes
+**27/** **@NOTimothyLottes** ^1859392139790053772
 
 [26] Someone on twitter (or was it bsky or mast?) had been doing a one shader game. And addressing these kinds of problems, and reminded us, YES the shader languages support global variables. No need to pass them into function! (bingo)
 
-**28/** @NOTimothyLottes
+**28/** **@NOTimothyLottes** ^1859392498797261032
 
 [27] We have been so seasoned to dislike globals in the past few decades due to well probably early mutli-window programming styles, that it is easy to forget you can just do globals, and they are fast at tool/compile time.
 
-**29/** @NOTimothyLottes
+**29/** **@NOTimothyLottes** ^1859392961294836222
 
 [28] I think the next level up of this design is to go to mostly global variables, but since the shader languages don't support global unions, then have different sets of globals when one needs to do type bitcast aliasing (which is very common with packed 16-bit and 64-bit logic)
 
-**30/** @NOTimothyLottes
+**30/** **@NOTimothyLottes** ^1859393537214763223
 
 [29] I still think the 'fix' for the shader compiler SSA state explosion mapping back to registers problem is to pass in explicit aliasing hints to the vendor compilers, so they have a better base guess at register allocation. But I doubt vendors would get on board with that
 
-**31/** @NOTimothyLottes
+**31/** **@NOTimothyLottes** ^1859394143522521102
 
 [30] My personal x86-64 languages typically worked with unions of structs on globals. Where each struct in the union was a different aliased meaning to the HW registers, and functions had been associated with a given struct in the union. So no stacks or argument passing.
 
-**32/** @NOTimothyLottes
+**32/** **@NOTimothyLottes** ^1859394661518848470
 
 [31] That kind of setup for the GPU is ideal IMO (at least for the type of stuff I do). You can link. Because the union struct for the registers is the calling ABI, and never moves (no stack). So code sharing works amazingly well. And avoiding register state explosion is built in
 
-**33/** @NOTimothyLottes
+**33/** **@NOTimothyLottes** ^1859395250537595016
 
 [32] oh damn [32], should probably stop now, until next time.
diff --git a/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/2024-11-22-AgileJebrim-shouldnt-uniform-be-a-scalar.md b/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/2024-11-22-AgileJebrim-shouldnt-uniform-be-a-scalar.md
index 394c75d..45481a5 100644
--- a/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/2024-11-22-AgileJebrim-shouldnt-uniform-be-a-scalar.md
+++ b/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/2024-11-22-AgileJebrim-shouldnt-uniform-be-a-scalar.md
@@ -26,65 +26,65 @@ parent_post_id: "1859791162091110754"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1859792525218988305
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Shouldn’t uniform be a scalar?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1859795220797501939
 
-@AgileJebrim
+**@AgileJebrim**
 
 Well 'uniform' in GLSL is a storage qualifier, "Uniforms are so named because they DO NOT CHANGE from one shader invocation to the next within a particular rendering cal" so you probably want another term for SGPR to avoid aliasing qualifiers
 
-**3/** @AgileJebrim
+**3/** **@AgileJebrim** ^1859795531041734937
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Within ISPC, uniform means scalar and varying means vector.
 
-**4/** @AgileJebrim
+**4/** **@AgileJebrim** ^1859805308660613275
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Looking deeper into the definition of SGPRs. They’re uniform just across each wavefront, rather than the entire dispatch yeah?
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1859807458652455176
 
-@AgileJebrim
+**@AgileJebrim**
 
 Yes it's a separate register file and logic unit that is per-wave instead of per-lane. Since it's introduction in Turing, NV calls them "URX for uniform registers" while AMD calls them SGPRs (scalar general purpose registers)
 
-**6/** @AgileJebrim
+**6/** **@AgileJebrim** ^1859808693950546022
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Almost sounding like we need an alternative IR to SPIR-V. One with predicated instructions and these wavefront-uniform registers/instructions. Maybe a PTX -> RDNA backend compiler?
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1859822527738245305
 
-@AgileJebrim
+**@AgileJebrim**
 
 As history goes, most re-writes fall into nearly the same problem as before. I'd rather have the fixes be applied to the existing stuff first (fix SPIR-V and GLSL, etc)
 
-**8/** @AgileJebrim
+**8/** **@AgileJebrim** ^1859822902427910389
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Perhaps. That existing PTX Vulkan extension does come to mind though.
 
-**9/** @CodePotrick
+**9/** **@CodePotrick** ^1860087693025378750
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 Its kinda annoying to put sgpr like logic in an ir tho as they have very specific limitations on each platform.
 
 Generalizing them in an ir might actually be a pessimisation.
 
-**10/** @CodePotrick
+**10/** **@CodePotrick** ^1860087976853721130
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 Amd for example can't do float ops on sgprs, so when you would allow float ops in the ir, amd has to move them to a vgpr, perform float op, move them back to sgpr for each ir-sgpr float op.
 
@@ -92,35 +92,35 @@ There are other examples for this.
 
 And nvidias have even other constrains.
 
-**11/** @AgileJebrim
+**11/** **@AgileJebrim** ^1860098975053021215
 
-@CodePotrick @NOTimothyLottes
+**@CodePotrick** **@NOTimothyLottes**
 
 And what’s the alternative right now? Just keep it all in a VGPR all the time?
 
-**12/** @CodePotrick
+**12/** **@CodePotrick** ^1860100329179873769
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 Ideally you'd avoid any float ops as long as you can to keep things in sgprs if you need to save registers/want the uniformity.
 
 If you need float ops on that var its probably best to keep it in vgprs if the alternative would be to transfer between sgpr and vgpr a lot
 
-**13/** @AgileJebrim
+**13/** **@AgileJebrim** ^1860100492610928989
 
-@CodePotrick @NOTimothyLottes
+**@CodePotrick** **@NOTimothyLottes**
 
 I wish I could work solely with integers all the time but if I did that on NV hardware, I’d be losing half the available ALUs.
 
-**14/** @AgileJebrim
+**14/** **@AgileJebrim** ^1860100610164687251
 
-@CodePotrick @NOTimothyLottes
+**@CodePotrick** **@NOTimothyLottes**
 
 I haven’t looked closely at AMD hardware since I don’t work with it much.
 
-**15/** @CodePotrick
+**15/** **@CodePotrick** ^1860101759794053178
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 they have their actual isa public and inspectable which is really nice to know whats actually happening.
 
@@ -128,9 +128,9 @@ Rga is also really good. Feels like im more in control with amd compared to nvid
 
 Maybe thats just the low level gremlin in my speaking tho ;).
 
-**16/** @AgileJebrim
+**16/** **@AgileJebrim** ^1860102030012088350
 
-@CodePotrick @NOTimothyLottes
+**@CodePotrick** **@NOTimothyLottes**
 
 I do have access to some of NVIDIA’s NDA documentation and tools…
 
diff --git a/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/index.md b/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/index.md
index 00062d5..d2092f5 100644
--- a/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/index.md
+++ b/archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/index.md
@@ -25,50 +25,50 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1859788005445414927
 
 Sometimes you only want to wave-coherent branch to something extremely rarely. There is no good way in GLSL to describe that. You always get one branch and one disruption of the linear path [RED]. What you want is [GREEN], common path is linear and branch-free. Gotos would enable
 
 ![](https://pbs.twimg.com/media/Gc9K3dEXIAA7tGy?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1859788598058602843
 
 In theory wave-coherent branch hint and then providing say a 99% taken branch taken compile hint could enable a compiler to know how to do proper code gen here
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1859789099005247518
 
 The other thing, if you know a path is always taken by some of the lanes, and thus on AMD you want NO branches, and instead just EXEC changing, there is no way to express that either. Doing mix(,,bool) could add extra overhead vs simple EXEC masking
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1859789847965335614
 
 This second example is why you want to be able to mix 'always-lane-divergent' branch hint, with '50% probability' meaning the HW needs to always execute both paths, and thus use EXEC masking without physical branching (assuming a good compiler)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1859791162091110754
 
 Also the lack of an explicit 'scalar' (aka SGPR) qualifier on variables. The compiler gets this wrong, a qualifier just fixes that problem. Non-SGPR platforms can just ignore the qualifier. And sgpr=readlane(maybeSgpr,0) can sometimes actually become a readlane (fail)
 
 Branches: [[archive/threads/NOTimothyLottes/2024-11-22-sometimes-you-only-want-to-wave-coherent-branch/2024-11-22-AgileJebrim-shouldnt-uniform-be-a-scalar]]
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1859791605613658307
 
 Other big thing on AMD's PC side, the HW has all these nice SALU ops which set the SCC (scalar flags register), and there is no good way to trick the compiler to doing basic stuff like branch on SALU overflow ...
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1859792310562848906
 
 I tried using GLSL's uaddCarry() but it at the time pushed the whole operation from SALU back to VALU making the code extra horrible, and uaddCarry() and friends = basic fail, the carry is a bool in HW not an integer, silly lack of good pattern matching there applies
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1859793686055485858
 
 Anyway this stuff is easily fixable if people just actually cared about it. It's not like you need to scrap the API or invent a new language. Just fix what we have, and people like me will use it, and teach others how to use it well too.
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1859794597250990335
 
 Also for obvious reasons, at least provide a PRAGMA "not-stupid" that we can place in shaders to avoid all the overhead generating crap that deoptimizes code to check for junior programmer mistakes at runtime, this stuff is bloody hard (and sometimes) impossible to bypass today
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1859796414622204412
 
 Lets add another thing, if(subgroupElect()){} to try to make stuff SALU is broken. Because subgroupElect() will do all the overhead to find the lowest active lane (even in cases the compiler should know otherwise). And if(gl_SubgroupID==0) for that also isn't well optimized
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1859798200141611061
 
 Maybe another time we should dive into the problems with shading languages mixing branching with loads and killing all the latency hiding. But too much for this thread...
diff --git a/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/2024-12-16-axelgneiting-im-well-aware-its-really-curious-they-still-stick.md b/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/2024-12-16-axelgneiting-im-well-aware-its-really-curious-they-still-stick.md
index 861c2c0..b0ec59e 100644
--- a/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/2024-12-16-axelgneiting-im-well-aware-its-really-curious-they-still-stick.md
+++ b/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/2024-12-16-axelgneiting-im-well-aware-its-really-curious-they-still-stick.md
@@ -26,9 +26,9 @@ parent_post_id: "1868492851170205803"
 
 ## Branch
 
-**1/** @axelgneiting
+**1/** **@axelgneiting** ^1868503435299205194
 
-@NOTimothyLottes @kechogarcia
+**@NOTimothyLottes** **@kechogarcia**
 
 I'm well aware. It's really curious they still stick to this design after so many years.
 
diff --git a/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/index.md b/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/index.md
index e02d18a..df0c4cf 100644
--- a/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/index.md
+++ b/archive/threads/NOTimothyLottes/2024-12-15-buffer-zoo-is-more-about-the-silly-season-of/index.md
@@ -25,41 +25,41 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1868444111390249140
 
 "Buffer zoo" is more about the silly season of things needed on the Vulkan shader side to do what you actually want which is just get instruction intrinsics. Just the layout and SSBO aliasing (below) hints at brutal stupid API/shader design
 
 ![](https://pbs.twimg.com/media/Ge4LfQvWwAAwgwz?format=png&name=orig)
 
-**2/** @kechogarcia
+**2/** **@kechogarcia** ^1868450660485919082
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Dxc hlsl sm 6.5 lets you index into ResourceDescriptorHeap directly and cast to whatever resource type. That and mutable vulkan descriptors, you wouldn't need to go the buffer Zoo route.... But then dxc spirv ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1868466254849212427
 
-@kechogarcia
+**@kechogarcia**
 
 Read<32,64,128>(uint64_t base, uint32_t offset, uint32_t immediate, uint32_t cacheControl, uint32_t format);
 
 And be done with this stupid mess
 
-**4/** @axelgneiting
+**4/** **@axelgneiting** ^1868487894169796789
 
-@NOTimothyLottes @kechogarcia
+**@NOTimothyLottes** **@kechogarcia**
 
 NVidia can't just do random format conversions without it being a texture descriptor I thought?
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1868492072166326484
 
-@axelgneiting @kechogarcia
+**@axelgneiting** **@kechogarcia**
 
 Can get the non-conversion {signed/unsigned short/int/long and half/float/double, of {1-4} components}. Which is good enough to start the interface. Then yes for NV you'd need to alias via a storage_texel_buffer to get {10:11:11,10:10:10:2,<u/s>norm*}
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1868492851170205803
 
-@axelgneiting @kechogarcia
+**@axelgneiting** **@kechogarcia**
 
 Then there are rough edges to TEXEL_BUFFER
 
diff --git a/archive/threads/NOTimothyLottes/2024-12-15-the-real-buffer-zoo-problem-with-vulkan-is/index.md b/archive/threads/NOTimothyLottes/2024-12-15-the-real-buffer-zoo-problem-with-vulkan-is/index.md
index 085260c..6a1421d 100644
--- a/archive/threads/NOTimothyLottes/2024-12-15-the-real-buffer-zoo-problem-with-vulkan-is/index.md
+++ b/archive/threads/NOTimothyLottes/2024-12-15-the-real-buffer-zoo-problem-with-vulkan-is/index.md
@@ -25,10 +25,10 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1868435545736782009
 
 The real "buffer zoo" problem with Vulkan is needing to make your HW instruction emulation macros with overcomplete both {offset, and index} inputs so the emulation can choose the correct one based on whatever crap path is required {SSBO, TEXEL_BUFFER, future pointer}
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1868436190447432064
 
 TEXEL_BUFFER is needed for whatever formats one cannot load from SSBOs, and both of those require 'indexes', and whenever the IHVs actually correctly optimize the pointer extension, one needs the byte offsets instead. So deadcode removal nightmare land wins today :(
diff --git a/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md
index 627a265..550bf74 100644
--- a/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md
+++ b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess.md
@@ -26,9 +26,9 @@ parent_post_id: "1868716773937414589"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1868717227866046808
 
-@NOTimothyLottes @GustavSterbrant
+**@NOTimothyLottes** **@GustavSterbrant**
 
 Fair enough. Current compilers are a bloated mess anyways and you’d get much faster times with your own assembler.
 
diff --git a/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md
index ce18ee4..901fad6 100644
--- a/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md
+++ b/archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/index.md
@@ -25,27 +25,27 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1868712285675671711
 
-@GustavSterbrant
+**@GustavSterbrant**
 
 So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched. Most of the problems I see cannot be fixed just by bypassing GLSL and doing SPIR-V directly. So not yet tempted to write a new SL
 
-**2/** @AgileJebrim
+**2/** **@AgileJebrim** ^1868714338418315659
 
-@NOTimothyLottes @GustavSterbrant
+**@NOTimothyLottes** **@GustavSterbrant**
 
 If you’re targeting a console with AMD hardware, why don’t you just rewrite the backend compiler? I assume you have the source for it too, so it’s more tweaking an existing compiler than anything else?
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1868716505325879612
 
-@AgileJebrim @GustavSterbrant
+**@AgileJebrim** **@GustavSterbrant**
 
 At-home stuff (aka non-employer) targets Vulkan Windows mostly (unfortunately). No interface in AMD's Windows driver to load binary shaders into Vulkan. If SteamOS ever fully took over PC gaming, then certainly I'd just go direct to the AMD kernel driver and bypass user-mode VK
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1868716773937414589
 
-@AgileJebrim @GustavSterbrant
+**@AgileJebrim** **@GustavSterbrant**
 
 Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family.
 
diff --git a/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/2024-12-21-AgileJebrim-have-you-tried-using-the-intel-cache-controls.md b/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/2024-12-21-AgileJebrim-have-you-tried-using-the-intel-cache-controls.md
index fbbc9ac..6207f6c 100644
--- a/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/2024-12-21-AgileJebrim-have-you-tried-using-the-intel-cache-controls.md
+++ b/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/2024-12-21-AgileJebrim-have-you-tried-using-the-intel-cache-controls.md
@@ -26,21 +26,21 @@ parent_post_id: "1870343645926224197"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1870345628531999121
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Have you tried using the Intel cache controls extension I shared earlier to see if they work on AMD?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1870353630047686764
 
-@AgileJebrim
+**@AgileJebrim**
 
 Not enough free time. Given that AMD's compiler has some serious correctness bugs ignoring memory qualifiers, I doubt they implemented the Intel extension.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1870354508271763698
 
-@AgileJebrim
+**@AgileJebrim**
 
 Will say though that if they ever implement a WMMA access extension (I don't know if they did or didn't yet), and they don't have streaming memory qualifier support they are just shooting their own AI stock$$$ gold rush foot off.
 
diff --git a/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/index.md b/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/index.md
index 60074bb..bc30f7d 100644
--- a/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/index.md
+++ b/archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-atomic-workaround-im/index.md
@@ -25,17 +25,17 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1870342724538204320
 
 Hopefully with this last atomic workaround I'm almost done with cleaning and fixing the 'bind-everything-once' style Vulkan engine design. Work in progress in the images that follow. Setting up the macros to get all the format aliasing is well quite ugly.
 
 ![](https://pbs.twimg.com/media/GfTKfZpWMAAifu3?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1870342953996288347
 
 I end up doing a lot of duplication via macros since memory qualifiers are on the layout aliasing (instead of an argument to the operation like they should be) ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1870343645926224197
 
 Vulkan is missing the streaming qualifiers, but I write the code like they exist for future compat
 W ... writeonly coherent (all writes)
@@ -52,67 +52,67 @@ Branches: [[archive/threads/NOTimothyLottes/2024-12-21-hopefully-with-this-last-
 
 ![](https://pbs.twimg.com/media/GfTMGj2WcAAoneG?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1870344537027092983
 
 Texture layout aliasing is well the easy stuff since it's just readonly effectively
 
 ![](https://pbs.twimg.com/media/GfTMbIVXEAAqSaA?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1870345116373676163
 
 STORAGE_TEXEL_BUFFER is well complex for aliasing and how to best use. Here is what I'm doing for setup (macro heavy). I have a define for each format descriptor index if I want to reorder them by usage for better cache layout. I only keep 32/64/128 bit types
 
 ![](https://pbs.twimg.com/media/GfTM36hXwAANxQl?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1870345417587614054
 
 I didn't put in support for 16-bit <U,S>NORM yet because  it tends not to get used (bad match for FP16). Likewise no buffer access to 9E5 or sRGB due to HW portability support issues
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1870346478729765374
 
 So todays HW
 (1.) At least for AMD buffer atomics get the signage from the OPCODE so in theory one can use a UINT32 typed TEXEL buffer with both aliased as r32ui and r32i
 
 ![](https://pbs.twimg.com/media/GfTOBhyWEAAmNzY?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1870346962945359928
 
 (2.) No buffer compression HW, so unlike images, there is no point in using separate types if the layout aliasing trick works. One could get by with just 32/64/128 bit type descriptors and extra ones for anything with format conversion
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1870347429104492943
 
 (3.) In cases like <FP16,UINT16>x<2,4> actually probably better to alias those at UINTx<1,2> because then one is sure the compiler doesn't screw up the implicit NOPing of the undo the the format conversion!
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1870348327763542515
 
 (4.) There is a strong desire to keep the number of descriptors down to avoid extra work in SMEM ops and extra SGPR pressure. So that also favors aliasing.
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1870348575181295969
 
 (5.) Ideally I'd want TBUFFER support with the HW grabbing the index width from the type in the opcode instead of the descriptor (but I don't think the HW does that, so probably would always need 3 descriptors minimum).
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1870349164405567671
 
 (6.) The future? Image compression relies on having the right type info in the descriptor to choose the right compression mode for decorrelation of the data. What happens if GPUs get buffer compression some day and everyone is just type aliasing all the time like SSBOs do?
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1870349929136201894
 
 (7.) What is the "right answer"? Even signed vs unsigned could be important for data decorrelation. Certainly float vs int is. But no one wants to burn perf today based on a guess of what is needed in an unknown future.
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1870350304878711133
 
 (8.) So my compromise is to have all the types, but write the code to use type aliasing (the fast path on todays HW) when I don't think data compression would help. And only use the right type (slower) if there is a prediction it might help some day if buffer compression shows up
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1870350758744363037
 
 (9.) In cases where I need compression today, then I use explicit 2D images (assuming 1D images don't get compression on some HWs). But note this is not great, because often I need that data back in SGPRs (expensive, SMEM doesn't to image loads)
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1870351434216329453
 
 Combining the STORAGE_TEXEL_BUFFER tricks (for something a good compiler could optimize from last week or so), I'm down to a few hundred macros for STB access. Showing a few here. It's ugly but the only way to actually implement well.
 
 ![](https://pbs.twimg.com/media/GfTSkwZWIAAgV-q?format=png&name=orig)
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1870351985855119449
 
 Not sure if this is the end of this story yet, but hopefully the holidays I get this back online and can get back to using it. Probably have it down to as optimal as it can get while being as portable and future looking as possible
diff --git a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-04-marc_b_reynolds-its-pretty-amazing-how-good-the-hastings.md b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-04-marc_b_reynolds-its-pretty-amazing-how-good-the-hastings.md
index 0df8ba7..5ab39df 100644
--- a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-04-marc_b_reynolds-its-pretty-amazing-how-good-the-hastings.md
+++ b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-04-marc_b_reynolds-its-pretty-amazing-how-good-the-hastings.md
@@ -26,9 +26,9 @@ parent_post_id: "1875589737282679108"
 
 ## Branch
 
-**1/** @marc_b_reynolds
+**1/** **@marc_b_reynolds** ^1875646616818139275
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 It's pretty amazing how good the Hastings approximations still are.  I'd note that they are designed for minimizing absolute error which isn't what you'd want for general purpose usage but it's the right answer for "all angles are equally important" problems.
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-JBrooksBSI-some-optimization-ideas-1-for-rdna2-simd-insn.md b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-JBrooksBSI-some-optimization-ideas-1-for-rdna2-simd-insn.md
index 34e80a2..5f566a4 100644
--- a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-JBrooksBSI-some-optimization-ideas-1-for-rdna2-simd-insn.md
+++ b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-JBrooksBSI-some-optimization-ideas-1-for-rdna2-simd-insn.md
@@ -26,9 +26,9 @@ parent_post_id: "1875583660545732960"
 
 ## Branch
 
-**1/** @JBrooksBSI
+**1/** **@JBrooksBSI** ^1876298864736801016
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Some optimization ideas:
 
@@ -38,15 +38,15 @@ Some optimization ideas:
 
 3) If FP16 range is ok, gives 2x VALU speed
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1876329313668366624
 
-@JBrooksBSI
+**@JBrooksBSI**
 
 Lack of ABS modifiers on V_PK ops basically kills FP16 benefit here unfortunately. I do unroll when not VGPR limited (favorite optimization). Wary though of SALU/VALU crossings due to latency + scheduling behavior (loss of operand cache, etc). VCC probably has special forwarding
 
-**3/** @JBrooksBSI
+**3/** **@JBrooksBSI** ^1876355942960570458
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I did an approx equal-area mapping to a 2D texture in 2018
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-pixelmager-i-was-looking-at-a-very-similar-problem-for-hemi.md b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-pixelmager-i-was-looking-at-a-very-similar-problem-for-hemi.md
index f09fe50..38cd96e 100644
--- a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-pixelmager-i-was-looking-at-a-very-similar-problem-for-hemi.md
+++ b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-pixelmager-i-was-looking-at-a-very-similar-problem-for-hemi.md
@@ -26,9 +26,9 @@ parent_post_id: "1875589737282679108"
 
 ## Branch
 
-**1/** @pixelmager
+**1/** **@pixelmager** ^1876239280529633476
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I was looking at a very similar problem for hemi-octahedrons recently. I definitely need to revisit in the context of this EAM paper, I ended up with a pretty slow polar-coordinate-remapping instead to move precision to the horizon https://www.shadertoy.com/view/wsBXzD
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/index.md b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/index.md
index ba243ce..c70070d 100644
--- a/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/index.md
+++ b/archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1875582899996782889
 
 For the love of octahedrons: https://fileadmin.cs.lth.se/graphics/research/papers/2008/simdmapping/clarberg_simdmapping08_preprint.pdf
 
@@ -33,7 +33,7 @@ Mapping this well to the GPU follows ...
 
 ![](https://pbs.twimg.com/media/GgdoSaxXYAAwbTz?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1875583660545732960
 
 At some point the standard Octahedron mapping leaves a lot to be desired due to highly variable texel sizing, so have been using that paper's equal area mapping instead. Spent some time optimizing today, got to this which is in theory just 31ops for the 2D to 3D transform
 
@@ -41,29 +41,29 @@ At some point the standard Octahedron mapping leaves a lot to be desired due to
 
 Branches: [[archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-JBrooksBSI-some-optimization-ideas-1-for-rdna2-simd-insn]]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1875584449674637486
 
 AMD's latest driver actually does mostly a good job compiling that (32 op clocks compiled, just 1 more instruction somewhere). I'm surprised actually it's now picking up 'cos(x*2pi)' and pattern matching that to just V_COS_F32!
 
 ![](https://pbs.twimg.com/media/Ggdp6iCWcAAYubj?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1875585990687125782
 
 And the inverse which should also be around 32 op clk (VALU). This uses the Horner form for the papers atan approximation. Could perhaps make that less or more accurate if desired.
 
 ![](https://pbs.twimg.com/media/GgdrTPnWYAABHUm?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1875586260875800870
 
 AMD's compiler also does a good job there.
 
 ![](https://pbs.twimg.com/media/GgdrucxXQAAPQfe?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1875587579938242661
 
 If AMD evolved to a fused floating point compare and select instead of a separate V_CMP* and V_CNDMASK_B32, it would shave a few cycles. Also if they could push 2 results into a result cache in 1 clk, doing the MIN and MAX in one op would shave a cycle.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1875589737282679108
 
 Related> Great ref for fast atan2: https://mazzo.li/posts/vectorized-atan2.html
 I'm using the simplest form from the 1955 paper in horner form scaled by /pi for cylindrical view projection code
diff --git a/archive/threads/NOTimothyLottes/2025-01-06-one-of-the-downsides-of-v-cndmask-b32-on-amd-is/index.md b/archive/threads/NOTimothyLottes/2025-01-06-one-of-the-downsides-of-v-cndmask-b32-on-amd-is/index.md
index 2b4c703..4d2230f 100644
--- a/archive/threads/NOTimothyLottes/2025-01-06-one-of-the-downsides-of-v-cndmask-b32-on-amd-is/index.md
+++ b/archive/threads/NOTimothyLottes/2025-01-06-one-of-the-downsides-of-v-cndmask-b32-on-amd-is/index.md
@@ -25,38 +25,38 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1876093937632600106
 
 One of the downsides of V_CNDMASK_B32 on AMD is that you burn the SGPRs on the VCC bool, so if you are selecting between constants, those require extra V_MOV_B32 ops. Would be much better to have fused cmp+mask so this limitation would be lifted!
 
 ![](https://pbs.twimg.com/media/Ggk5dIQWkAAoCWn?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1876095947752841242
 
 Another night, another round of AMD compiler bugs. Sometimes AMD fails 'uint32_t packFloat2x16(f16vec2 v)' ... I'm seeing the 16-bit MSB cleared in this constant (yeah it's the slow V_CNDMASK_B32 case in the prior tweet)
 
 ![](https://pbs.twimg.com/media/Ggk7SBBXQAAJNbo?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1876096561941475619
 
 Workaround is to use 'pack32(halfBitsToUint16(a))' instead (ie first convert the packed 16-bit float to packed 16-bit integer, then convert to 32-bit integer) ...
 
 ![](https://pbs.twimg.com/media/Ggk72RLXEAA0EH5?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1876112593510949253
 
 One of my favorite AMD instructions V_BFI_B32 is unfortunately one that no intrinsic exists for on PC, and one that the AMD compiler often messes up the pattern matching for, sometimes it reduces to {AND,ADD} instead
 
 ![](https://pbs.twimg.com/media/GglKA6nW4AEtOIC?format=png&name=orig)
 ![](https://pbs.twimg.com/media/GglKXy4XcAAA_Og?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1876120138283729159
 
 Just looking at the next 5 lines of disassembly shows another 2 perf bugs: the compiler transforms 3 operations into 5 operations because it cannot handle mixed packed and unpacked stuff. The 2 V_ANDs can be merged, and the LSHL and CVT should just be one op
 
 ![](https://pbs.twimg.com/media/GglQsALXYAAEfWI?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1876126316816380333
 
 No way to work around those problems. Looks like bitfieldExtract 'v4' back-propagates something where the compiler ignores the .y in the packed logic, and then makes a mess of things scalarizing it. BFE only uses the 5-bit LSB of 'v4', so it's safe to leave junk in the other bits
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-09-just-for-fun-started-to-look-into-cardinal-cubic/index.md b/archive/threads/NOTimothyLottes/2025-01-09-just-for-fun-started-to-look-into-cardinal-cubic/index.md
index b84522d..53a1ed9 100644
--- a/archive/threads/NOTimothyLottes/2025-01-09-just-for-fun-started-to-look-into-cardinal-cubic/index.md
+++ b/archive/threads/NOTimothyLottes/2025-01-09-just-for-fun-started-to-look-into-cardinal-cubic/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1877208278632955949
 
 Just for Fun: Started to look into "Cardinal Cubic O-MOMS" for resampling, some refs:
 https://hhoppe.com/proj/filtering/supp/
@@ -33,7 +33,7 @@ https://hhoppe.com/proj/filtering/supp/sample_code.cpp
 The source paper is math salad:
 https://www.ee.cuhk.edu.hk/~tblu/monsite/pdfs/blu0101.pdf
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1877209306476564906
 
 Results are quite nice in repeated reprojection: 
 https://w3.impa.br/~diego/publications/NehHop14.pdf
@@ -42,59 +42,59 @@ Lanczos is of course not stable (if you reproject enough with a fast lanczos app
 
 ![](https://pbs.twimg.com/media/Gg0va37XEAAQz9S?format=jpg&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1877210969203425432
 
 However O-MOMS appears to need a pre-pass on the data before running the simple cubic filter. That simple cubic would otherwise blur bad (no negative lobes). So this is about where I stopped dissecting the math salad, and started looking at the code salad
 
 ![](https://pbs.twimg.com/media/Gg0w_aGWoAAaUif?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1877211650412982754
 
 That prepass seems to work with 9 coefs in 1 dimension. So this starts to look mighty expensive??? for GPU-side implementation (compared to the existing option of limiting lanczos to make it stable).
 
 ![](https://pbs.twimg.com/media/Gg0xjpcXAAEg3cl?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1877211943640965484
 
 Anyway if anyone knows of a less salad-like example of cubic O-MOMS, please post
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1877214488220287067
 
 So if you reproject rotate in linear using a bilinear filter, after 16 reprojections you get this slop (very blurry), which is why the old simple TAA's started to look bad very fast
 
 ![](https://pbs.twimg.com/media/Gg00ZBZXMAAX4bY?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1877215054984036702
 
 Compared to say this with a clamped approximate lanczos (same 16 reprojections, and linear filtering). The min/max for the clamp is of the inner 2x2 quad of the 4x4 filter window
 
 ![](https://pbs.twimg.com/media/Gg008NMXwAA1uiZ?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1877215831995646460
 
 So even after 16 frames, clamped lanczos approximation is already significantly less sharp than source (below). Thing most of the shader TAAs screw up is that even with great reprojection filtering, still need error-correction sharpening on the reprojection to keep it dialed in
 
 ![](https://pbs.twimg.com/media/Gg01iQFW8AAuwBC?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1877216852734005250
 
 Some don't limit the kernel approximation that has negative lobes, because it's not differentiable, leading to the classic trailing edge halo (dark outline typically seen in DLSS2 at least). After close to 64 frames of reprojection (rotation), easy to see that effect
 
 ![](https://pbs.twimg.com/media/Gg02p6SXsAEStmt?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1877217269031317583
 
 Letting that go too long and well it converges to a high contrast black and white mess
 
 ![](https://pbs.twimg.com/media/Gg03IwkXIAAIb97?format=png&name=orig)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1877217718430048745
 
 The non-linear limiter (simple clamping) keeps it mostly stable in color, even if the detail still converged to noodles
 
 ![](https://pbs.twimg.com/media/Gg03eLtWgAA3X7L?format=png&name=orig)
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1877224142950289815
 
 Also if you overcook your negative lobes in the approximation (using the RED curve below), it speeds up the noodling process (that is the same 16 reprojections as prior)
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-22-simple-napkin-analysis-of-that-high-end-crt/index.md b/archive/threads/NOTimothyLottes/2025-01-22-simple-napkin-analysis-of-that-high-end-crt/index.md
index 70c67a0..1e4676b 100644
--- a/archive/threads/NOTimothyLottes/2025-01-22-simple-napkin-analysis-of-that-high-end-crt/index.md
+++ b/archive/threads/NOTimothyLottes/2025-01-22-simple-napkin-analysis-of-that-high-end-crt/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1881908248544166159
 
 Simple napkin analysis of that high-end CRT scalar (monochome one) ... notes about cleaning up the code.
 
@@ -33,17 +33,17 @@ I track state usage throughout the code to ballpark expected max VGPR count. Thi
 
 ![](https://pbs.twimg.com/media/Gh3hVTEXQAAaDT8?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1881908646743097773
 
 So yeah packed 16-bit is the reason complex shaders like this are possible on PC GPUs. It is the way to single pass and avoid multiple trips through DRAM.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1881909208339357745
 
 This code does 2 parallel kernels, but also breaks the computation of each kernel into 4 weighted sums. This is done for 2 reasons: (a.) possibly higher precision, (b.) to enable parallel work to hide VALU latency (ILP)!
 
 ![](https://pbs.twimg.com/media/Gh3iXwJX0AAfa2p?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1881909849006715306
 
 This shader needs roughly
 410 VALU op clocks
@@ -51,30 +51,30 @@ And 253 of those (more than half)
 are in the load latency window
 So this shader will trivially hide a lot of latency without getting to high wave/CU counts
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1881910192495022093
 
 BUT
 Traditionally this has been a curse, because AMD's oldest wave first scheduling breaks down when the oldest is ultra high VALU load without stalls! The other waves often cannot get forward progress to get loads out to debubble the memory sub-system
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1881910835708383328
 
 Worst case (no scaling, no compression) this would use 6-bytes/pixel of bandwidth (damn), and amortize closer to 4-bytes/pixel with scaling. And GPUs have capacity often for 32 VALU op clocks per byte. So this is certain to be VALU bound (410+ VALU clocks)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1881911435691008317
 
 But things like Strix Halo (laptops) are quite a bit more bandwidth starved, so generally I try to stay VALU bound to be friendly towards scaling down
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1881912737896534188
 
 Estimation that something like a 7900 XT would be able to do over 10,000 of these passes at 4K per second, so this technique is good for 480 Hz! Of course I don't have a 7900 XT, and my only working AMD GPU laptop (the other has bad HDMI port) refuses to profile, so numbers later
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1881915941455593681
 
 Writing code (below, note FMA_MIX is the hot ticket for free FP32->FP16 conversion) with instruction intrinsic macros (that unfortunately map to high-level shader code). But it at least enables me to ballpark instruction counts. With one exception I count transcendentals as 4 ops
 
 ![](https://pbs.twimg.com/media/Gh3oMLCXcAErmE-?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1881917527951122766
 
 Can compare guesses with actuals on the disassembly/
 
@@ -82,17 +82,17 @@ Can compare guesses with actuals on the disassembly/
 
 ![](https://pbs.twimg.com/media/Gh3pJhqXUAAgRLb?format=png&name=orig)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1881918542943297646
 
 I use 13 transcendentals so adjusting my 410 count by -13*3 I get 371 VALU ops. The actual shader uses 438 (and is VALU bound) an extra 18% extra slop somewhere. Some of that is that I didn't count the CS swizzle logic (but that won't account for most of the extra 67 ops) ...
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1881919883832959169
 
 Some of the slop, it's not using NSA (this is GFX9), so lots of extra V_MOV_B32s. The gather offsets are packed in an extra VGPR so even if the base {v34,v35} are shared across all the gather4s, it's duplicating those VGPR pairs 8 extra times (no NSA here).
 
 ![](https://pbs.twimg.com/media/Gh3rlnsXcAAgKWR?format=png&name=orig)
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1881923400882647110
 
 GFX9 is Vega, so no NSA here, and 1 SGPR read per operation. It was RDNA1 that introduced the good stuffs (NSA and 2 SGPRs/op).
 
@@ -102,7 +102,7 @@ Can see below cases where 2 SGPRs are needed Vega will introduce extra V_MOV_B32
 ![](https://pbs.twimg.com/media/Gh3vMCgXIAAAAoM?format=png&name=orig)
 ![](https://pbs.twimg.com/media/Gh3vR4UXAAAtGyK?format=png&name=orig)
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1881925349245858028
 
 Now some actual compiler bugs,
 (1.) Vega has V_MAD_MIX, but the compiler won't use it, instead it wastes extra V_CVT_PKRTZ_F16_F32 ops
diff --git a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-bmcnett-my-take-is-similar-but-i-also-feel-that-a-lot-of.md b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-bmcnett-my-take-is-similar-but-i-also-feel-that-a-lot-of.md
index fd0e08c..dc07d81 100644
--- a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-bmcnett-my-take-is-similar-but-i-also-feel-that-a-lot-of.md
+++ b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-bmcnett-my-take-is-similar-but-i-also-feel-that-a-lot-of.md
@@ -26,21 +26,21 @@ parent_post_id: "1883580512171942335"
 
 ## Branch
 
-**1/** @bmcnett
+**1/** **@bmcnett** ^1883581286838919440
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 My take is similar, but I also feel that a lot of processing is best done predictively in parallel across multiple future frames, one SIMD lane per future frame
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1883584542851977240
 
-@bmcnett
+**@bmcnett**
 
 Don't necessarily want to store all predictions raw though. One of the advantages of say simple things like baked directional lightmaps is that one keeps the data for multiple "frames" (or views) in a compressed form until just right before usage, and it's mis-predict safe
 
-**3/** @bmcnett
+**3/** **@bmcnett** ^1883585257292825064
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Yeah, you need to store many prediction outputs in compressed form, with the time dimension being one over which you compress, in addition to whatever spatial dimensions are relevant
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-noop_dev-i-thought-framegen-was-just-an-offspring-of-mpeg2.md b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-noop_dev-i-thought-framegen-was-just-an-offspring-of-mpeg2.md
index 5efe5d1..a147aff 100644
--- a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-noop_dev-i-thought-framegen-was-just-an-offspring-of-mpeg2.md
+++ b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-noop_dev-i-thought-framegen-was-just-an-offspring-of-mpeg2.md
@@ -26,9 +26,9 @@ parent_post_id: "1883591956598845661"
 
 ## Branch
 
-**1/** @noop_dev
+**1/** **@noop_dev** ^1883594247653462329
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I thought framegen was just an offspring of mpeg2 motion prediction, at least how it was in TVs for 15 years.
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-27-Varaquilex-a-visualization-of-said-cold-caches-on-a-cs.md b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-27-Varaquilex-a-visualization-of-said-cold-caches-on-a-cs.md
index 25e3784..aef130d 100644
--- a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-27-Varaquilex-a-visualization-of-said-cold-caches-on-a-cs.md
+++ b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-27-Varaquilex-a-visualization-of-said-cold-caches-on-a-cs.md
@@ -26,41 +26,41 @@ parent_post_id: "1883569959286313322"
 
 ## Branch
 
-**1/** @Varaquilex
+**1/** **@Varaquilex** ^1883999400260931601
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 A visualization of said cold caches on a CS workload from Timothy's GDC 2018 Engine Optimization Hot Lap slides: https://gpuopen.com/wp-content/uploads/2018/05/gdc_2018_sponsored_engine_optimization_hot_lap.pptx
 
 ![](https://pbs.twimg.com/media/GiVPBdfbAAAhqJ8?format=jpg&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1884089289765794145
 
-@Varaquilex
+**@Varaquilex**
 
 Amazingly unfortunate that AMD still doesn't release the tool that those instruction trace captures had been visualized on. It's the best and most useful tool period I've ever seen at any company in the industry.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1884090146183921799
 
-@Varaquilex
+**@Varaquilex**
 
 If they did choose to release it, I'd teach the world how to use it well, for free. For hardcore optimization it is close to ideal. RGP doesn't start to really show you what you need to know to make good hardcore engineering decisions on AMD hardware.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1884091088606249284
 
-@Varaquilex
+**@Varaquilex**
 
 This is a hint for someone like Valve who could take their RADV SQTT (https://www.phoronix.com/news/RADV-SQTT-Profiling-Support) interface and build something truly transformative for GPU shader engineering
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1884091505805262912
 
-@Varaquilex
+**@Varaquilex**
 
 Mix that kind of visualization tool with a good shader compiler (and HW intrinsics) and basically it's the kind of crack a serious GPU shader dev cannot say no too
 
-**6/** @Varaquilex
+**6/** **@Varaquilex** ^1884092156413096069
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 That tool was one of the most insightful tools I have ever used. I do miss it. It would really be awesome to see it released to the public.
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/index.md b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/index.md
index e7249a8..57a2c9a 100644
--- a/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/index.md
+++ b/archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1883566551120670753
 
 Often overlooked aspect of GPU perf scaling
 Shaders run at two rates
@@ -33,78 +33,78 @@ Shaders run at two rates
 (2.) Warm I$ and K$ rate
 You actually need jobs with small wave count to be sharing the same I$ and K$ across waves (cannot be latency sensitive)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1883569276973707397
 
 Big problem with mass amounts of artist graph authored material shaders paired with raster, 
 (1.) More materials
 (2.) GPU kicks work as wide as possible (due to limited ROP queue size)
 Both amplify the amount of cold cache work
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1883569959286313322
 
 Very common to look even at full-screen passes and see quite long first waves/SIMD (cold caches), followed by later warm-cache steady state. As GPUs get huge, it pushes more and more waves into the cold-cache region. Scaling-TAAs do the same by reducing render resolution.
 
 Branches: [[archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-27-Varaquilex-a-visualization-of-said-cold-caches-on-a-cs]]
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1883570605909590084
 
 So quite literally the smaller the GPU (aka mobile), the more possible benefits from scaling-TAAs getting reduced resolution, because the cold-cache effects are minimized, etc. But with say the 5090, scaling-TAAs can drop whole GPU efficiency by a substantial amount
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1883571920211529760
 
 NVIDIA has load prefetch hints (load more lines than required for the load), and AMD should ideally start including the same for both K$ and D$, so one can at least reduce worst case latency. This doesn't solve bandwidth duplication of wide work distribution though.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1883572955529252878
 
 There are a few different perf wins from decoupling shading from raster, one is the reduction of cold cache effects. One can loop through waves of work in the same material shader, without exit, without reload of constants, etc.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1883574057180021045
 
 Decoupled shading moves a subset of the shading data [material lookup] from interpolated (and thus distributed duplication) to non-temporal streaming (no duplication).
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1883574463771676674
 
 Likewise if it's same-material same-wave, aka one wave is looping through a local collection of surface, the remaining non-material sampling (that is interpolated) has a higher likely hood of hitting in the cache [less ultimate duplication of data across the chip]
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1883575590445576272
 
 In modern times with scaling-TAAs and maximum negative mip-bias, by reducing render resolution and maximizing frame rate, one is also minimizing cache reuse. So instead of say shading all the near samples at the same time, each are now divided across perhaps 32 frames
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1883576673381285955
 
 Thus a massive mismatch between data layout and data usage. The data is stored (and compressed) localized and layered (multiple textures/material), but is increasingly being used in an effectively random access. Both scaling-TAAs and RT are guilty here.
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1883579422676320293
 
 Games that rely on a mix of {heavy deferred shading, scaling-TAAs (reduced render res), RT noise reduction, and frame generation} are scaling poorly (bad engineering) and scale as a function of increased {latency, artifacts}
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1883579950051266839
 
 Meanwhile games that are still engineered more like vintage games {high res, low try density, simple baked lightmap textures mostly, MSAA} are scaling relatively well getting high FPS and low latency
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1883580512171942335
 
 Ultimately all of this hints that it would be better if the per-frame workloads are closer to the vintage games (no-TAA, no frame-gen), and instead one amortizes shading into something that "bakes" in realtime amortized across many frames into the vintage style engine data
 
 Branches: [[archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling/2025-01-26-bmcnett-my-take-is-similar-but-i-also-feel-that-a-lot-of]]
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1883587813092069667
 
 All these "AI" spatial-temporal denoise-scaling-TAAs are ultimately just doing really expensive logic to try to reconstruct the surface material properties at high res and local lighting from a blurry/noisy mess then apply the local conditions to the material
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1883588874582298925
 
 Which is perhaps stupid given the games already easily know the exact high-res material properties, why try to "infer" them burning TOps of logic and heating your office.
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1883590137445224708
 
 Scaling-denoise-TAAs do hint thought that perhaps the academic methods games use for BPR and shading are quite lacking in terms of amortization of costs.
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1883590627285409935
 
 Frame-gen when it "works" ok is just an alpha blend between two states. Clearly an engine could be doing that too instead of reshading everything every frame. And an engine could choose when to do that vs something else to avoid artifacts, something a frame-gen cannot do.
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1883591956598845661
 
 Ultimately the industry will choose if to devolve into AI generated slop-ware where IHVs black box more and more of your engine and you get more and more trapped and lazy. Or break out and do something better and control your own destiny.
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-just-raw-spatial-scaling-in-a-custom-resolve.md b/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-just-raw-spatial-scaling-in-a-custom-resolve.md
index 45efaf2..943def6 100644
--- a/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-just-raw-spatial-scaling-in-a-custom-resolve.md
+++ b/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-just-raw-spatial-scaling-in-a-custom-resolve.md
@@ -26,20 +26,20 @@ parent_post_id: "1884282476195110998"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1884283764068737420
 
 Just raw spatial scaling in a custom resolve/
 4xMSAA at 2.25x area is 2.66xAA on edges
 8xMSAA at 2.25x area scale is 5.33xAA on edges
 8xMSAA at 4x area scale is 4xAA on edges <--- bingo
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1884285206024310827
 
 Take 8xMSAA with a view-port jitter pattern (or even PSL) which always maintains the same sample vs axis intersections! <--- double bingo
 
 Sub-pixel detail is now mostly stable, will show up in all frames in the local neighborhood = stable temporally
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1884286098538733671
 
 Bottom line/
 8xMSAA + smart jitter (or PSL)
@@ -49,31 +49,31 @@ ALL in one custom resolve pass
 
 Something one could make temporally stable without ghosting and still maintain 4xAA (on edges at output resolution) on the worst case in disocclusions
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1884286415619645604
 
 It would destroy DLSS4 in terms of classic image quality
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1884287209487876224
 
 Note one can inline something like CAS/RCAS (what I did at AMD) into the custom MSAA resolve, by modulating a negative lobe based on a local min/max kernel's min distance to signal peak {0 or 1}. Meaning it's possible to get really sharp output from this combo.
 
-**6/** @dankbaker
+**6/** **@dankbaker** ^1884304987284795468
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Is there an example shader that does that custom resolve?
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1884316996940251525
 
-@dankbaker
+**@dankbaker**
 
 Probably not in the config you are interested in (I'm assuming spatial with no scaling?) Feel free to DM me. Most of these things need adaption specific to the config. Last one I did was huge spatial scaling for a CRT-styled scalar using this kernel,
 
 ![](https://pbs.twimg.com/media/GiZv5SFWYAAyv2W?format=jpg&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1884318785479598435
 
-@dankbaker
+**@dankbaker**
 
 My project is monochome so the kernel blending logic is single channel, and the content is designed to handle a huge amount of negative lobe well so I don't constrain ringing (BLUE, replace with 'm.y*RINGING'), and everything in linear of course ... but it should provide an idea
 
diff --git a/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-my-mindset-is-more-tuned-towards-rendering.md b/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-my-mindset-is-more-tuned-towards-rendering.md
index e0da2b1..1a9509e 100644
--- a/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-my-mindset-is-more-tuned-towards-rendering.md
+++ b/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-my-mindset-is-more-tuned-towards-rendering.md
@@ -26,15 +26,15 @@ parent_post_id: "1884360689093091618"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1884361733537509538
 
-@MichalDrobot
+**@MichalDrobot**
 
 My mindset is more tuned towards rendering without minSampleShading and using the temporal component to get the shading resolution up since base frame rate will be high anyway. So no soft VRS in my line of thinking either (other than whatever falls out of 8xMSAA render)
 
-**2/** @MichalDrobot
+**2/** **@MichalDrobot** ^1884362974418407807
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 That’s pretty much exactly the mindset and what ended up shipping in Killzone Shadow Fall (4xMSAA -> 2x scaling + TAA) and in FarCry4 8xMSAA FMask only + analytical resolve + TAA
 Doing sub samples in FC4 was challenging due to all that AT foliage.
diff --git a/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/index.md b/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/index.md
index 0378871..d0cddce 100644
--- a/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/index.md
+++ b/archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/index.md
@@ -25,89 +25,89 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1884282476195110998
 
 So we (the industry) really ever went back to the MSAA based TAA combinations and applied everything we learned in the past decade ...
 
 Branches: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-just-raw-spatial-scaling-in-a-custom-resolve]]
 
-**2/** @MichalDrobot
+**2/** **@MichalDrobot** ^1884350003621122456
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Hey that’s literally what our VRS is doing with all those tricks and more. We just don’t call it an upsampler ; )
 On PC we resolve MSAA to texture2DArray to retain plane separation benefits for bandwidth and coherency
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1884353921529098377
 
-@MichalDrobot
+**@MichalDrobot**
 
 Larger differences are
 (1.) Your VRS is PSL'ing to a regular grid? (need the actual 8x pattern for what I'm suggesting)
 (2.) Sounds like you are getting benefit from FMASK due to the soft VRS, but for what I'm suggesting the NV flat+DCC layout is way better
 
-**4/** @MichalDrobot
+**4/** **@MichalDrobot** ^1884354832561062036
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 1) it’s 4xMSAA but we DRS only on X axis which is matching your case I believe. Similar how it was done it Killzone Shadowfall.
 8xMSAA we could explore XY scaling
 2) depends. On PC it’s flat /w DCC. On gen8 it’s fmask packed. Gen9 is FMask with DCC plane0/1
 
-**5/** @MichalDrobot
+**5/** **@MichalDrobot** ^1884355267732631588
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 But sure I agree that 8x is the way to go for 4K. Our challenge is that we still have gen8 with 1k target and at those resolutions 8x scales really sub linear due to quad occupancy
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1884360689093091618
 
-@MichalDrobot
+**@MichalDrobot**
 
 I guess the question then is if you implement variable spatial scaling in the custom resolve, is the 8xMSAA loss something that can easily be covered by increased spatial scale on the low end HW? 8x area scaling at 8xMSAA is still likely good for 3xAA on edges at spatial-only
 
 Branches: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-my-mindset-is-more-tuned-towards-rendering]]
 
-**7/** @MichalDrobot
+**7/** **@MichalDrobot** ^1884361420827156678
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 If low end hw is decent with MSAA AND you can control triangle density effectively to combat quad occupancy loss (we can’t) - that’s the best there is imo.
 FWIW that’s why we use stencil even for geo edges for MSAA - because we get too many interior edges that don’t do anything
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1884363102520803783
 
-@MichalDrobot
+**@MichalDrobot**
 
 I see, yes once authoring pushes tri/pix density then what makes sense changes. I was thinking more of the way things had been authored in the relief mapping era.
 
-**9/** @MichalDrobot
+**9/** **@MichalDrobot** ^1884363859089092688
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Then you need invest heavily into visbuffer for “simple draws” and pay setup price to compensate those deficiencies.  involved pipeline that is not portable
 I can totally see your plan working for specific art styles or more retro gaming. There is a huge Indy market for this
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1884367100245938321
 
-@MichalDrobot
+**@MichalDrobot**
 
 If tri/pix density is high, even if there are some huge triangles left, without substantially good multi-scale LOD (meaning cluster count scaling), I think soft culling alone falls off the !/$ curve for scaling - hints perhaps past the crossover for non-triangle rendering
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1884367910606450855
 
-@MichalDrobot
+**@MichalDrobot**
 
 At that stage I'd have transitioned to direct final view reconstruction from object space domain. Walking object space, atomicMin(MSB{z,ref}LSB) at some good enough density into the final projected space, then use a neighborhood of 'refs' to get back to object space neighborhoods
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1884368462056747162
 
-@MichalDrobot
+**@MichalDrobot**
 
 ... for the filtering. One can effectively cancel atomics per lane based on local projected screen-space density to deal with domain stretch (skinning), so it gets to be highly scalable.
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1884368997950304563
 
-@MichalDrobot
+**@MichalDrobot**
 
 The TAA reconstructions all crossed that threshold of cost where it's easy to swap in reconstruction from something other than screen-space. And with no disocclusion trouble, object space is much less of a challenge to go from.
diff --git a/archive/threads/NOTimothyLottes/2025-01-31-comparing-matrix-to-quaternion-code/index.md b/archive/threads/NOTimothyLottes/2025-01-31-comparing-matrix-to-quaternion-code/index.md
index dd0fa53..7df42a4 100644
--- a/archive/threads/NOTimothyLottes/2025-01-31-comparing-matrix-to-quaternion-code/index.md
+++ b/archive/threads/NOTimothyLottes/2025-01-31-comparing-matrix-to-quaternion-code/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1885175713638076657
 
 Comparing matrix to quaternion code:
 (A.) https://d3cw3dd2w32x2b.cloudfront.net/wp-content/uploads/2015/01/matrix-to-quat.pdf
@@ -37,7 +37,7 @@ Anything better than those?
 
 ![](https://pbs.twimg.com/media/Gil71jfXEAAhOJa?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1885182390978429048
 
 The (B.) alternative method might be just 32 VALU clocks on AMD, wrote up the code below (but warning didn't test it yet).
 
diff --git a/archive/threads/NOTimothyLottes/2025-02-04-gelatinous-pixel-soup/index.md b/archive/threads/NOTimothyLottes/2025-02-04-gelatinous-pixel-soup/index.md
index d2c83fa..d8c997f 100644
--- a/archive/threads/NOTimothyLottes/2025-02-04-gelatinous-pixel-soup/index.md
+++ b/archive/threads/NOTimothyLottes/2025-02-04-gelatinous-pixel-soup/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1886572405176345062
 
 __/ "GELATINOUS PIXEL SOUP!" \__
 Another spicy Threat Interactive video
@@ -34,7 +34,7 @@ https://www.youtube.com/watch?v=KEtb0punTHk
 Someone willing to challenge the status quo
 Lets talk about some of his topics ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1886573153826038114
 
 Finally someone posting ms/frame breakdown!
 Appears to be using an actual mid-range GPU
@@ -46,7 +46,7 @@ Even at 60Hz you'd be giving up the majority of your frame budget to AI
 
 ![](https://pbs.twimg.com/media/Gi50Il6XwAAHdo2?format=jpg&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1886574332505198960
 
 [ORANGE]
 Transformer model being almost 2x the cost of the prior CNN model. Double the cost for less ghosting.
@@ -55,11 +55,11 @@ Note STP (non-ML) was targeting 1/3 to 1/2 of the cost of that old CNN model wit
 
 ![](https://pbs.twimg.com/media/Gi50lS_WMAEXEZC?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1886578272135504258
 
 It is certainly possible to engineer a bunch of very low cost and high quality human written shader solutions for scaling-TAAs that do better than the ML ones in !/$ for the non-ray-reconstruction cases
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1886580107097080317
 
 NV banking on poorly optimized PC titles though is NOT a new thing: lets rewind to 2012!
 
@@ -71,17 +71,17 @@ Yet NV wins because of game-ready drivers
 
 ![](https://pbs.twimg.com/media/Gi5585sWcAAPpw-?format=png&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1886581250359529845
 
 NVIDIA was always about enabling dev laziness, the RT+AI+Fake era is just the ultimate form of that, where the lazy dev is marginalized to a few % of the total frame budget with AI taking the majority.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1886583358110552360
 
 Others playing "follow-the-leader" unfortunately still didn't catch on to the most important point, that Jensen's plan forces consumers to buy into only high-end cards to fix all the PC game problems. Nothing about the AI future scales down!
 
 ![](https://pbs.twimg.com/media/Gi582LwWMAA4JBz?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1886584084031213672
 
 Jensen's "Low-End" = 5070 is 1/3 the VALU of a 5090 
 
@@ -90,7 +90,7 @@ is 1/19 the VALU and 1/7.6 the bandwidth
 
 Already today, without scaling-TAAs on 5080, many "high-end" PC games either struggle to hit 60Hz at 4K or cannot make it to 120Hz ... ouch
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1886585534115381520
 
 So Jensen's AI future depends on big GPU$$$$
 
@@ -98,44 +98,44 @@ And all other non-NV IHVs and OEMs build substantially smaller GPUs (Apple) or f
 
 Following Jensen's path is suicide, because they won't have the baseline GPU mass required to play
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1886586038870798570
 
 Should feel extra sorry for someone like Qualcomm who though they could just make an RT core and follow the baseline HW requirements, but completely missed the point that NV would just raise the ray-reconstruction cost to a place Qualcomm could never get to
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1886589607846019114
 
 AMD/others can easily extend out 1-fake frame to N-fake frames, and they all have timewarp for VR experience, so doing the fake latency thing is trivial too. And maybe FSR4/etc ML based non-RR scaling-TAAs hit DLSS parity soon
 
 But NVIDIA has already pivoted to ray reconstruction
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1886590953328181652
 
 At the end of the day, it is actually unreasonable to expect IHVs to do anything other than follow NVIDIA if PC engines just eat up RT and get bottle-fed on AI. Even if AMD or anyone makes awesome divergent tech, if it isn't mass market engine adoption it will go no where
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1886592037329289661
 
 Likewise how can we expect major AAA engines to take on the uncertainty and insane R&D challenge of getting off their current NV evolution paths and do something radically different, it's just too high risk
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1886592291030126732
 
 So the industry is somewhat in a live lock condition where it won't make forward progress
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1886597785148924309
 
 Related story. So the reason I left AMD for Unity was because Unity was spinning up an R&D team for scalable high-end graphics. And our target was mobile through high-end PC. And left alone we would have got there. But the stock crashed and we got axed or forced out.
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1886602718900359233
 
 I think ultimately those in the industry who don't like the current status quo, it's on you to build the tech yourself and ship it in an game to prove it is possible. Because it isn't likely that anyone has the pockets deep enough to fund a new general purpose engine on risky R&D
 
-**17/** @0xpatrickhan
+**17/** **@0xpatrickhan** ^1886699325553828171
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 What are some problem areas you think need to be tackled? I’ve read some of what you’ve written in response to some of the gripes of modern day temporal supersampling/AA. What else? Anything that IHVs would be uniquely positioned to do?
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1886741205423128997
 
-@0xpatrickhan
+**@0xpatrickhan**
 
 There is a laundry list of things IHVs dont expose or expose very poorly for basic compute shaders, making it quite difficult or impossible to get a compiler to do the right thing. Fix those and devs like myself could easily build better than AI tech options
diff --git a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-could-a-shader-compiler-not-do-this-i-e-detect.md b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-could-a-shader-compiler-not-do-this-i-e-detect.md
index 3c9b929..8b73ba4 100644
--- a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-could-a-shader-compiler-not-do-this-i-e-detect.md
+++ b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-could-a-shader-compiler-not-do-this-i-e-detect.md
@@ -26,15 +26,15 @@ parent_post_id: "1912477061467304351"
 
 ## Branch
 
-**1/** @BoganBits
+**1/** **@BoganBits** ^1912556384572653833
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Could a shader compiler not do this?  i.e. detect such inefficient code, and "re-vectorise" it, so to speak i.e. have each shader instance do 2 at once, interleaved
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1912564973638726123
 
-@BoganBits
+**@BoganBits**
 
 This is something to be done at the dispatch level, not something a compiler knows about
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-i-would-be-interested-to-see-a-concrete-example.md b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-i-would-be-interested-to-see-a-concrete-example.md
index 1a1c337..b9d5b8e 100644
--- a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-i-would-be-interested-to-see-a-concrete-example.md
+++ b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-i-would-be-interested-to-see-a-concrete-example.md
@@ -26,16 +26,16 @@ parent_post_id: "1912477061467304351"
 
 ## Branch
 
-**1/** @BoganBits
+**1/** **@BoganBits** ^1912555483317313711
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I would be interested to see a concrete example of this
 ideally with a benchmark to show the improvement
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1912564424990163114
 
-@BoganBits
+**@BoganBits**
 
 Early STP had a mode to pipeline the dependent passes, that was back when it was being developed out of Unity. That mode was way faster. But later it was removed because Unity wouldn't allow resources bound for read+write at the same time = fail.
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-DjMolehill-branching-cache-locality-and-memory-handling-are.md b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-DjMolehill-branching-cache-locality-and-memory-handling-are.md
index c73436c..f87f61f 100644
--- a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-DjMolehill-branching-cache-locality-and-memory-handling-are.md
+++ b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-DjMolehill-branching-cache-locality-and-memory-handling-are.md
@@ -26,9 +26,9 @@ parent_post_id: "1912484261321392231"
 
 ## Branch
 
-**1/** @DjMolehill
+**1/** **@DjMolehill** ^1912507659494035701
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 branching, cache locality, and memory handling are key 🔥
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-JBrooksBSI-id-add-standardized-documented-isa-that-enables.md b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-JBrooksBSI-id-add-standardized-documented-isa-that-enables.md
index 9d65292..ed763d0 100644
--- a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-JBrooksBSI-id-add-standardized-documented-isa-that-enables.md
+++ b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-JBrooksBSI-id-add-standardized-documented-isa-that-enables.md
@@ -26,9 +26,9 @@ parent_post_id: "1912483968563269946"
 
 ## Branch
 
-**1/** @JBrooksBSI
+**1/** **@JBrooksBSI** ^1912487286190797257
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I'd add:
 
@@ -36,35 +36,35 @@ Standardized, documented ISA that enables compatibility across multiple GPU gene
 
 WGP (WorkGroup Processor) mode which doubles the # of SIMD units executing a single threadgroup, halving latency for bottleneck operations.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1912492806150508755
 
-@JBrooksBSI
+**@JBrooksBSI**
 
 Personally I still don't like the WGP+wave32 stuff. Limited dual issue instructions with less operand flexibility (wave64 back to back issue IMO is better, just HW dual pipe transcendentals). WGP's two L0 cache and related resource split issues.
 
-**3/** @JBrooksBSI
+**3/** **@JBrooksBSI** ^1912494958248149451
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 WGP mode and wave32 are separate features. WGP mode schedules waves within a threadgroup across both CUs (4x SIMDs) in each WGP instead of limiting waves to a single CU (2x SIMD).
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1912563170138542436
 
-@JBrooksBSI
+**@JBrooksBSI**
 
 Yeah so it's more the wave32 that I don't like
 
-**5/** @JBrooksBSI
+**5/** **@JBrooksBSI** ^1912585972698710273
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I'd like to discuss this in more detail, as I have found wave32 to be faster than wave64 for everything except some vertex shaders.
 
 I think the reason wave64 can be faster for vertex shaders is that only half the VS waves get launched, so more occupancy for PS/CS waves per WGP.
 
-**6/** @JBrooksBSI
+**6/** **@JBrooksBSI** ^1912589134969073756
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 The reasons Wave64 has been slower for me:
 1) More VGPR pressure = less occupancy
@@ -74,9 +74,9 @@ The reasons Wave64 has been slower for me:
 
 I spot-unroll 2x-4x for more intra-wave parallelism as needed.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1912626987858059469
 
-@JBrooksBSI
+**@JBrooksBSI**
 
 Re
 1) With what I do, high occupancy is often slower
@@ -84,9 +84,9 @@ Re
 3) It's half the K$ loads for wave64
 4) I use DPP16 at most (no dynamic shuffle)
 
-**8/** @JBrooksBSI
+**8/** **@JBrooksBSI** ^1912631441516839042
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Wow, that is wildly different from what I do.
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/index.md b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/index.md
index 476c4a9..3906ba6 100644
--- a/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/index.md
+++ b/archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/index.md
@@ -25,24 +25,24 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1912475720103649326
 
 __/ CS OPTIMIZATION BRAIN DUMPING \__
 (1.) Sometimes branching can disrupt otherwise regular execution flow leading to a performance regression,
 while it might be counter intuitive to always do more work, it can sometimes be faster too ->
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1912476350230786300
 
 WHY> Branching can cause: I$ misses, branch delays, wave switches that kill operand cache, poor register allocation, extra VALU overheads on the rejoin to move VGPRs, and most importantly poor VMEM behavior (not able to hoist out a speculative load earlier)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1912476782592241802
 
 (2.) Time a shader in isolation, tend to see 3 regions of execution: {cold-start, warm-cache, drain} regions.
 Early waves are missing through {I$,K$,L0$}, warm-cache waves have lower runtime.
 
 For this reason it is very important to pipeline (overlap) workloads.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1912477061467304351
 
 Serially dependent workloads should be broken up spatially and pipelined!
 
@@ -50,31 +50,31 @@ I've never seen a dev do this correctly (look at their serially dependent post p
 
 Branches: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-i-would-be-interested-to-see-a-concrete-example]], [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-BoganBits-could-a-shader-compiler-not-do-this-i-e-detect]]
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1912477911799509324
 
 (3.) If a shader is only going to run a small number of waves on say one CU (like a material used on a few pixels) then budget bandwidth for it's full {shader and constants} (which might be more costly than the textures themselves).
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1912480275612712963
 
 (4.) Back to {cold,warm,drain} -> for small workloads or large 'cold/drain-region' workloads, it is better to force that onto one CU and loop through work (semi or full) persistent waves, to ensure high cache locality and reuse.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1912480566789743035
 
 ... Note, might want to use large CU filling workgroups, because single-wave workgroups might get tossed on different low-level caches.
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1912481048237080840
 
 (5.) For what should be VALU bound stuff, usually the problem on AMD is locally clustered VMEM caused by oldest first scheduling, causing memory bubbles. What you really want is steady VMEM keeping memory working well in parallel with execution ...
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1912481807489982756
 
 ... This can be very hard to fix. Sometimes you need to use more VALU to decode better compressed data to go faster (counter intuitive), or even reduce the waves running in parallel (for better cache/wave ratio) [also counter intuitive] ...
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1912482284181115211
 
 There are shader source level transforms which can help too. Meaning you might see a difference batching say by groups of 2x2 (part kernel) instead of say the full kernel size. Yes sometimes the shader compiler will radically re-order, other times not (depends on VGPR pressure)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1912483968563269946
 
 (6.) The two most important things AMD ever did IMO to their architecture
 (a.) Packed 16-bit (with double rate)
@@ -83,7 +83,7 @@ There are shader source level transforms which can help too. Meaning you might s
 
 Branches: [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping/2025-04-16-JBrooksBSI-id-add-standardized-documented-isa-that-enables]]
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1912484261321392231
 
 ... The reasons being that it becomes possible to reduce round trips through memory by pass merging and other techniques -> resulting in shaders with massive state fitting in VGPRs without spilling
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-holy-truthnuke-and-people-think-c-is-the-optimal.md b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-holy-truthnuke-and-people-think-c-is-the-optimal.md
index e31538e..ca029c6 100644
--- a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-holy-truthnuke-and-people-think-c-is-the-optimal.md
+++ b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-holy-truthnuke-and-people-think-c-is-the-optimal.md
@@ -26,23 +26,23 @@ parent_post_id: "1917652589358858332"
 
 ## Branch
 
-**1/** @onatt0
+**1/** **@onatt0** ^1917653631651729876
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 holy truthnuke - and people think C is the optimal state of possible runtimes when it's a very limited runtime to have state mixed call/data-stacks
 
 not only you have to keep the whole stack around with replicated state, it limits to serialized execution instead of parallel
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1917656437473399108
 
-@onatt0
+**@onatt0**
 
 I laugh when people say C is like assembly, they are missing what we actually did in assembly back then, which was all registers and globals and gotos, no stacks. It's radically different than good assembly.
 
-**3/** @onatt0
+**3/** **@onatt0** ^1917659010024587634
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 when C became *the* execution model, it restricted all future hardware, HW gets built with how the C compiler will compile to it instead of what's ultimately a good design and a malleable macro-lang to map to HW
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-imo-code-compilation-is-inherently-sequential.md b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-imo-code-compilation-is-inherently-sequential.md
index eba90e8..667d799 100644
--- a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-imo-code-compilation-is-inherently-sequential.md
+++ b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-imo-code-compilation-is-inherently-sequential.md
@@ -26,23 +26,23 @@ parent_post_id: "1917646466417381426"
 
 ## Branch
 
-**1/** @onatt0
+**1/** **@onatt0** ^1917651417487036446
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 IMO code compilation is inherently sequential+ "execution contextual", dynamic logic execution to get the binary as the essence vs a static lang
 
 codegen with execution on GPU could work as 2-items(vreg)/stack and 32K cells per lane for AI to map code to data instead of weights?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1917654997895983255
 
-@onatt0
+**@onatt0**
 
 So for x86 I've many times written code gen with extra nop-prefix padding to fix all instructions to a multiple of known 32-bits. Which means you know in advance sizing of everything, then you can easily do parallel code generation. So need not necessarily all be serial
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1917655990792560843
 
-@onatt0
+**@onatt0**
 
 However I'm often building then instantly using code while generating a baked binary to use later, so that regard much is inherently serially dependent. This bootstrapping technique is perhaps one the great things to learn from things like color forth IMO.
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-simply-brilliant.md b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-simply-brilliant.md
index 998ad60..1341632 100644
--- a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-simply-brilliant.md
+++ b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-simply-brilliant.md
@@ -26,9 +26,9 @@ parent_post_id: "1917653265329594372"
 
 ## Branch
 
-**1/** @onatt0
+**1/** **@onatt0** ^1917654071323857138
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 simply brilliant!
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/index.md b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/index.md
index 315d5b0..0aa8cc4 100644
--- a/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/index.md
+++ b/archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/index.md
@@ -25,23 +25,23 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1917646466417381426
 
-@onatt0
+**@onatt0**
 
 [3] I got side tracked by building a language that could be assembled from on the GPU in SIMD. However now I ask myself if that is just adding "complexity", because if programs are bounded in size, why not just focus on CPU non-parallel nested factoring (aka the forth-like way)
 
 Branches: [[archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-imo-code-compilation-is-inherently-sequential]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1917648900556558768
 
-@onatt0
+**@onatt0**
 
 [4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1917650289978454504
 
-@onatt0
+**@onatt0**
 
 [5] Can do this instead,
 a. Track a "top" register (number)
@@ -49,29 +49,29 @@ b. Use symbols to override top register
 c. Have push (store) just advance top to next reg (in circular queue)
 Gets to easy unnamed arguments
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1917651574354030636
 
-@onatt0
+**@onatt0**
 
 [6] You mentioned VK is most "form filling" which I think is an accurate description. For most "C" like APIs I like to just lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls ...
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1917652037078065160
 
-@onatt0
+**@onatt0**
 
 [7] They key concept here is that "common" arguments like the device are pushed onto the tape using store duplication when they are known (after device creation). So it's preemptive scatter, so later at call time there is no argument gather.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1917652589358858332
 
-@onatt0
+**@onatt0**
 
 [8] Likely the majority of C/C++/OOP/bloatware is just shuffling data around in argument gather to support the concept of data stacks on HW that has no physical data stack.
 
 Branches: [[archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that/2025-04-30-onatt0-holy-truthnuke-and-people-think-c-is-the-optimal]]
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1917653265329594372
 
-@onatt0
+**@onatt0**
 
 [9] Could just pre-layout call arguments in order of usage, leverage data compression at init-time to unpack into memory before run-time. No more code to shuffle arguments, or set registers to immediates, etc. Just a common (cached) pre-call to consume args from the "tape"
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/2025-04-30-NOTimothyLottes-related-thoughts-0-having-a-low-upper-bound-on.md b/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/2025-04-30-NOTimothyLottes-related-thoughts-0-having-a-low-upper-bound-on.md
index 8efc679..1ca380a 100644
--- a/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/2025-04-30-NOTimothyLottes-related-thoughts-0-having-a-low-upper-bound-on.md
+++ b/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/2025-04-30-NOTimothyLottes-related-thoughts-0-having-a-low-upper-bound-on.md
@@ -26,40 +26,40 @@ parent_post_id: "1917613300902146419"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1917642786804785230
 
-@onatt0
+**@onatt0**
 
 Related thoughts/
 [0] Having a low upper bound on the maximum complexity allowed in a program enables so much simplification. One can always move complexity into data, while keeping tight codebases.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1917644904055910502
 
-@onatt0
+**@onatt0**
 
 [1] Seems like you group symbols into pages where each page can have a string (shared with all symbols in the page), which when pared with limited fixed maximum symbol string size, is an elegant way of effectively supporting larger naming [I'll probably steal that idea next time]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1917645859791200562
 
-@onatt0
+**@onatt0**
 
 [2] I'm also a big fan of how you used 16:9 aspect to auto render all the debug info, symbol tables, disassembly, etc, alongside the source. I think many people are probably lost in the speed at which you can manipulate and test ideas while working on the source
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1917646466417381426
 
-@onatt0
+**@onatt0**
 
 [3] I got side tracked by building a language that could be assembled from on the GPU in SIMD. However now I ask myself if that is just adding "complexity", because if programs are bounded in size, why not just focus on CPU non-parallel nested factoring (aka the forth-like way)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1917648900556558768
 
-@onatt0
+**@onatt0**
 
 [4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1917650289978454504
 
-@onatt0
+**@onatt0**
 
 [5] Can do this instead,
 a. Track a "top" register (number)
@@ -67,21 +67,21 @@ b. Use symbols to override top register
 c. Have push (store) just advance top to next reg (in circular queue)
 Gets to easy unnamed arguments
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1917651574354030636
 
-@onatt0
+**@onatt0**
 
 [6] You mentioned VK is most "form filling" which I think is an accurate description. For most "C" like APIs I like to just lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls ...
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1917652037078065160
 
-@onatt0
+**@onatt0**
 
 [7] They key concept here is that "common" arguments like the device are pushed onto the tape using store duplication when they are known (after device creation). So it's preemptive scatter, so later at call time there is no argument gather.
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1917652589358858332
 
-@onatt0
+**@onatt0**
 
 [8] Likely the majority of C/C++/OOP/bloatware is just shuffling data around in argument gather to support the concept of data stacks on HW that has no physical data stack.
 
diff --git a/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/index.md b/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/index.md
index e8700b9..06c2a5c 100644
--- a/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/index.md
+++ b/archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they/index.md
@@ -25,8 +25,8 @@ in_reply_to: "1917653631651729876"
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1917656437473399108
 
-@onatt0
+**@onatt0**
 
 I laugh when people say C is like assembly, they are missing what we actually did in assembly back then, which was all registers and globals and gotos, no stacks. It's radically different than good assembly.
diff --git a/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/2025-07-23-Karyuutensei-where-does-the-restart-number-come-from-i-assume.md b/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/2025-07-23-Karyuutensei-where-does-the-restart-number-come-from-i-assume.md
index 9c8e333..6b9cdcc 100644
--- a/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/2025-07-23-Karyuutensei-where-does-the-restart-number-come-from-i-assume.md
+++ b/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/2025-07-23-Karyuutensei-where-does-the-restart-number-come-from-i-assume.md
@@ -26,9 +26,9 @@ parent_post_id: "1948009807161721332"
 
 ## Branch
 
-**1/** @Karyuutensei
+**1/** **@Karyuutensei** ^1948052805647782109
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Where does the restart number come from? I assume this is how many times you exited the code and started again automatically using your batch script?
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/index.md b/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/index.md
index aa7f88e..b79f2df 100644
--- a/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/index.md
+++ b/archive/threads/NOTimothyLottes/2025-07-23-nobody-self-includes-with-defines-to-reorder-c/index.md
@@ -25,69 +25,69 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1947848281280631267
 
 "nobody self includes with defines to reorder C code" ... Haha, apparently I'm not the only one, the File Pilot guy does it too :)
 
 ![](https://pbs.twimg.com/media/GwgkzCMWsAAnfS7?format=png&name=orig)
 
-**2/** @Karyuutensei
+**2/** **@Karyuutensei** ^1947918274764657130
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Do you also automatically generate the include files or do you just write them yourself?
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1948002273352634482
 
-@Karyuutensei
+**@Karyuutensei**
 
 I only include __FILE__ (self). For WIN32 and VK even, I recreate the parts of external headers I need (use) inside the 'one source file', typically with structural type changes to switch back to simple types like 64 bit intergers instead of pointers. Trying to get to C--
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1948003669942952024
 
-@Karyuutensei
+**@Karyuutensei**
 
 One side effect, even with C code the compilation is perceptually instant for the whole program. The other thing I do is mix the GLSL and C all in the same file, so I share defines. I do have one external include for the compiled SPIR-V ...
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1948004638344573135
 
-@Karyuutensei
+**@Karyuutensei**
 
 For the SPIR-V, I also have one program, but I use specialization constants set at PSO generation to select the code path for a specific 'shader'.  This requires spriv opt as a pre-processor else the IHV compilers tend to be 10x or more slower.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1948006808284500326
 
-@Karyuutensei
+**@Karyuutensei**
 
 During dev time I use 2 terminals each with their own shell scripts. The first is to just loop and keep regenerating the SPIR-V if anything in the 'one file' changes. This is unfortunately a mess to do in a batch file (below)
 
 ![](https://pbs.twimg.com/media/Gwi1pOOW4AEZDE5?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1948007959134392704
 
-@Karyuutensei
+**@Karyuutensei**
 
 The second does the same for the C program, loops recompiling and running the program. So when I'm editing source I can just fast exit the program and it restarts [with instant restart/reload it is quite fast to restart]
 
 ![](https://pbs.twimg.com/media/Gwi23Q9WMAI4Grm?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1948008427080253547
 
-@Karyuutensei
+**@Karyuutensei**
 
 I'm using GCC on Windows, because why bother with having to install Visual Studio or it's compiler tool chain mess. I just do MINGW64 and be done with it. My debugger is the instant restart for C code, and shader reload for GLSL
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1948009807161721332
 
-@Karyuutensei
+**@Karyuutensei**
 
 I don't use standard C libs or anything like that. I just write my own stuff. For 'printf' style debugging I have macros that write to a memory mapped log file. They give {[restartNumber]|[msSinceLaunch]|[sourceLine]|[hex]|[dec]|[comment]}. Keeping multiple restarts in same log
 
 ![](https://pbs.twimg.com/media/Gwi4H27WgAAIgMN?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1948010813555634392
 
-@Karyuutensei
+**@Karyuutensei**
 
 That log example is a simple test program, it starts in 0.3 ms for that run. The log tells all about how it pipelines start up {doing memory page warming, kart load, window setup, VK setup in parallel, getting to PSO gen as fast as possible [get layout done first]}
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-07-31-AgileJebrim-spir-v-ive-given-up-on-trying-to-massage-frontend.md b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-07-31-AgileJebrim-spir-v-ive-given-up-on-trying-to-massage-frontend.md
index 1cb3d34..96167b1 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-07-31-AgileJebrim-spir-v-ive-given-up-on-trying-to-massage-frontend.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-07-31-AgileJebrim-spir-v-ive-given-up-on-trying-to-massage-frontend.md
@@ -26,51 +26,51 @@ parent_post_id: "1950935464149483683"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1950936023447302584
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 SPIR-V. I’ve given up on trying to massage frontend compilers to do exactly what I want. I’m just letting others write in whatever shader language they want and then taking the SPIR-V it generates and reoptimizing it the way I want it.
 
-**2/** @AgileJebrim
+**2/** **@AgileJebrim** ^1950936671957950601
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 One of the motivating factors is the fact that people already have a bunch of existing code, so the less work needed on their part to rewrite it, the better.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1950938798906372114
 
-@AgileJebrim
+**@AgileJebrim**
 
 If IHV compilers all handled well the case where the SPIR-V skips most SSA and leverages OpLoad/Store to global shader data (as in registers not memory), it might be a lot more tractable to go direct to SPIR-V.
 
-**4/** @AgileJebrim
+**4/** **@AgileJebrim** ^1950940769277063236
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I’m forcing the case where each invocation has access to a full 256 registers, which should hopefully limit the whole SSA/register spill problem. I haven’t tried intentionally breaking SSA though. Even if I did, there’s no way such UB would ever be certifiable.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1950944779199512703
 
-@AgileJebrim
+**@AgileJebrim**
 
 I don't know of any case where 256 registers had acceptable performance. And that includes IHV hand assembly. Full unrolling on GCN needed at least 2 waves/SIMD (128 regs max). And I personally target around 64 for anything going through a compiler.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1950945398333333701
 
-@AgileJebrim
+**@AgileJebrim**
 
 Note on some newer AMD GPUs they increased the regfile by 50% I think, which would be a 96 max reg target
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1950946283834703962
 
-@AgileJebrim
+**@AgileJebrim**
 
 Some of the larger problems with compilers is common sub-expression elimination. Meaning they will take out intentional recoputation or reloads and add register pressure. Often one has to fake a different value by ORing to a dynamic loaded zero (not known at compiler time)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1950947343966113910
 
-@AgileJebrim
+**@AgileJebrim**
 
 Meaning at medium levels of complexity the compilers are always going way over the register budget you'd target with hand written ASM. SSA ensures this. There are no aliasing hints in the IR.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-01-olson_dan-whats-the-top-something-else-ive-been-out-of-the.md b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-01-olson_dan-whats-the-top-something-else-ive-been-out-of-the.md
index 7d8839d..f9a6078 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-01-olson_dan-whats-the-top-something-else-ive-been-out-of-the.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-01-olson_dan-whats-the-top-something-else-ive-been-out-of-the.md
@@ -26,33 +26,33 @@ parent_post_id: "1950935464149483683"
 
 ## Branch
 
-**1/** @olson_dan
+**1/** **@olson_dan** ^1951144195843928435
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 What's the top "something else"?  I've been out of the space for a while.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1951295915274240375
 
-@olson_dan
+**@olson_dan**
 
 Wanting to build something that effectively loads/stores a 'cart' file which contains all the 'code+data' of the game in a restartable package. The code cannot be GLSL because I'm not going to link in a huge compiler. Leaves something that generates SPIR-V on the fly. New lang
 
-**3/** @EskilSteenberg
+**3/** **@EskilSteenberg** ^1951331025986134342
 
-@NOTimothyLottes @olson_dan
+**@NOTimothyLottes** **@olson_dan**
 
 For a long time i have contemplated writing a small GLSL->SPIR-V compiler. I think you could get away with something very simple, if you are conservative with your language use.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1951340035996815801
 
-@EskilSteenberg @olson_dan
+**@EskilSteenberg** **@olson_dan**
 
 Have a crazy idea for GPU shader dev inspired by a C64 SID tracker where you have a 'pattern' for the 'instrument' which shows SID fx changing over time, along with the standard multi-channel pattern nestily using the instrument ...
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1951340632183583076
 
-@EskilSteenberg @olson_dan
+**@EskilSteenberg** **@olson_dan**
 
 ... Effectively a macro assembly language style thing where defines can be played back interleaved for things like ILP or loop unrolling etc. But programmer controlling interleaving, and register offsets, etc. Then ultimately output to SPIR-V direct (no GLSL step).
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-02-NOTimothyLottes-so-far-the-plan-is-to-have-the-data-read-write.md b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-02-NOTimothyLottes-so-far-the-plan-is-to-have-the-data-read-write.md
index fa7896e..6aafd50 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-02-NOTimothyLottes-so-far-the-plan-is-to-have-the-data-read-write.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-02-NOTimothyLottes-so-far-the-plan-is-to-have-the-data-read-write.md
@@ -26,9 +26,9 @@ parent_post_id: "1951591243328135279"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1951638140600381942
 
-@onatt0 @EskilSteenberg @olson_dan
+**@onatt0** **@EskilSteenberg** **@olson_dan**
 
 So far the plan is to have the data read/write from the GPU, but still use the CPU to do the SPIR-V generation from said data.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/index.md b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/index.md
index 36d1c32..e338bee 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/index.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/index.md
@@ -25,31 +25,31 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1950935464149483683
 
 Been on the fence on writing shader interfaces in GLSL vs something else that translates to SPIR-V. Most GLSL mixed with defines can just direct port to other platforms. However these days I have hundreds of lines of macros to transform GLSL closer to assembly.
 
 Branches: [[archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-07-31-AgileJebrim-spir-v-ive-given-up-on-trying-to-massage-frontend]], [[archive/threads/NOTimothyLottes/2025-07-31-been-on-the-fence-on-writing-shader-interfaces-in/2025-08-01-olson_dan-whats-the-top-something-else-ive-been-out-of-the]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1950936863054667962
 
 Meaning I write using macros that are mostly a 1:1 mapping to AMDs GCN/RDNA ISA. With workarounds for missing stuff. SPIR-V output is an intimidating level of complex verbosity. More so when navigating frequent type bit aliasing (float, int, packed 16-bit float and int).
 
-**3/** @JBrooksBSI
+**3/** **@JBrooksBSI** ^1950950959385084261
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Sounds like an RDNA->SPIRV asm converter tool would be the way to go
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1950952733516705959
 
-@JBrooksBSI
+**@JBrooksBSI**
 
 I part tried to GLSL once. Using a global uint4 array as registers. But the wrapping of bit aliasing typecasts around operations is loaded with compiler perf bugs. Esp with packed 16-bit. So making it usable in practice is quite hard.
 
-**5/** @JBrooksBSI
+**5/** **@JBrooksBSI** ^1950974044234457406
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 What I do for console dev is write RDNA2 asm on PS5 (via wrapped shader intrinsics). 
 
@@ -59,8 +59,8 @@ This is a technique I have been using since 2006, for PS3 SPU coding:
 
 ![](https://pbs.twimg.com/media/GxNAMxPa4AAnMRt?format=jpg&name=orig)
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1951101400319934940
 
-@JBrooksBSI
+**@JBrooksBSI**
 
 Eventually I ended up the same way (writing via instruction defines). Originally when I did FXAA it was a 1:1 line mapping to NV ISA. But without factoring through a define. But it's really the custom register allocation that I wish was universally expressible today.
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-0x44_-assembly-isnt-hard-its-just-platform-specific.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-0x44_-assembly-isnt-hard-its-just-platform-specific.md
index 844bc38..2855efd 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-0x44_-assembly-isnt-hard-its-just-platform-specific.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-0x44_-assembly-isnt-hard-its-just-platform-specific.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @0x44_
+**1/** **@0x44_** ^1951048949667619280
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Assembly isn't hard, it's just platform specific, which makes it tedious.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-2Sexy4MyGPU-it-was-never-hard-just-tedious.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-2Sexy4MyGPU-it-was-never-hard-just-tedious.md
index 7c795e2..74b3976 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-2Sexy4MyGPU-it-was-never-hard-just-tedious.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-2Sexy4MyGPU-it-was-never-hard-just-tedious.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @2Sexy4MyGPU
+**1/** **@2Sexy4MyGPU** ^1950935584714654191
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 It was never hard, just tedious.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-CUDAHandbook-i-have-been-writing-assembly-for-almost-40-years.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-CUDAHandbook-i-have-been-writing-assembly-for-almost-40-years.md
index bdb3d9a..5e98209 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-CUDAHandbook-i-have-been-writing-assembly-for-almost-40-years.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-CUDAHandbook-i-have-been-writing-assembly-for-almost-40-years.md
@@ -26,21 +26,21 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @CUDAHandbook
+**1/** **@CUDAHandbook** ^1951018231856312578
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I have been writing assembly for almost 40 years. The reason we say it is hard, is because it takes more effort to write than higher-level languages like C. Of course it’s doable, but portability between CPU architecture alone makes assembly only worth doing when warranted.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1951098891396645052
 
-@CUDAHandbook
+**@CUDAHandbook**
 
 I'm hoping to show how to make it less tedious than C
 
-**3/** @Alleycatsphinx
+**3/** **@Alleycatsphinx** ^1951338802250932340
 
-@NOTimothyLottes @CUDAHandbook
+**@NOTimothyLottes** **@CUDAHandbook**
 
 My major problem with programming is the tedium.
 
@@ -48,9 +48,9 @@ GLSL Sandbox is still the best IDE I've ever used...
 
 Live code with instant update, simple automatic version control, cross platform web deployment, basic stripped down math language...
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1951341979289497943
 
-@Alleycatsphinx @CUDAHandbook
+**@Alleycatsphinx** **@CUDAHandbook**
 
 I love live systems as "the IDE". This time probably with function keys as a pallet of 'save/restore' points (snapshot the entire project, as one file).
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Karyuutensei-unrelated-but-i-would-also-love-a-look-at-your.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Karyuutensei-unrelated-but-i-would-also-love-a-look-at-your.md
index 013b435..c1fabb3 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Karyuutensei-unrelated-but-i-would-also-love-a-look-at-your.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Karyuutensei-unrelated-but-i-would-also-love-a-look-at-your.md
@@ -26,15 +26,15 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @Karyuutensei
+**1/** **@Karyuutensei** ^1950905493053923408
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Unrelated, but I would also love a look at your CRTs and how you use them in everyday stuff.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1950926350174351566
 
-@Karyuutensei
+**@Karyuutensei**
 
 Showing that setup would be fun. Most of my active CRTs are hooked up to vintage consoles though.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-NickDrisc0ll-im-sure-it-would-be-invaluable.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-NickDrisc0ll-im-sure-it-would-be-invaluable.md
index 63a6b3a..c5da85d 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-NickDrisc0ll-im-sure-it-would-be-invaluable.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-NickDrisc0ll-im-sure-it-would-be-invaluable.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @NickDrisc0ll
+**1/** **@NickDrisc0ll** ^1950899486059851961
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I'm sure it would be invaluable
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-PunteroCrudo-i-would-and-i-think-more-people-would-be.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-PunteroCrudo-i-would-and-i-think-more-people-would-be.md
index 1b4b354..b68397c 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-PunteroCrudo-i-would-and-i-think-more-people-would-be.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-PunteroCrudo-i-would-and-i-think-more-people-would-be.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @PunteroCrudo
+**1/** **@PunteroCrudo** ^1950929528131326083
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I would, and I think more people would be interested.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-SquaredApe-given-ive-only-done-asm-on-amiga-with-devpac-i.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-SquaredApe-given-ive-only-done-asm-on-amiga-with-devpac-i.md
index a2fb8e7..7eec9b5 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-SquaredApe-given-ive-only-done-asm-on-amiga-with-devpac-i.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-SquaredApe-given-ive-only-done-asm-on-amiga-with-devpac-i.md
@@ -26,15 +26,15 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @SquaredApe
+**1/** **@SquaredApe** ^1950915633811534012
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Given I've only done ASM on Amiga with Devpac, I guess it's probably a limited take, but I enjoyed it and didn't find it harder than say something like C, mostly because the problems I solved back then were 2D domain and the hardware was pretty simple... but not too hard?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1950926927985770680
 
-@SquaredApe
+**@SquaredApe**
 
 ASM could be a pain when mixing with high level languages due to the constant manual register and stack shuffling, but with what I have in mind will factor that out.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Stererence-ive-been-doing-assembly-a-bit-in-d-with-the.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Stererence-ive-been-doing-assembly-a-bit-in-d-with-the.md
index 6c091c5..da0c21b 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Stererence-ive-been-doing-assembly-a-bit-in-d-with-the.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Stererence-ive-been-doing-assembly-a-bit-in-d-with-the.md
@@ -26,15 +26,15 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @Stererence
+**1/** **@Stererence** ^1950970860694913461
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I've been doing assembly a bit in D with the inline assembler and it's very fun to the point where it's too distracting for me, I don't really get why people are so averse to it generally.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1951102123686457463
 
-@Stererence
+**@Stererence**
 
 Inline assembly in GCC has been a cornerstone of my C code for a long time.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-VicThorDev6-a-lot-of-people-who-claim-assembly-is-hard-just.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-VicThorDev6-a-lot-of-people-who-claim-assembly-is-hard-just.md
index 4258e8a..31b4f08 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-VicThorDev6-a-lot-of-people-who-claim-assembly-is-hard-just.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-VicThorDev6-a-lot-of-people-who-claim-assembly-is-hard-just.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @VicThorDev6
+**1/** **@VicThorDev6** ^1950927812401004774
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 A lot of people who claim assembly is hard just never did any themselves. In my opinion reading or even programming things in assembly isn't very hard but actually doing some of the optimizations compilers might do seems a lot harder
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-_naf_90-im-learning-assembly-in-my-spare-time.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-_naf_90-im-learning-assembly-in-my-spare-time.md
index 533a6c1..37f3c8e 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-_naf_90-im-learning-assembly-in-my-spare-time.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-_naf_90-im-learning-assembly-in-my-spare-time.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @_naf_90
+**1/** **@_naf_90** ^1950948334002159684
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I’m learning assembly in my spare time
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-biovf-i-would-definitely-watch-that.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-biovf-i-would-definitely-watch-that.md
index fa40aa7..9e66785 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-biovf-i-would-definitely-watch-that.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-biovf-i-would-definitely-watch-that.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @biovf
+**1/** **@biovf** ^1950863824522739861
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I would definitely watch that 🙂
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-cyberbemon-id-love-to-watch-that.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-cyberbemon-id-love-to-watch-that.md
index 669916a..f185291 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-cyberbemon-id-love-to-watch-that.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-cyberbemon-id-love-to-watch-that.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @cyberbemon
+**1/** **@cyberbemon** ^1950940978229236154
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I'd love to watch that.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-there-are-a-lot-of-watch-me-write-this-app-in.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-there-are-a-lot-of-watch-me-write-this-app-in.md
index 2f85277..a1720e4 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-there-are-a-lot-of-watch-me-write-this-app-in.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-there-are-a-lot-of-watch-me-write-this-app-in.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @furan
+**1/** **@furan** ^1950955895351083303
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 There are a lot of "watch me write this app in assembly" yt videos
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-would-watch-though.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-would-watch-though.md
index 619110f..d0c55e7 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-would-watch-though.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-would-watch-though.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @furan
+**1/** **@furan** ^1950956007737463015
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 would watch though
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-konigssohne-if-youre-got-a-blank-canvas-go-for-it-interfacing.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-konigssohne-if-youre-got-a-blank-canvas-go-for-it-interfacing.md
index 6d37c25..3b34a2c 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-konigssohne-if-youre-got-a-blank-canvas-go-for-it-interfacing.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-konigssohne-if-youre-got-a-blank-canvas-go-for-it-interfacing.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @konigssohne
+**1/** **@konigssohne** ^1950961762419044639
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 If you're got a blank `canvas` go for it.
 Interfacing to a kernel interrupt is one thing, hooking up to a toolkit ui is another I haven't ever seen, in asm.
@@ -36,9 +36,9 @@ Interfacing to a kernel interrupt is one thing, hooking up to a toolkit ui is an
 That leaves it all to command lines.
 And meh.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1951102721832133016
 
-@konigssohne
+**@konigssohne**
 
 Look at the older music trackers. All ASM and quite good UIs from a workflow efficiency perspective. They don't emulate a 'windowing system UI' for good reason, it wouldn't ever be as good as what they did do.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-leonard_coder-im-still-doing-assembly-as-hobby-68k-assembly-x64.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-leonard_coder-im-still-doing-assembly-as-hobby-68k-assembly-x64.md
index 8c41ae7..b113c26 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-leonard_coder-im-still-doing-assembly-as-hobby-68k-assembly-x64.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-leonard_coder-im-still-doing-assembly-as-hobby-68k-assembly-x64.md
@@ -26,35 +26,35 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @leonard_coder
+**1/** **@leonard_coder** ^1950889332375470135
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I'm still doing assembly as hobby :) ( 68k assembly, x64 assembly is not as fun to write).
 I'm interested to see such a tutorial, but please change a bit your font size and coding style :)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1950925507266007332
 
-@leonard_coder
+**@leonard_coder**
 
 I think people get confused with my screen gabs because they are on 4k panels and I run low res CRTs (so the bitmap fonts are not small for me). Also I think most of my strange C syntax is to make it more assembly like, so won't all be there in ASM
 
-**3/** @leonard_coder
+**3/** **@leonard_coder** ^1951282375997993089
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 oh you're on low res CRT? that explain a lot, I was always really surprised by your 3x5 pixels look-alike font  :) 
 But yeah Vulkan triangle setup code in assembly is something, I'm in!
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1951292823258398746
 
-@leonard_coder
+**@leonard_coder**
 
 Oh, yeah, I should disclose, no triangles will be harmed or even used in this project, it's PS-free, or CS-only. All gfx generated the vintage PC way, just on compute GPUs, in human crafted logic instead of fixed function HW.
 
-**5/** @leonard_coder
+**5/** **@leonard_coder** ^1951303945122423099
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 it's even better! (at least to me)
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-m6502-i-would-enjoy-watching-that.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-m6502-i-would-enjoy-watching-that.md
index c84fd11..8cf2f72 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-m6502-i-would-enjoy-watching-that.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-m6502-i-would-enjoy-watching-that.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @m6502
+**1/** **@m6502** ^1950913023851278616
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I would enjoy watching that.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mmalex-i-agree-if-one-is-ok-with-bottom-up-thinking-99.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mmalex-i-agree-if-one-is-ok-with-bottom-up-thinking-99.md
index fc4b9ce..b402b3d 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mmalex-i-agree-if-one-is-ok-with-bottom-up-thinking-99.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mmalex-i-agree-if-one-is-ok-with-bottom-up-thinking-99.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @mmalex
+**1/** **@mmalex** ^1950886322341630045
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 i agree, if one is ok with 'bottom up' thinking. 99% of my self taught early programming was asm, from demos to music editors (trackers) & it was a joy to work so directly with the machine. im convinced it still underlies my preference/prejudice for straightforward style of code
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mu_chrinovic-definitely-interested-in-anything-you-put-out.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mu_chrinovic-definitely-interested-in-anything-you-put-out.md
index a9c3dff..6bf02ec 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mu_chrinovic-definitely-interested-in-anything-you-put-out.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mu_chrinovic-definitely-interested-in-anything-you-put-out.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @mu_chrinovic
+**1/** **@mu_chrinovic** ^1950864277624979480
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 definitely interested in anything you put out
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-nullspector-i-would-so-love-that.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-nullspector-i-would-so-love-that.md
index 2b89dce..cc02d2e 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-nullspector-i-would-so-love-that.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-nullspector-i-would-so-love-that.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @nullspector
+**1/** **@nullspector** ^1950865695140364456
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I would so love that!
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-o__boga-im-staying-maybe-for-vulkan-depending-on-how.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-o__boga-im-staying-maybe-for-vulkan-depending-on-how.md
index 60524fb..0ee3b76 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-o__boga-im-staying-maybe-for-vulkan-depending-on-how.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-o__boga-im-staying-maybe-for-vulkan-depending-on-how.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @o__boga
+**1/** **@o__boga** ^1950939824183001106
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I'm staying maybe for Vulkan, depending on how manageable it gets to me. (Assembly or not)
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-opdroid1234-i-would.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-opdroid1234-i-would.md
index 51b60c8..77183f1 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-opdroid1234-i-would.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-opdroid1234-i-would.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @opdroid1234
+**1/** **@opdroid1234** ^1950902422362046528
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 i would!
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-philthistweet-i-just-wish-the-win32-api-was-better-designed-it.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-philthistweet-i-just-wish-the-win32-api-was-better-designed-it.md
index 7241576..a782d83 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-philthistweet-i-just-wish-the-win32-api-was-better-designed-it.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-philthistweet-i-just-wish-the-win32-api-was-better-designed-it.md
@@ -26,19 +26,19 @@ parent_post_id: "1950866703342088407"
 
 ## Branch
 
-**1/** @philthistweet
+**1/** **@philthistweet** ^1950918943834620235
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I just wish the win32 API was better designed. It would essentially be perfect for cross dev then.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1950927467645894968
 
-@philthistweet
+**@philthistweet**
 
 Certainly it could be, but as is, it's easy to use and not strictly limiting. Id be curious what people don't like about it. Maybe the winproc interface?
 
-**3/** @philthistweet
+**3/** **@philthistweet** ^1950932301187346833
 
 Just a few examples:
 1) thread/process creation and management 
@@ -51,9 +51,9 @@ Whoever sat down to create it probably said: "How can I create the most annoying
 
 Honestly, I may start a wrapper project though, because it's the only stable API that works
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1950933470802215318
 
-@philthistweet
+**@philthistweet**
 
 Clone is nicer and having ability to own cores should be great. But at least you get affinity and schedule priority. Yeah agree the file interface is poor, but I just memmap and manually page warm to bypass most of that.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-plasmabitcoin-very-interested.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-plasmabitcoin-very-interested.md
index 3df9e5f..c508eeb 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-plasmabitcoin-very-interested.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-plasmabitcoin-very-interested.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @plasmabitcoin
+**1/** **@plasmabitcoin** ^1950963702569771336
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Very interested!
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-pranksterware-thatd-rock.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-pranksterware-thatd-rock.md
index a195b98..3637e51 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-pranksterware-thatd-rock.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-pranksterware-thatd-rock.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @pranksterware
+**1/** **@pranksterware** ^1950872517700206902
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 That'd rock!
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-roasted6read-i-am-interested.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-roasted6read-i-am-interested.md
index 03851ec..be50cd6 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-roasted6read-i-am-interested.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-roasted6read-i-am-interested.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @roasted6read
+**1/** **@roasted6read** ^1950914379412566114
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I am interested
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ruben_cabaco-would-be-very-interested-in-it-also-on-your-forth.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ruben_cabaco-would-be-very-interested-in-it-also-on-your-forth.md
index b68672c..15b6717 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ruben_cabaco-would-be-very-interested-in-it-also-on-your-forth.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ruben_cabaco-would-be-very-interested-in-it-also-on-your-forth.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @ruben_cabaco
+**1/** **@ruben_cabaco** ^1950894646881611793
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Would be very interested in it! Also on your Forth inspired languages and the whole mental approach to simplify problem solving with efficiency in mind. Hard to find materials on this, and from what I gather your old projects/thoughts are no longer online.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-simplex_fx-is-it-already-aprils-fools-again.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-simplex_fx-is-it-already-aprils-fools-again.md
index d9db9b0..1d2e84f 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-simplex_fx-is-it-already-aprils-fools-again.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-simplex_fx-is-it-already-aprils-fools-again.md
@@ -26,33 +26,33 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @simplex_fx
+**1/** **@simplex_fx** ^1951011391827010009
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Is it already april’s fools again?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1951099694156792065
 
-@simplex_fx
+**@simplex_fx**
 
 Would it be interesting any other way
 
-**3/** @simplex_fx
+**3/** **@simplex_fx** ^1951165438311756272
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Worst part of this is not even the asm, but the choice of Vulkan 🤣
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1951295183611670741
 
-@simplex_fx
+**@simplex_fx**
 
 Vulkan for compute is a lot better than say DX12. Because VK has a working pipelinable API construct: VkEvents, where in contrast DX12's pipeline barriers are serializing in the drivers. Also GL has no pipelining. So VK wins by virtue of no other option.
 
-**5/** @simplex_fx
+**5/** **@simplex_fx** ^1951309944441151891
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Highly depends on one’s goals.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ssh4net-please.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ssh4net-please.md
index 30f6b7f..d1a3574 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ssh4net-please.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ssh4net-please.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @ssh4net
+**1/** **@ssh4net** ^1950870099809681578
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Please!
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-thecolemanthe-assembly-isnt-hard-its-tedious-no-abstractions.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-thecolemanthe-assembly-isnt-hard-its-tedious-no-abstractions.md
index 514ebcb..7b038ea 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-thecolemanthe-assembly-isnt-hard-its-tedious-no-abstractions.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-thecolemanthe-assembly-isnt-hard-its-tedious-no-abstractions.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @thecolemanthe
+**1/** **@thecolemanthe** ^1950956186783895852
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Assembly isn't hard, it's tedious. No abstractions, only the raw building blocks of computing. A lot of people just aren't ready or willing to deal with what the reality of an if or string concatenation much less the horrors of what their overly abstract oop code actually is.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-totalwert-thread.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-totalwert-thread.md
index 1478783..7150822 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-totalwert-thread.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-totalwert-thread.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @totalwert
+**1/** **@totalwert** ^1950900720770625916
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 <video controls src="https://video.twimg.com/tweet_video/GxL93LLW8AA-5hM.mp4"></video>
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-im-gonna-start-pretending-i-understood-everything.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-im-gonna-start-pretending-i-understood-everything.md
index abf4d9f..aed9cfe 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-im-gonna-start-pretending-i-understood-everything.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-im-gonna-start-pretending-i-understood-everything.md
@@ -26,9 +26,9 @@ parent_post_id: "1950868863836410096"
 
 ## Branch
 
-**1/** @AnshumanKhanna5
+**1/** **@AnshumanKhanna5** ^1951095609567617288
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I'm gonna start pretending I understood everything you said
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-video-link-now.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-video-link-now.md
index 8639ece..5fe98c7 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-video-link-now.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-video-link-now.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @AnshumanKhanna5
+**1/** **@AnshumanKhanna5** ^1951095292377571395
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 VIDEO LINK NOW
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-John31625320803-it-doesnt-really-matter-what-language-you-call.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-John31625320803-it-doesnt-really-matter-what-language-you-call.md
index 1e83f88..4ca873c 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-John31625320803-it-doesnt-really-matter-what-language-you-call.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-John31625320803-it-doesnt-really-matter-what-language-you-call.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @John31625320803
+**1/** **@John31625320803** ^1951198394329829393
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 It doesn't really matter what language you call Vulkan from, the pain is all in the API...
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-_vkaku-i-know-someone-whod-be-excited-opdroid1234.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-_vkaku-i-know-someone-whod-be-excited-opdroid1234.md
index a29a072..65ddf86 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-_vkaku-i-know-someone-whod-be-excited-opdroid1234.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-_vkaku-i-know-someone-whod-be-excited-opdroid1234.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @_vkaku
+**1/** **@_vkaku** ^1951170620542296537
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I know someone who'd be excited @opdroid1234
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-schulzb589-i-would-watch-that-so-count-me-in.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-schulzb589-i-would-watch-that-so-count-me-in.md
index 074f610..3ece638 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-schulzb589-i-would-watch-that-so-count-me-in.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-schulzb589-i-would-watch-that-so-count-me-in.md
@@ -26,9 +26,9 @@ parent_post_id: "1950860870818439202"
 
 ## Branch
 
-**1/** @schulzb589
+**1/** **@schulzb589** ^1951093394786361833
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I would watch that.  So, count me in.
 
diff --git a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/index.md b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/index.md
index d51238b..35c9f05 100644
--- a/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/index.md
+++ b/archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/index.md
@@ -25,31 +25,31 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1950860870818439202
 
 People claim assembly is hard. A good counter to that would be showing how to build a x86-64 WIN32 Vulkan based engine from scratch in ASM. Not sure how many people would find that worth watching though.
 
 Branches: [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-biovf-i-would-definitely-watch-that]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mu_chrinovic-definitely-interested-in-anything-you-put-out]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-nullspector-i-would-so-love-that]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ssh4net-please]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-pranksterware-thatd-rock]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-mmalex-i-agree-if-one-is-ok-with-bottom-up-thinking-99]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-leonard_coder-im-still-doing-assembly-as-hobby-68k-assembly-x64]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-ruben_cabaco-would-be-very-interested-in-it-also-on-your-forth]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-NickDrisc0ll-im-sure-it-would-be-invaluable]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-totalwert-thread]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-opdroid1234-i-would]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Karyuutensei-unrelated-but-i-would-also-love-a-look-at-your]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-m6502-i-would-enjoy-watching-that]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-roasted6read-i-am-interested]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-SquaredApe-given-ive-only-done-asm-on-amiga-with-devpac-i]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-VicThorDev6-a-lot-of-people-who-claim-assembly-is-hard-just]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-PunteroCrudo-i-would-and-i-think-more-people-would-be]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-2Sexy4MyGPU-it-was-never-hard-just-tedious]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-o__boga-im-staying-maybe-for-vulkan-depending-on-how]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-cyberbemon-id-love-to-watch-that]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-_naf_90-im-learning-assembly-in-my-spare-time]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-there-are-a-lot-of-watch-me-write-this-app-in]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-furan-would-watch-though]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-thecolemanthe-assembly-isnt-hard-its-tedious-no-abstractions]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-konigssohne-if-youre-got-a-blank-canvas-go-for-it-interfacing]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-plasmabitcoin-very-interested]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-Stererence-ive-been-doing-assembly-a-bit-in-d-with-the]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-simplex_fx-is-it-already-aprils-fools-again]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-CUDAHandbook-i-have-been-writing-assembly-for-almost-40-years]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-0x44_-assembly-isnt-hard-its-just-platform-specific]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-schulzb589-i-would-watch-that-so-count-me-in]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-AnshumanKhanna5-video-link-now]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-_vkaku-i-know-someone-whod-be-excited-opdroid1234]], [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-08-01-John31625320803-it-doesnt-really-matter-what-language-you-call]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1950861811982434738
 
 If game logic is GPU side there is little point in NOT doing assembly, since the CPU side stuff would always be platform specific.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1950862975193292928
 
 ASM provides a good opportunity to show how to convert typical function argument gather into store multicast with linear prefetch for arguments to API calls. Effectively re-arch for cold cache efficiency. And other radically cool stuff that nobody does.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1950866703342088407
 
 Linux has been all down hill over the years. OSS was fantastic, easy portable Linux system call interface. Also it's easy to do direct X11 with just syscalls. Now with Wayland you are stuck with linking to a garbage library. So might as well do WIN32 for Linux and depend on Wine.
 
 Branches: [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard/2025-07-31-philthistweet-i-just-wish-the-win32-api-was-better-designed-it]]
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1950867786424598890
 
 So Valve standardizing on Proton saves a lot of trouble with porting across ABIs/etc, just do WIN32 as it's way easier to interface with than Wayland and whatever horrible userland audio interface Linux monkeys switch to this era.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1950868863836410096
 
 Few probably remember the old Unix before pthreads and ELF. It was better then. Much easier to use fork and shm to do platform audio than today. And that holds for all the vintage workstations (which I did implement back in the day)
 
diff --git a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-VPCOMPRESSB-elaborate-on-the-cart-style-memory-model-i-assume.md b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-VPCOMPRESSB-elaborate-on-the-cart-style-memory-model-i-assume.md
index 908b0dd..c081a09 100644
--- a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-VPCOMPRESSB-elaborate-on-the-cart-style-memory-model-i-assume.md
+++ b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-VPCOMPRESSB-elaborate-on-the-cart-style-memory-model-i-assume.md
@@ -26,7 +26,7 @@ parent_post_id: "1951346857017250014"
 
 ## Branch
 
-**1/** @VPCOMPRESSB
+**1/** **@VPCOMPRESSB** ^1951359238787186957
 
 elaborate on the "CART"-style memory model?
 
@@ -34,41 +34,41 @@ i assume you initialize with the default start-up state that's maybe loaded from
 
 saving the game would then just be copying a region to disk contiguously—zero fragmentation. which means you can stream-in data linearly, provided that the layout of the CART maps to the ordering of the transformation stages. you can also compress the data in the CART quiet well i imagine. you can implement this as a double buffering system? the CART used strictly for rendering, and the pool strictly for transformations?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1951387345305112815
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 There is a Vulkan extension on PC that enables one to take a mapped file (aka the page cache) and access it from the GPU directly.
 
-**3/** @AgileJebrim
+**3/** **@AgileJebrim** ^1951400368182595775
 
-@NOTimothyLottes @VPCOMPRESSB @VPCOMPRESSB
+**@NOTimothyLottes** **@VPCOMPRESSB** **@VPCOMPRESSB**
 
 I believe the benefit here is that it avoids an extra copy.
 
 https://registry.khronos.org/vulkan/specs/latest/man/html/VK_EXT_external_memory_host.html
 
-**4/** @VPCOMPRESSB
+**4/** **@VPCOMPRESSB** ^1952121489429496201
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 that API seems very opaque. how can a person tell/preset the size and behavior of the page cache? would i just need to manage it similar to managing the CPU's cache?
 
-**5/** @AgileJebrim
+**5/** **@AgileJebrim** ^1952126843420655935
 
-@VPCOMPRESSB @NOTimothyLottes
+**@VPCOMPRESSB** **@NOTimothyLottes**
 
 There’s a win32 version too but yeah I would just generally assume that pages are 4096 bytes unless I have reason to believe otherwise. Apparently the intent that Timothy had is to use CreateFileMappingA() as well.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1952149643460030496
 
-@AgileJebrim @VPCOMPRESSB
+**@AgileJebrim** **@VPCOMPRESSB**
 
 In an ideal world the OS would allow pinning the file's pages. Since there is no guarantee, I can walk (read) the first cache line of the 4 kb pages periodically to try to force pinned behavior.
 
-**7/** @AgileJebrim
+**7/** **@AgileJebrim** ^1952150763750277299
 
-@NOTimothyLottes @VPCOMPRESSB
+**@NOTimothyLottes** **@VPCOMPRESSB**
 
 VirtualLock()?
 
diff --git a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-joeyazf-sounds-super-interesting.md b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-joeyazf-sounds-super-interesting.md
index 4e3ccb1..b828fcc 100644
--- a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-joeyazf-sounds-super-interesting.md
+++ b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-joeyazf-sounds-super-interesting.md
@@ -26,9 +26,9 @@ parent_post_id: "1951347512088088657"
 
 ## Branch
 
-**1/** @joeyazf
+**1/** **@joeyazf** ^1951378813985890736
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Sounds super interesting!
 
diff --git a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-snk_xed-looking-forward-to-it-what-do-i-bookmark.md b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-snk_xed-looking-forward-to-it-what-do-i-bookmark.md
index 2eefaea..88a912e 100644
--- a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-snk_xed-looking-forward-to-it-what-do-i-bookmark.md
+++ b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-snk_xed-looking-forward-to-it-what-do-i-bookmark.md
@@ -26,9 +26,9 @@ parent_post_id: "1951347512088088657"
 
 ## Branch
 
-**1/** @snk_xed
+**1/** **@snk_xed** ^1951374094655516679
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Looking forward to it, what do I bookmark?
 
diff --git a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-02-whereisratman-really-hope-you-do-this-find-your-posts-so.md b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-02-whereisratman-really-hope-you-do-this-find-your-posts-so.md
index 18c4b6d..6891aa6 100644
--- a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-02-whereisratman-really-hope-you-do-this-find-your-posts-so.md
+++ b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-02-whereisratman-really-hope-you-do-this-find-your-posts-so.md
@@ -26,9 +26,9 @@ parent_post_id: "1951345967795675161"
 
 ## Branch
 
-**1/** @whereisratman
+**1/** **@whereisratman** ^1951607410361090301
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Really hope you do this! Find your posts so interesting but usually fly over my head.
 
diff --git a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/index.md b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/index.md
index bde1c82..031cb4d 100644
--- a/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/index.md
+++ b/archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/index.md
@@ -25,19 +25,19 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1951345967795675161
 
 At least for my next at home project, I think the right answer is a building it from assembly scratch series on video with a public domain release of the 'engine' which will be a live edit toy for hardcore GPU-side PC game dev in certain constraints [which keep it simple]
 
 Branches: [[archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-02-whereisratman-really-hope-you-do-this-find-your-posts-so]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1951346857017250014
 
 It won't require RT, but it also won't run on Intel iGPUs [to low binding limits, etc]. Memory model will be 'CART' style where you get the a RAM CART [buffer] in memory which gets state snapshot, followed by dynamic GPU memory which is not snapshotted
 
 Branches: [[archive/threads/NOTimothyLottes/2025-08-01-at-least-for-my-next-at-home-project-i-think-the/2025-08-01-VPCOMPRESSB-elaborate-on-the-cart-style-memory-model-i-assume]]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1951347512088088657
 
 Also run-from GPU-side editing tools for shader source and bind everything tables. And build-the-editors-in-it style. Which load/store to the CART. So it won't be for people who want TBs of giant team gen content, but rather sized for what a single person could pull off
 
diff --git a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-10-AgileJebrim-thats-what-i-do-one-pinned-thread-per-core-sched.md b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-10-AgileJebrim-thats-what-i-do-one-pinned-thread-per-core-sched.md
index 6a68fce..e55325f 100644
--- a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-10-AgileJebrim-thats-what-i-do-one-pinned-thread-per-core-sched.md
+++ b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-10-AgileJebrim-thats-what-i-do-one-pinned-thread-per-core-sched.md
@@ -26,9 +26,9 @@ parent_post_id: "1976637149387587994"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1976730663018491918
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 That’s what I do. One pinned thread per core. SCHED_FIFO, highest priority, and reconfigure various settings within the OS to avoid preemptions/interrupts/hyperthreading.
 
diff --git a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-lectem-pinning-works-well-only-if-your-program-is-the.md b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-lectem-pinning-works-well-only-if-your-program-is-the.md
index ee810e2..b9716b8 100644
--- a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-lectem-pinning-works-well-only-if-your-program-is-the.md
+++ b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-lectem-pinning-works-well-only-if-your-program-is-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1976637149387587994"
 
 ## Branch
 
-**1/** @lectem
+**1/** **@lectem** ^1976935182289805554
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Pinning works well only if your program is the only one working. Any modern computer most likely have things running in the background. If any thread gets preempted in the middle of an execution block (that happens even with job stealing) you're screwed.
 
diff --git a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-techno_bog-do-you-have-a-source-from-which-one-could-learn.md b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-techno_bog-do-you-have-a-source-from-which-one-could-learn.md
index 6c501b5..c46594d 100644
--- a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-techno_bog-do-you-have-a-source-from-which-one-could-learn.md
+++ b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/2025-10-11-techno_bog-do-you-have-a-source-from-which-one-could-learn.md
@@ -26,45 +26,45 @@ parent_post_id: "1976637149387587994"
 
 ## Branch
 
-**1/** @techno_bog
+**1/** **@techno_bog** ^1977096425059320169
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Do you have a source from which one could learn how to achieve the equivalent flexibility by following this approach? Sometimes on gaming devices you only have a handful of threads to deal with unlike on PCs.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1977125534795550981
 
-@techno_bog
+**@techno_bog**
 
 Oh my conclusion was to abandon using the CPU for anything other than program init-time work and some IO processing, move everything else to the GPU where one has access to a good parallel programming model. Also enable CPU to power down so GPU gets {power,thermal,bandwidth}
 
-**3/** @techno_bog
+**3/** **@techno_bog** ^1977170730618863739
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 That’s not what you say in the post? Regardless, re the GPU, I struggle to understand how I’d do that within reasonable time. Ryan’s approach seems to be ergonomic enough to apply generically.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1977198847127699753
 
-@techno_bog
+**@techno_bog**
 
 Oh Ryan's approach isn't bad per say, it's way better than what most people do, it just wasn't something that yielded guaranteed quality of service that I was looking for. Nothing on the CPU running Windows can do that..
 
-**5/** @techno_bog
+**5/** **@techno_bog** ^1977213091487088879
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Then it must be going completely over my head. What are you criticizing exactly? Programming using the CPU in general?  Why pick Ryan's post specifically then?
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1977227086164107687
 
-@techno_bog
+**@techno_bog**
 
 Criticizing the Windows lack of allowing pined exclusive core use for the foreground application. If I play a PC game, as the user, I don't want background garbage to preempt what I'm playing. Ryan's post because it is a smart way to approach the best one can do on Windows today
 
-**7/** @techno_bog
+**7/** **@techno_bog** ^1977246748943773845
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 OK, I definitely had a reading comprehension issue here. Very new to this, thanks for clarifying.
 
diff --git a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/index.md b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/index.md
index 0c78a66..409334b 100644
--- a/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/index.md
+++ b/archive/threads/NOTimothyLottes/2025-10-10-thread-about-this-from-rfleury-https-www-rfleury/index.md
@@ -25,35 +25,35 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1976631453749535059
 
 Thread about this from @rfleury - https://www.rfleury.com/p/multi-core-by-default - because I used to do that too on the CPU ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1976632043539681371
 
 Same basic idea, all CPU threads ran the same program, each thread entry point gets an index of which thread they are. Same style as GPU programming but on the CPU! Also did runtime C code editing by exiting all threads and re-entering via new DLL ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1976633021882142744
 
 There are some obvious problems though: CPU "random" preemptions -> if any thread grabs work through an atomic or even by just dividing up work according to thread index, if that thread gets preempted, the future sync will stall introducing bubbles ...
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1976635135157256537
 
 Some CPU schedulers will preempt long running CPU threads at times of which one has no control. About the only way to try to improve this situation is to have a pair of threads instead of one, where they round robin execution using system context switches ...
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1976635621306421596
 
 Meaning giving the OS places that it becomes better to context switch a thread (at the point the thread has no ownership of a work item). This of course introduces overhead and complexity and breaks the manual threadIndex approach to work carving
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1976636115047317637
 
 Meaning patching the problem by speculative context switches doesn't guarantee the OS won't preempt during a bad time, it just decreases the probability
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1976636745694470151
 
 There are other options though: allow work duplication, meaning make the work such that if 2 or more threads all compute the data, they get the same answer ... then if a thread gets to a dependency, it can start to finish work that gets stalled due to preemption
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1976637149387587994
 
 This unfortunately also adds complexity and overhead, but at least one can continue to make forward progress. The RIGHT solution is pinned explicit CPU cores, an in modern times with huge thread count CPUs, there is no real excuse not to do this other than stupidity
 
diff --git a/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-13-questorInter-no-floats-ever-logged-or-some-agreement-that-its.md b/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-13-questorInter-no-floats-ever-logged-or-some-agreement-that-its.md
index 780f341..c32f162 100644
--- a/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-13-questorInter-no-floats-ever-logged-or-some-agreement-that-its.md
+++ b/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-13-questorInter-no-floats-ever-logged-or-some-agreement-that-its.md
@@ -26,15 +26,15 @@ parent_post_id: "1977570893309321268"
 
 ## Branch
 
-**1/** @questorInter
+**1/** **@questorInter** ^1977736160072839316
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 no floats ever logged? or some "agreement" that it's always multiplied by 100000 or something like that? besides, interesting (low-level) ideas I really like :)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1977736975416213651
 
-@questorInter
+**@questorInter**
 
 If I need to see a float, I scale it, then convert to an interger and print that. If it is the exact value, I just bit alias as 32-bit int and print that. Problem solved :) Similar if I need to see a 64-bit pointer, I write the hi and lo as two lines, etc.
 
diff --git a/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-17-Karyuutensei-i-watched-the-video-and-one-thing-that-was-not.md b/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-17-Karyuutensei-i-watched-the-video-and-one-thing-that-was-not.md
index 5b4e2e5..d2eb82f 100644
--- a/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-17-Karyuutensei-i-watched-the-video-and-one-thing-that-was-not.md
+++ b/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-17-Karyuutensei-i-watched-the-video-and-one-thing-that-was-not.md
@@ -26,15 +26,15 @@ parent_post_id: "1977570893309321268"
 
 ## Branch
 
-**1/** @Karyuutensei
+**1/** **@Karyuutensei** ^1979085608040489019
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I watched the video and one thing that was not clear to me is why is half of the file wasted. Aren’t you using all upper 16 bits of the counter for the lines? Also, what do you mean with “no retries”?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1979208516733698451
 
-@Karyuutensei
+**@Karyuutensei**
 
 Could have just used pow2 pages + 1 page for counter, but I got lazy. Yes could use more than 16-bits for line counter too. Reload counter could be 4-bits. Lock-free typically implies a retry-loop (non-wait-free). This however is wait-free (no retry-loop).
 
diff --git a/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/index.md b/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/index.md
index 84547a2..0705e54 100644
--- a/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/index.md
+++ b/archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/index.md
@@ -25,20 +25,20 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1977570893309321268
 
 Short talk on how I do CPU-side debugging without a debugger using a simple memory mapped file message logging system with lock-free atomic and file-io-free message store: https://www.youtube.com/watch?v=EaUSAVcXwEc ... contains the implementation as well
 
 Branches: [[archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-13-questorInter-no-floats-ever-logged-or-some-agreement-that-its]], [[archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-17-Karyuutensei-i-watched-the-video-and-one-thing-that-was-not]]
 
-**2/** @AgileJebrim
+**2/** **@AgileJebrim** ^1977574043479154821
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 No retries - you should call it wait-free too.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1977575984166846522
 
-@AgileJebrim
+**@AgileJebrim**
 
 Good point, I'm going to adopt that 'wait-free' term moving forward :)
diff --git a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-AgileJebrim-reversed-is-a-significant-improvement-but-it.md b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-AgileJebrim-reversed-is-a-significant-improvement-but-it.md
index 2c9ec1c..b09f0e6 100644
--- a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-AgileJebrim-reversed-is-a-significant-improvement-but-it.md
+++ b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-AgileJebrim-reversed-is-a-significant-improvement-but-it.md
@@ -26,17 +26,17 @@ parent_post_id: "1990260050485797063"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1990260754688172298
 
 Reversed is a significant improvement but it still has its limitations when doing planetary-scale rendering that needs good precision up both close and far away. Your options there are either a logarithmic depth buffer to linearize things (albeit losing early z), your own integer-based depth test system in compute shaders, or a stack of multiple frustums layered on top of one another.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1990261535491723691
 
-@AgileJebrim
+**@AgileJebrim**
 
 Yes for my non-tri stuff I'm log depth already. This is just for games, not simulation.
 
-**3/** @AgileJebrim
+**3/** **@AgileJebrim** ^1990263993236136239
 
 Simulation can usually localize enough that reverse Z is good enough. Google Earth style geospatial visualization is where things get trickier.
 
diff --git a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-bgolus-many-are-still-on-opengles-and-webgl-which-dont.md b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-bgolus-many-are-still-on-opengles-and-webgl-which-dont.md
index a91f9f5..8a5e549 100644
--- a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-bgolus-many-are-still-on-opengles-and-webgl-which-dont.md
+++ b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-bgolus-many-are-still-on-opengles-and-webgl-which-dont.md
@@ -26,9 +26,9 @@ parent_post_id: "1990260050485797063"
 
 ## Branch
 
-**1/** @bgolus
+**1/** **@bgolus** ^1990285316054503566
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Many are still on OpenGLES and WebGL, which don’t properly support inverse depth due to still using a -1 to 1 clip space. Not really a problem for inverse depth in its own, but does cause problems for infinite far depth.
 
diff --git a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-terekhov_de-ive-never-had-real-depth-precision-issues-in-our.md b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-terekhov_de-ive-never-had-real-depth-precision-issues-in-our.md
index b101e3d..4cce501 100644
--- a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-terekhov_de-ive-never-had-real-depth-precision-issues-in-our.md
+++ b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-terekhov_de-ive-never-had-real-depth-precision-issues-in-our.md
@@ -26,9 +26,9 @@ parent_post_id: "1990260050485797063"
 
 ## Branch
 
-**1/** @terekhov_de
+**1/** **@terekhov_de** ^1990284522508927371
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I've never had real depth precision issues in our game ports but I guess I'd better just adopt and get used to reversed infinite projection cause it's objectively better. Promise to try it for our next project :)
 
diff --git a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-18-Alecazam123-infinite-far-doesnt-apply-to-ortho-and-many-of.md b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-18-Alecazam123-infinite-far-doesnt-apply-to-ortho-and-many-of.md
index 601a677..f277c06 100644
--- a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-18-Alecazam123-infinite-far-doesnt-apply-to-ortho-and-many-of.md
+++ b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-18-Alecazam123-infinite-far-doesnt-apply-to-ortho-and-many-of.md
@@ -26,9 +26,9 @@ parent_post_id: "1990260050485797063"
 
 ## Branch
 
-**1/** @Alecazam123
+**1/** **@Alecazam123** ^1990818990059671922
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Infinite far doesn’t apply to ortho, and many of editors/engines need to switch camera viewports.  But it’s great for persp.  Also too much code handing modeInv for normals, which is wrong and unneeded.
 
diff --git a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-19-stainless_code-i-havent-really-done-graphics-in-a-while-but-ive.md b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-19-stainless_code-i-havent-really-done-graphics-in-a-while-but-ive.md
index 48a754a..3f0c1a4 100644
--- a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-19-stainless_code-i-havent-really-done-graphics-in-a-while-but-ive.md
+++ b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-19-stainless_code-i-havent-really-done-graphics-in-a-while-but-ive.md
@@ -26,16 +26,16 @@ parent_post_id: "1990260050485797063"
 
 ## Branch
 
-**1/** @stainless_code
+**1/** **@stainless_code** ^1991219165978370275
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I haven't really done graphics in a while, but I've never heard about infinite far nor reversed z, where can I read up on it more?
 Some cursory googling didn't return anything useful on this topic.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1991352784529289269
 
-@stainless_code
+**@stainless_code**
 
 I put some docs (based on an old blog post) on projection matrix stuff inside STP source: https://github.com/Unity-Technologies/Graphics/blob/master/Packages/com.unity.render-pipelines.core/Runtime/STP/Stp.hlsl - Documents the maths to take depth and 2 projections and get a static reprojection vector for example.
 
diff --git a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/index.md b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/index.md
index a758ae1..abc7675 100644
--- a/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/index.md
+++ b/archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1990260050485797063
 
 I wish everyone would just adopt "reversed with infinite far" projection matrixes so I could only optimize for the fastest and highest precision option, but I'm guessing people haven't all migrated over :(
 
@@ -33,17 +33,17 @@ I wish everyone would just adopt "reversed with infinite far" projection matrixe
 
 Branches: [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-terekhov_de-ive-never-had-real-depth-precision-issues-in-our]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-17-bgolus-many-are-still-on-opengles-and-webgl-which-dont]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-18-Alecazam123-infinite-far-doesnt-apply-to-ortho-and-many-of]], [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with/2025-11-19-stainless_code-i-havent-really-done-graphics-in-a-while-but-ive]]
 
-**2/** @AgileJebrim
+**2/** **@AgileJebrim** ^1990260754688172298
 
 Reversed is a significant improvement but it still has its limitations when doing planetary-scale rendering that needs good precision up both close and far away. Your options there are either a logarithmic depth buffer to linearize things (albeit losing early z), your own integer-based depth test system in compute shaders, or a stack of multiple frustums layered on top of one another.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1990261535491723691
 
-@AgileJebrim
+**@AgileJebrim**
 
 Yes for my non-tri stuff I'm log depth already. This is just for games, not simulation.
 
-**4/** @AgileJebrim
+**4/** **@AgileJebrim** ^1990263993236136239
 
 Simulation can usually localize enough that reverse Z is good enough. Google Earth style geospatial visualization is where things get trickier.
 
diff --git a/archive/threads/NOTimothyLottes/2026-01-14-can-do-that/index.md b/archive/threads/NOTimothyLottes/2026-01-14-can-do-that/index.md
index 7f6b65c..45d2d24 100644
--- a/archive/threads/NOTimothyLottes/2026-01-14-can-do-that/index.md
+++ b/archive/threads/NOTimothyLottes/2026-01-14-can-do-that/index.md
@@ -29,8 +29,8 @@ in_reply_to: "2011353617102741593"
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2011429743053111302
 
-@VPCOMPRESSB
+**@VPCOMPRESSB**
 
 Can do that. But at least these kinds of systems are already faster than human response time (excluding when they have external dependencies on say on some other kernel like Linux). I'll be able to recompile all binary code (including GPU-side) in a tiny fraction of frame time.
diff --git a/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/2026-03-08-gindi4711-did-they-not-just-use-more-historical-frames-to.md b/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/2026-03-08-gindi4711-did-they-not-just-use-more-historical-frames-to.md
index 93e3ec5..b267ef6 100644
--- a/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/2026-03-08-gindi4711-did-they-not-just-use-more-historical-frames-to.md
+++ b/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/2026-03-08-gindi4711-did-they-not-just-use-more-historical-frames-to.md
@@ -26,15 +26,15 @@ parent_post_id: "2030722033286328426"
 
 ## Branch
 
-**1/** @gindi4711
+**1/** **@gindi4711** ^2030734135338144038
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Did they not just use more historical frames to get their samples and have a better model to compensate for the side effects?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2030737650882113897
 
-@gindi4711
+**@gindi4711**
 
 Costs went up a lot so maybe. But cannot really add frames of context without getting costly. Secondary option is to store extra data in feedback sideband.
 
diff --git a/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/index.md b/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/index.md
index 9c2ee28..e24a636 100644
--- a/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/index.md
+++ b/archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/index.md
@@ -25,36 +25,36 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2030722033286328426
 
 I'll add one conspiracy theory for everyone listening: After STP's source was out there, DLSS4 'transformer' magically gained 'sharpness' but I don't believe it was from the ML model change at all, instead I think they just introduced the same error feedback mechanism in STP ...
 
 Branches: [[archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone/2026-03-08-gindi4711-did-they-not-just-use-more-historical-frames-to]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2030722489538543674
 
 Specifically STP samples feedback at the position of the input pixels, and uses that difference as an error term estimating the amount of blur introduced, one can subtract out some amount of that 'error' to sharpen ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2030723314801357065
 
 Of course that idea isn't strictly new either, fluid sims with advection use similar logic to sharpen. So I'm just another human building on the masters of the past. One can start to go beyond sharpening with this technique and get into local contrast adaption too ...
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2030723826993213805
 
 One of the marketing points of DLSS4 was 'sharpness' but it didn't actually resolve details to a higher frequency than prior, instead it just gets to a higher contrast, and then they con the consumer with that ...
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2030725182671798689
 
 Another trick one can employ, and something I used often as a pro photographer, was to deliberately thin or thicken features with sub-pixel precision during enlargement. Meaning you can take a 'feature' and thin it below source nyquist. And people go 'wow' it's detailed ...
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2030726077312541100
 
 So for instance one can take a input (lower-resolution) feature and simultaneously increase it's contrast while reducing it's thickness (when enlarged) in an energy preserving way. Can use signal bounds to estimate how much contrast and thus thin-ness one can push the feature ...
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2030726373124317233
 
 This gets easier with color signals because you can take the minimum bounds of the three channels, this is actually exactly what CAS does (just applied in a context without enlargement) ...
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^2030726690721198381
 
 Anyway all this stuff is easy to artistically shape analytically in shader code, and never needed any kind of ML to be implemented (in fact ML would be slow, because it cannot do max/min style logic!!!).
diff --git a/archive/threads/NOTimothyLottes/2026-05-23-another-memorial-weekend-thought-for-either/index.md b/archive/threads/NOTimothyLottes/2026-05-23-another-memorial-weekend-thought-for-either/index.md
index 729eb5d..1e38fff 100644
--- a/archive/threads/NOTimothyLottes/2026-05-23-another-memorial-weekend-thought-for-either/index.md
+++ b/archive/threads/NOTimothyLottes/2026-05-23-another-memorial-weekend-thought-for-either/index.md
@@ -25,33 +25,33 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2058159498716463375
 
 Another memorial weekend thought: for either 
 (a.) single use code - [majority of slopware]
 (b.) cold cache code - [also typical of slopware]
 the CPU loading the code is a significant amount of the burned memory bandwidth ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2058160921462063183
 
 Meaning in C/C++ land where "programmers" (or rather slop-rammers) mostly sniff argument sloshing glue, moving to a scatter instead of gather based language with a single common "call" that just overreads all the register args, would likely be significantly faster ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2058161964442866061
 
 The analog for the syscall side is to work from a 'tape' pointer read the 7 registers (syscall number in rax, and the 6 max args) always from a linear stream, but advance the read pointer by the number of actual registers used. So the overfetch is just a linear prefetch ...
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2058162553541300497
 
 If working with only 32-bit args (see the MAP_32BIT comment), it would be efficient. Add a post-syscall address to call in the common syscall loop, the part that does post-syscall logic like scattering data to future argument read slots (aka the scatter part) ...
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2058164906659066002
 
 Now if it was possible to uber-op the post call logic, meaning a fixed logic block that is just data configurable, that call goes away, and it's all probably executing instructions out of the cache (at some level) ...
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2058165475033440643
 
 Effectively you'd have an 'initialization language' which is designed to workaround cold execution paths, but with linear CPU prefetch friendly data access for reads, and random scatter for stores (where latency don't matter) ...
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2058166883044516181
 
 Most crap-o-grammers today in the user-space C++ bloat-ware domain have not really optimized for performance, rather they optimized for maximum bloat generation. Just add up how much the installed libraries weigh in MiB on a clean OS install.
diff --git a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-29-the_geeko1-this-doesnt-have-to-be-like-this-but-the-new-dma.md b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-29-the_geeko1-this-doesnt-have-to-be-like-this-but-the-new-dma.md
index d24b31c..a9fcf04 100644
--- a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-29-the_geeko1-this-doesnt-have-to-be-like-this-but-the-new-dma.md
+++ b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-29-the_geeko1-this-doesnt-have-to-be-like-this-but-the-new-dma.md
@@ -26,51 +26,51 @@ parent_post_id: "2060198133905199300"
 
 ## Branch
 
-**1/** @the_geeko1
+**1/** **@the_geeko1** ^2060203539775869114
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 this doesn't have to be like this .. but the new DMA-buf changes are not upstreamed yet on linux .. if that's done I would love to upstream my changes to the AMD KMD so u can have actual physical addresses of VRAM exported.
 
-**2/** @the_geeko1
+**2/** **@the_geeko1** ^2060203754436047276
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 on the other side u could assign vfio-pci driver to the other device and write the drivers on user-space on both CPU/GPU and cut out the kernel drivers out the picture which is quite nice.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2060228966263173629
 
-@the_geeko1
+**@the_geeko1**
 
 This reminds me, I don't actually know how GPU audio (HDMI out) works, but I've always assumed it was a private onboard memory where regular shader load/store doesn't have access. The bandwidth though is tiny, so that round trip through the CPU is mostly just a latency concern
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2060229726027776043
 
-@the_geeko1
+**@the_geeko1**
 
 And by latency, it's mostly a question of how to get a consistent small workload through the GPU at a periodic schedule (feed the data to the CPU right before it's needed for the copy back to the GPU)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2060230415634350214
 
-@the_geeko1
+**@the_geeko1**
 
 Networking is interesting, in that one could do a SALU/SMEM approach to processing packets, or one could do something like work with only fixed size UDP packets and process them using VALU/VMEM, in which case the CPU could interleave/deinterleave the dwords for good GPU access
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2060232012301009140
 
-@the_geeko1
+**@the_geeko1**
 
 With the SALU/SMEM approach, having direct communication with the network card could be nice, but I doubt the linux folks want to allow raw UDP header/payload DMA scatter/gather bypassing all the OS layers
 
-**7/** @the_geeko1
+**7/** **@the_geeko1** ^2060235097807147376
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 It's always an option to drop the kernel driver and assign the vfio-pci driver and write a custom driver on user space .. also there some NICs with a programmable chip on them .. they could be programmed to DMA some packets into CPU memory like normal and some into the GPU
 
-**8/** @the_geeko1
+**8/** **@the_geeko1** ^2060235529036140866
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Nvidia calls them DPU I think ? those are also useful for GPUs to share data if on the same network .. and I think that is the main driver behind Nvidia's work on restructuring how the DMA-bufs work on linux.
 
diff --git a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-30-nicbarkeragain-very-keen-to-see-how-the-gpu-side-audio-turns-out.md b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-30-nicbarkeragain-very-keen-to-see-how-the-gpu-side-audio-turns-out.md
index c209462..9c8ac8d 100644
--- a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-30-nicbarkeragain-very-keen-to-see-how-the-gpu-side-audio-turns-out.md
+++ b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-30-nicbarkeragain-very-keen-to-see-how-the-gpu-side-audio-turns-out.md
@@ -26,15 +26,15 @@ parent_post_id: "2060186437820010850"
 
 ## Branch
 
-**1/** @nicbarkeragain
+**1/** **@nicbarkeragain** ^2060515066919936097
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Very keen to see how the GPU side audio turns out!
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2060530551753191644
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 To get the low latency Im looking for will require chunking up all work on the GPU and interleaving slots for audio processing. Lower bound on processing granularity is 32 stereo samples in a 64 wave, so less than a millisecond of representative time
 
diff --git a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-06-27-mrsteyk1-its-seemingly-incorrect-due-to-its-use-for.md b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-06-27-mrsteyk1-its-seemingly-incorrect-due-to-its-use-for.md
index 3cc0675..98e04a9 100644
--- a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-06-27-mrsteyk1-its-seemingly-incorrect-due-to-its-use-for.md
+++ b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-06-27-mrsteyk1-its-seemingly-incorrect-due-to-its-use-for.md
@@ -26,9 +26,9 @@ parent_post_id: "2060190230838223346"
 
 ## Branch
 
-**1/** @mrsteyk1
+**1/** **@mrsteyk1** ^2070892786065482185
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 It's seemingly incorrect due to it's use for NtWaitForAlertByThreadId. Internal implementation is a hash table [128] indexed by (a1>>5)&0x7f inside PEB. Default spin value (v4) for my build is 10240 shared for similar type of functions (SRWLocks etc).
 
diff --git a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/index.md b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/index.md
index 4c9f52d..32277bf 100644
--- a/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/index.md
+++ b/archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/index.md
@@ -25,56 +25,56 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2060186437820010850
 
 Took perhaps a 5 month vacation from at home programming, but getting back in the grove with 1hr/day.  Polishing up my WIN32 and Linux system call interfaces. Perhaps working towards a demo of GPU-side audio and network processing.
 
 Branches: [[archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-30-nicbarkeragain-very-keen-to-see-how-the-gpu-side-audio-turns-out]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2060189329801003343
 
 Today's topic was Sleep [crap] vs NtDelayExecution [good], does seem useful to be able to NtAlertThread while a thread is sleeping (an analog to signaling while nanosleeping on Linux).
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2060190230838223346
 
 Futex users, there is the WakeByAddressAll and WaitOnAddress in Windows. But why use those when you can just directly call https://ntdoc.m417z.com/rtlwaitonaddress - but haven't tried that yet, and are the docs correct, why PLARGE_INTEGER for ms, when NtDelayExecution does the 100ns unit thing?
 
 Branches: [[archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-06-27-mrsteyk1-its-seemingly-incorrect-due-to-its-use-for]]
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2060191401883619479
 
 https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related read, also I'm a little late to the https://ntdoc.m417z.com/system_hypervisor_user_shared_data party, but will have that sorted soon as well
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2060192645582905577
 
 Other thought, I typically mmap an extra LOG file, and write via atomic to grab a fixed width line. No stdout. The log wraps around and exists for multiple executions or even parallel processes. It's the way to do it ... BUT ...
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2060193385411969118
 
 ... I think I'm going to just move the LOG file into the first N KiB of the CART file. So mmap'ed on CPU and GPU, and I can just bank on how "less" doesn't actually load the entire file while printing, so I can still see output on a console if needed for debug.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2060195139696365679
 
 And another random thought, can you force de-power the CPU by abusing the https://www.felixcloutier.com/x86/pause instruction for things that are not spin-loops :) Going to have to try this one at some point.
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^2060195914568851775
 
 Pushing data to GPU is really a no-brainer (write-combined stores), minus possibility of non-atomic write visibility, so I do simple stuff like always having a ring buffer of packets available where the GPU can validate each entry with a HASH, taking the latest valid one to use
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^2060196816574882209
 
 Also AMD exports non-cached memory in VK, so it's possible to poll on data the CPU pushes (via write combined stores to VRAM) on AMD a few times per frame even.
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^2060197138923938169
 
 The workaround for NVIDIA is if one wants to read N times per frame, then the CPU needs to duplicate the packet ring to N separate lines. Then the GPU is free to poll, but using separate cachelines each time.
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^2060198133905199300
 
 The route back for IO that needs to be routed through the CPU {audio out, network out} is a lot more unfun. AMD again has the nice uncached memory support, so that part is easy. NVIDIA well, would have to take the crappy mid-frame L2 writeback (likely) making CPU-read available
 
 Branches: [[archive/threads/NOTimothyLottes/2026-05-29-took-perhaps-a-5-month-vacation-from-at-home/2026-05-29-the_geeko1-this-doesnt-have-to-be-like-this-but-the-new-dma]]
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^2060199422730871174
 
 Those who have tread here before with driver side logic (DMA transfers/etc) got screwed, Win+Linux driver idiots and their CPU interrupt based scheduling = completely useless. So getting the driver out of the picture is the way to go
diff --git a/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/2026-05-31-FUZxxl-if-you-do-the-multiply-in-uint128-t-and-then.md b/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/2026-05-31-FUZxxl-if-you-do-the-multiply-in-uint128-t-and-then.md
index 416929a..8651495 100644
--- a/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/2026-05-31-FUZxxl-if-you-do-the-multiply-in-uint128-t-and-then.md
+++ b/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/2026-05-31-FUZxxl-if-you-do-the-multiply-in-uint128-t-and-then.md
@@ -26,21 +26,21 @@ parent_post_id: "2060730425929080874"
 
 ## Branch
 
-**1/** @FUZxxl
+**1/** **@FUZxxl** ^2060885487858880689
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 If you do the multiply in uint128_t and then right-shift by 64 places, the compiler should do the right thing.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2060898306851516562
 
-@FUZxxl
+**@FUZxxl**
 
 “Should” is exactly why I prefer the actual instruction instrinsics or just inline asm (which is what I use on C CPU land)
 
-**3/** @FUZxxl
+**3/** **@FUZxxl** ^2061000558698197386
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Have fun with a solution that the compiler optimises worse and that is not portable.
 
diff --git a/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/index.md b/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/index.md
index 6ef3610..e07cd4c 100644
--- a/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/index.md
+++ b/archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2060730425929080874
 
 Renovating CPU clock code. I'm assuming x86-64 TSC is always >= 1 GHz so that conversion of clock counter diff to nanoseconds is simply a MUL instruction fetching the RDX high 64-bit result (of the 128-bit computed). But figuring out how to do the inline asm was a pain.
 
@@ -33,10 +33,10 @@ Renovating CPU clock code. I'm assuming x86-64 TSC is always >= 1 GHz so that co
 
 Branches: [[archive/threads/NOTimothyLottes/2026-05-30-renovating-cpu-clock-code/2026-05-31-FUZxxl-if-you-do-the-multiply-in-uint128-t-and-then]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2060742129190568413
 
 Looks like NtQuerySystemInformation() with SystemHypervisorSharedPageInformation (aka 0xc5) gives 64-bit scalar for TSC that converts time to units of 10 MHz. So the smart way is to work in units of TSC, then do a subtraction of TSC terms, then MULHI to get {ms, us, or ns} time
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2060752921092833490
 
 https://gist.github.com/pmttavara/6f06fc5c7679c07375483b06bb77430c - A great reference for getting TSC scaling multipliers on Linux and Windows
diff --git a/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/2026-05-31-retrotink2-here-i-am-still-debugging-by-looking-at-if-a.md b/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/2026-05-31-retrotink2-here-i-am-still-debugging-by-looking-at-if-a.md
index d9c1e18..d097680 100644
--- a/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/2026-05-31-retrotink2-here-i-am-still-debugging-by-looking-at-if-a.md
+++ b/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/2026-05-31-retrotink2-here-i-am-still-debugging-by-looking-at-if-a.md
@@ -26,15 +26,15 @@ parent_post_id: "2061123768429211767"
 
 ## Branch
 
-**1/** @retrotink2
+**1/** **@retrotink2** ^2061206435942511008
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Here I am still debugging by looking at if a single LED turns on.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2061252886453944549
 
-@retrotink2
+**@retrotink2**
 
 That plus an oscilloscope … this is the way
 
diff --git a/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/index.md b/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/index.md
index 0352985..4aebbfa 100644
--- a/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/index.md
+++ b/archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/index.md
@@ -25,16 +25,16 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2061123768429211767
 
 no-debugger-debug / console / printf-style - prior evolved to one mmapped fixed-width-height log file with an atomic for multi-thread|process messages - but even that seems too complexy ...
 
 Branches: [[archive/threads/NOTimothyLottes/2026-05-31-no-debugger-debug-console-printf-style-prior/2026-05-31-retrotink2-here-i-am-still-debugging-by-looking-at-if-a]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2061124536729207080
 
 moving to this >>> CART file is mmapped on CPU with mapped GPU access (no file IO) - background page walker to ensure OS won't page it out - beginning of CART file is a grid of 32-bit unsigned values - hex dumping that as my 'log file' - either to term or GPU render
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2061124942968545433
 
 hits the easy to debug CPU or GPU stuff in the same framework (simply write and it just appears) - it's always a HEX dump, but can show decimal by pretending it's a 4-bit/character terminal with a hex font :)
diff --git a/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/2026-06-02-iamwhosiam-i-dont-think-your-even-suppose-to-change-your.md b/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/2026-06-02-iamwhosiam-i-dont-think-your-even-suppose-to-change-your.md
index 39196b3..693a5cc 100644
--- a/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/2026-06-02-iamwhosiam-i-dont-think-your-even-suppose-to-change-your.md
+++ b/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/2026-06-02-iamwhosiam-i-dont-think-your-even-suppose-to-change-your.md
@@ -26,15 +26,15 @@ parent_post_id: "2061416116694442141"
 
 ## Branch
 
-**1/** @iamwhosiam
+**1/** **@iamwhosiam** ^2061658841360589225
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I don’t think your even suppose to change your thread’s priority in general anymore, it just messes with scheduling.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2061757874297065775
 
-@iamwhosiam
+**@iamwhosiam**
 
 Try using low latency pro audio tools and disabling the app’s authorization for high priority scheduling
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/index.md b/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/index.md
index b2d3cf9..1785e8a 100644
--- a/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/index.md
@@ -25,12 +25,12 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2061416116694442141
 
 Windows thread priority. SeIncreaseBasePriorityPrivilege required to play in the (fake)"Realtime" class -BUT- apparently there is AvSetMmThreadCharacteristics() for "Pro Audio" and AvSetMmThreadPriority() which can bring up priority into realtime. Curious if games using today?
 
 Branches: [[archive/threads/NOTimothyLottes/2026-06-01-windows-thread-priority/2026-06-02-iamwhosiam-i-dont-think-your-even-suppose-to-change-your]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2061416572627886473
 
 Either way NtSetInformationThread() seems to be the way to just set {1-15} (non-realtime class) priority directly without the silly clamp(priorityClassBase+threadPriority,1,15) business
diff --git a/archive/threads/NOTimothyLottes/2026-06-02-for-windows-trying-to-standardize-on-highest/index.md b/archive/threads/NOTimothyLottes/2026-06-02-for-windows-trying-to-standardize-on-highest/index.md
index 52fc9dd..cafbed1 100644
--- a/archive/threads/NOTimothyLottes/2026-06-02-for-windows-trying-to-standardize-on-highest/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-02-for-windows-trying-to-standardize-on-highest/index.md
@@ -25,10 +25,10 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2061937134756380682
 
 For Windows trying to standardize on HIGHEST_PRIORITY_CLASS, mixed with THREAD_PRIORITY_{IDLE,NORMAL,TIME_CRITICAL}. Which maps to {1, 13, 15} respectively. Then trying "Pro Audio" hack with AVRT to get whatever that gives in the 16-31 fake "realtime" bracket for highest.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2061937679575429246
 
 Linux mapping will be {SCHED_IDLE, SCHED_OTHER with 2 settings of nice} to match. Unfortunately SCHED_FIFO is locked out by default, but if the user blesses the right permissions will get better audio latency. Maybe pause/unpause will trigger auto latency re-adaption.
diff --git a/archive/threads/NOTimothyLottes/2026-06-02-its-unfortunate-there-isnt-an-easy-way-to-map-the/index.md b/archive/threads/NOTimothyLottes/2026-06-02-its-unfortunate-there-isnt-an-easy-way-to-map-the/index.md
index 8310191..bac06ca 100644
--- a/archive/threads/NOTimothyLottes/2026-06-02-its-unfortunate-there-isnt-an-easy-way-to-map-the/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-02-its-unfortunate-there-isnt-an-easy-way-to-map-the/index.md
@@ -25,6 +25,6 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2061933917137932437
 
 It's unfortunate there isn't an easy way to map the page file so that writes don't automagically post to storage, meaning map then turn off flush until a time desired by the programmer.
diff --git a/archive/threads/NOTimothyLottes/2026-06-03-back-running-640x480-on-my-vga-crts-to-prep-for/index.md b/archive/threads/NOTimothyLottes/2026-06-03-back-running-640x480-on-my-vga-crts-to-prep-for/index.md
index f301b6f..2e7d992 100644
--- a/archive/threads/NOTimothyLottes/2026-06-03-back-running-640x480-on-my-vga-crts-to-prep-for/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-03-back-running-640x480-on-my-vga-crts-to-prep-for/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2062031187023982879
 
 Back running 640x480 on my VGA CRTs to prep for workflow that ports down to 480i60 for NTSC. Using my 'right' font. Fully decoupling from all system calls for time is working out great. And yes I'm using all the stuff I talked about in my Advanced Aliasing talk too (joy to code).
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-dinit-is-out-no-c-for-me-so-runit-wins-by-default.md b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-dinit-is-out-no-c-for-me-so-runit-wins-by-default.md
index 5d63fce..8e9e2d8 100644
--- a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-dinit-is-out-no-c-for-me-so-runit-wins-by-default.md
+++ b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-dinit-is-out-no-c-for-me-so-runit-wins-by-default.md
@@ -26,7 +26,7 @@ parent_post_id: "2064858927829745887"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2064869304294641903
 
 'dinit' is out (no C++ for me) - so runit wins by default [also future desire to run busybox, so it's the natural choice]
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-going-to-give-artix-lxqt-runit-variation-a-try.md b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-going-to-give-artix-lxqt-runit-variation-a-try.md
index b7bb690..a9dcd69 100644
--- a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-going-to-give-artix-lxqt-runit-variation-a-try.md
+++ b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-going-to-give-artix-lxqt-runit-variation-a-try.md
@@ -26,15 +26,15 @@ parent_post_id: "2064858927829745887"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2064877857252291055
 
 Going to give artix-lxqt-runit variation a try. Mostly just a stop gap to see if I can actually get a bloated Linux system installed before a more serious effort with BuildRoot. First de-windows victim computer will be an AMD powered APU.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2064902414243631277
 
 Looks like the workaround for my locked UEFI secure boot Enabled on the second machine was to "Set Supervisor Password", afterwords I could disable secure boot and APM, but still no way to enable legacy BIOS "Boot Mode".
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2064922357186077053
 
 Somewhat surprised, Artix using the graphical install just worked out of the box (AMD APU). Got confused post install when 'top' shows 'Xorg' instead of 'XLibre' but the package manager says XLibre is installed.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-RouaniJihad-my-patience-is-this-thin-with-win11-right-now-but.md b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-RouaniJihad-my-patience-is-this-thin-with-win11-right-now-but.md
index 2b8a7f6..011a241 100644
--- a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-RouaniJihad-my-patience-is-this-thin-with-win11-right-now-but.md
+++ b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-RouaniJihad-my-patience-is-this-thin-with-win11-right-now-but.md
@@ -26,9 +26,9 @@ parent_post_id: "2064858927829745887"
 
 ## Branch
 
-**1/** @RouaniJihad
+**1/** **@RouaniJihad** ^2064865782870294858
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 My patience is this 🤏 thin with win11 right now, but Linux sounds like too much work, Mac is probably easier with more native software
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-mcnabbd-fascinating-to-me-how-this-challenge-would-have.md b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-mcnabbd-fascinating-to-me-how-this-challenge-would-have.md
index 853354f..139904a 100644
--- a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-mcnabbd-fascinating-to-me-how-this-challenge-would-have.md
+++ b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-mcnabbd-fascinating-to-me-how-this-challenge-would-have.md
@@ -26,15 +26,15 @@ parent_post_id: "2064858927829745887"
 
 ## Branch
 
-**1/** @mcnabbd
+**1/** **@mcnabbd** ^2064875327617396915
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 fascinating to me how this challenge would have captivated me a couple decades ago but now i just wanna run away
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2064876889177457052
 
-@mcnabbd
+**@mcnabbd**
 
 Similar feelings. Used to build linux from scratch in the BIOS era, also ran FreeBSD/etc, just for fun. But things had been easier then. Now years of technical debt later, all my tolerance for complexity has been fully exhausted.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/index.md b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/index.md
index 83b171a..50bbcb3 100644
--- a/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/index.md
@@ -25,20 +25,20 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2064858927829745887
 
 So I'm on Linux now, but obviously I cheated, because this is a SteamOS machine (pre-installed). Need to re-learn enough to be able to make responsible choices on a new install. First up what init system to do? {openrc, runit, s6, or dinit}.
 
 Branches: [[archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-RouaniJihad-my-patience-is-this-thin-with-win11-right-now-but]], [[archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-NOTimothyLottes-dinit-is-out-no-c-for-me-so-runit-wins-by-default]], [[archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated/2026-06-11-mcnabbd-fascinating-to-me-how-this-challenge-would-have]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2064877857252291055
 
 Going to give artix-lxqt-runit variation a try. Mostly just a stop gap to see if I can actually get a bloated Linux system installed before a more serious effort with BuildRoot. First de-windows victim computer will be an AMD powered APU.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2064902414243631277
 
 Looks like the workaround for my locked UEFI secure boot Enabled on the second machine was to "Set Supervisor Password", afterwords I could disable secure boot and APM, but still no way to enable legacy BIOS "Boot Mode".
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2064922357186077053
 
 Somewhat surprised, Artix using the graphical install just worked out of the box (AMD APU). Got confused post install when 'top' shows 'Xorg' instead of 'XLibre' but the package manager says XLibre is installed.
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/2026-06-13-tomcr2100-interesting-font-does-it-have-a-name.md b/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/2026-06-13-tomcr2100-interesting-font-does-it-have-a-name.md
index 9954a4a..fe6e02b 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/2026-06-13-tomcr2100-interesting-font-does-it-have-a-name.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/2026-06-13-tomcr2100-interesting-font-does-it-have-a-name.md
@@ -26,9 +26,9 @@ parent_post_id: "2065832746757341482"
 
 ## Branch
 
-**1/** @tomcr2100
+**1/** **@tomcr2100** ^2065909746536747274
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Interesting font, does it have a name?
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/index.md b/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/index.md
index a157784..898ed73 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2065832746757341482
 
 Cross compilation is up. Just like on windows with GCC I have to disable all warnings because there is no way to turn off “function called through a non-compatible type”. They obviously should have had warning IDs and an ID based disable.
 
@@ -34,13 +34,13 @@ Cross compilation is up. Just like on windows with GCC I have to disable all war
 
 Branches: [[archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up/2026-06-13-tomcr2100-interesting-font-does-it-have-a-name]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065833669516816492
 
 Found my first of perhaps many Wine “fix me”s looks like they didn’t emulate NtQuerySystemInformation() for use to get the TSC time scalar. Also implies all PC devs do this wrong, else Valve would have had this implemented already.
 
-**3/** @never_released
+**3/** **@never_released** ^2066021954486755450
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Intriguingly Microsoft documentation has this bit
 
@@ -50,8 +50,8 @@ https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolutio
 
 ![](https://pbs.twimg.com/media/HKv7lkRXAAA5ZdO?format=jpg&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2066023880557281310
 
-@never_released
+**@never_released**
 
 It will be a sad day when we have to be concerned about VM migration while playing a game on a local machine
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and.md
index 1c16a7f..014a8c3 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and.md
@@ -26,15 +26,15 @@ parent_post_id: "2065840191340707905"
 
 ## Branch
 
-**1/** @BonbliStar
+**1/** **@BonbliStar** ^2065944487075975648
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 most futex impls i've seen check for that and early return before the syscall, but you likely already knew that
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065998673117376693
 
-@BonbliStar
+**@BonbliStar**
 
 Yes, the comment was more the point of designing for the worst case, the limit of possibly blocking calls that interact with the scheduling.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-NOTimothyLottes-the-glibc-implementation-would-do-that-i-bypass.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-NOTimothyLottes-the-glibc-implementation-would-do-that-i-bypass.md
index c9037e2..da31c97 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-NOTimothyLottes-the-glibc-implementation-would-do-that-i-bypass.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-NOTimothyLottes-the-glibc-implementation-would-do-that-i-bypass.md
@@ -26,9 +26,9 @@ parent_post_id: "2065851939917906296"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2065872197147578751
 
-@axelgneiting
+**@axelgneiting**
 
 The glibc implementation would do that. I bypass libc and just do it manually with perf_event_open syscall and mmap.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm.md
index 9aadc47..8ebe746 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm.md
@@ -26,17 +26,17 @@ parent_post_id: "2065840191340707905"
 
 ## Branch
 
-**1/** @raggi
+**1/** **@raggi** ^2065865513608307103
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 nanosleep(0) will sleep for the timer slack
 
 _mm_pause() if you want to avoid a context switch and keep your scheduler quantum
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065876017277772143
 
-@raggi
+**@raggi**
 
 I do that via inline asm to save power. This was more a comment on the cost of actually using the futex system call, need to be careful about the call frequency
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates.md
index 4c7363f..10e71f1 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates.md
@@ -26,27 +26,27 @@ parent_post_id: "2065840191340707905"
 
 ## Branch
 
-**1/** @rflaherty71
+**1/** **@rflaherty71** ^2065859701909459406
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Seems like people trying to push high frame rates would be perfectly fine with just busy spinning at that point
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065876612881551764
 
-@rflaherty71
+**@rflaherty71**
 
 Not exactly true, the larger problem is getting context switched at a bad time, so getting non-blocking bound comes with another set of dangers (higher bad preemption risk)
 
-**3/** @AgileJebrim
+**3/** **@AgileJebrim** ^2065902481918341310
 
-@NOTimothyLottes @rflaherty71
+**@NOTimothyLottes** **@rflaherty71**
 
 All the more reason to go GPU-side where that can’t occur.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2066002894877266034
 
-@AgileJebrim @rflaherty71
+**@AgileJebrim** **@rflaherty71**
 
 Consumer GPU side is littered with junk these days, starting with multi display compositors.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while.md
index 4317a00..025d193 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while.md
@@ -26,7 +26,7 @@ parent_post_id: "2065840191340707905"
 
 ## Branch
 
-**1/** @winning_tactic
+**1/** **@winning_tactic** ^2065896862129733922
 
 Why not do a gradual sleeping? Start with
 while (spin--) {
@@ -39,27 +39,27 @@ You can have power modes that sets a lower threshhold to always yield and not sp
 
 But I've never considered a write to a dummy file as a legitimate yield/wait trigger. I wonder how that would fit in to my solution...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2066002050064798174
 
-@winning_tactic
+**@winning_tactic**
 
 I don’t design around waiting for a specific point in time, I do other things, but talk about them when I can easily show the results
 
-**3/** @winning_tactic
+**3/** **@winning_tactic** ^2066004392088658074
 
 Correct. But that's the point of gradually backoff, active spinlocking, then green thread yielding (cooperative other tasks, maybe even the one contesting) then kernel_poke (I guess that's what I would call that writing to file its a return from kernel-land immediately) then timer fired, the idea isn't to wait on a time, it's wait on an increasing value that changes tactics from the previous waits so that you don't really have to keep track of when what happens.
 https://gitlab.com/qsrc.net/Lampyr/-/blob/dev/rt/time.c?ref_type=heads#L78
 But I've got to work on the power stuff and steal your idea of course.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2066006932599533982
 
-@winning_tactic
+**@winning_tactic**
 
 Ahh the illusion of nonblocking execution on consumer devices. The moment the os decides to preempt your thread, there no longer exists a non blocking interface. A single thread never gets a guarantee of execution, so waiting for some exact point in time is failed design
 
-**5/** @winning_tactic
+**5/** **@winning_tactic** ^2066009122739237175
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 It's green threads multiplexed on pinned threads both cooperatively and preemptively. I beg your pardon!~
 https://gitlab.com/qsrc.net/Lampyr/-/blob/dev/rt/task.c?ref_type=heads
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/index.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/index.md
index 7e80cd0..d4cea16 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/index.md
@@ -25,12 +25,12 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2065840191340707905
 
 Interesting how on this Linux box, scheduling NOPs like nanosleep of 0 and futex waiting on an already set memory location … both take around 60 microseconds, cannot afford to do many of those per millisecond. Food for thought for high fps targets
 
 Branches: [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates]], [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm]], [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while]], [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065840616148193294
 
 A write of zero bytes is closer to say 6 microseconds in contrast, so just the user/kernel transition is expensive but 10x faster
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-eternalclassic_-you-can-use-camac-free-to-take-raw-photos-on.md b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-eternalclassic_-you-can-use-camac-free-to-take-raw-photos-on.md
index a88f2a5..0a444e0 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-eternalclassic_-you-can-use-camac-free-to-take-raw-photos-on.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-eternalclassic_-you-can-use-camac-free-to-take-raw-photos-on.md
@@ -26,15 +26,15 @@ parent_post_id: "2065804972378243476"
 
 ## Branch
 
-**1/** @eternalclassic_
+**1/** **@eternalclassic_** ^2065854318817816626
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 you can use camac (free) to take raw photos on iphone without post-processing shit
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065872329402442195
 
-@eternalclassic_
+**@eternalclassic_**
 
 Will have to try that thanks
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-quiveron_x-why-are-you-using-crt.md b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-quiveron_x-why-are-you-using-crt.md
index 792e7ef..0e620ba 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-quiveron_x-why-are-you-using-crt.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-quiveron_x-why-are-you-using-crt.md
@@ -26,19 +26,19 @@ parent_post_id: "2065804972378243476"
 
 ## Branch
 
-**1/** @quiveron_x
+**1/** **@quiveron_x** ^2065848389875458358
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Why are you using CRT
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065850045975474547
 
-@quiveron_x
+**@quiveron_x**
 
 Still the best display technology IMO. Low persistence, analog, variable resolution, smooth continuous blended signal, deep blacks, great contrast, etc.
 
-**3/** @quiveron_x
+**3/** **@quiveron_x** ^2065851423489937868
 
 I completely agree, I asked because I was wondering if you were planning on doing something specific.
 I think we gave up on them too early, they felt good to use, pleasant to look at, only negative side is they were too heavy. People obsessing over resolution don't realize if image is shit it doesn't matter if it's 4k or 8k
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-winning_tactic-hz-sharing-i-wonder-if-crts-can-be-changed-like.md b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-winning_tactic-hz-sharing-i-wonder-if-crts-can-be-changed-like.md
index 06b2f04..0b833c2 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-winning_tactic-hz-sharing-i-wonder-if-crts-can-be-changed-like.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-winning_tactic-hz-sharing-i-wonder-if-crts-can-be-changed-like.md
@@ -26,9 +26,9 @@ parent_post_id: "2065804972378243476"
 
 ## Branch
 
-**1/** @winning_tactic
+**1/** **@winning_tactic** ^2065886660747796581
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Hz sharing? I wonder if CRTs can be changed like 60 -> 59 Hz, and if that would correct it? I do not know whether any is correct, but I'd betcha there's some kinda thing there about that. Why would the iphone has .. no it's not mechanical, so I have no clue but that is a puzzle
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-14-mayemayey-ohh-what-is-that-a-2070sb.md b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-14-mayemayey-ohh-what-is-that-a-2070sb.md
index b7bbdee..a41d485 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-14-mayemayey-ohh-what-is-that-a-2070sb.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-14-mayemayey-ohh-what-is-that-a-2070sb.md
@@ -26,39 +26,39 @@ parent_post_id: "2065804972378243476"
 
 ## Branch
 
-**1/** @mayemayey
+**1/** **@mayemayey** ^2066072383954288814
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 ohh what is that? a 2070SB?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2066182371808776318
 
-@mayemayey
+**@mayemayey**
 
 FP2141SB
 
-**3/** @mayemayey
+**3/** **@mayemayey** ^2066199206457495922
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 yep. that's a rebranded 2070sb haha. there's an hsync/vsync (~152khz, 254hz) overclocking tutorial if you ever feel daring enough to. 😉
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2066260423540675020
 
-@mayemayey
+**@mayemayey**
 
 Those crazy refresh rates are long past diminishing returns though due to the fixed phosphor decay. Great display, only big flaw is the vertical nonlinearity at the extreme top and bottom.
 
-**5/** @mayemayey
+**5/** **@mayemayey** ^2066403191860732086
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 do you have any blurriness in the corners?
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2066507632307847327
 
-@mayemayey
+**@mayemayey**
 
 It might if I ran it at peak resolutions but I mostly stick to higher refresh rates instead, so wouldn’t notice.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/index.md b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/index.md
index 777e11d..dd0d708 100644
--- a/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/index.md
@@ -25,19 +25,19 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2065804972378243476
 
 Nanorc done and back to actual programming with the new font. The iPhone cannot seem to correctly capture a CRT anymore … and yes my _ is … and my ; is a 5 dot vertical line (prefer that for C/GLSL coding)
 
 ![](https://pbs.twimg.com/media/HKs2q8RXQAAVsjN?format=jpg&name=orig)
 Branches: [[archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-quiveron_x-why-are-you-using-crt]], [[archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-eternalclassic_-you-can-use-camac-free-to-take-raw-photos-on]], [[archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-13-winning_tactic-hz-sharing-i-wonder-if-crts-can-be-changed-like]], [[archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with/2026-06-14-mayemayey-ohh-what-is-that-a-2070sb]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2065806847634776401
 
 Thankfully I can still dedecorate the term window to focus lines for useful content. Practically speaking I almost have a new language implemented in C via typedefs and macros … back to building and testing the native Linux system level interface
 
 ![](https://pbs.twimg.com/media/HKs4YE5WMAAfe6G?format=jpg&name=orig)
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2065809876488503805
 
 Lubbers are invading my screen
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-14-Social_Vulture-running-in-crt-or-are-you-emulating-scanlines-in.md b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-14-Social_Vulture-running-in-crt-or-are-you-emulating-scanlines-in.md
index 7b7991a..e269baa 100644
--- a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-14-Social_Vulture-running-in-crt-or-are-you-emulating-scanlines-in.md
+++ b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-14-Social_Vulture-running-in-crt-or-are-you-emulating-scanlines-in.md
@@ -26,9 +26,9 @@ parent_post_id: "2066184005632786736"
 
 ## Branch
 
-**1/** @Social_Vulture
+**1/** **@Social_Vulture** ^2066190873235206299
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Running in CRT or are you emulating scanlines in your editor?
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-GrowlerEnjooyer-there-is-0-chance-you-actually-use-this-font-its.md b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-GrowlerEnjooyer-there-is-0-chance-you-actually-use-this-font-its.md
index f4cc626..9ba9510 100644
--- a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-GrowlerEnjooyer-there-is-0-chance-you-actually-use-this-font-its.md
+++ b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-GrowlerEnjooyer-there-is-0-chance-you-actually-use-this-font-its.md
@@ -26,27 +26,27 @@ parent_post_id: "2066184005632786736"
 
 ## Branch
 
-**1/** @GrowlerEnjooyer
+**1/** **@GrowlerEnjooyer** ^2066465370689732716
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 There is 0 chance you actually use this font. It's for the meme, right?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2066508385600598172
 
-@GrowlerEnjooyer
+**@GrowlerEnjooyer**
 
 Oh I definitely use this font, was designed to be extremely easy to visually parse for code.
 
-**3/** @GrowlerEnjooyer
+**3/** **@GrowlerEnjooyer** ^2066510991014432852
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Bravo, well played Mr troll
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2066556689483002354
 
-@GrowlerEnjooyer
+**@GrowlerEnjooyer**
 
 Not trolling, actually do use the font for my terminals on that dev box
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-sadhuIGI-also-this-font-is-cursed.md b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-sadhuIGI-also-this-font-is-cursed.md
index e46e8a3..d57bd9b 100644
--- a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-sadhuIGI-also-this-font-is-cursed.md
+++ b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/2026-06-15-sadhuIGI-also-this-font-is-cursed.md
@@ -26,9 +26,9 @@ parent_post_id: "2066184005632786736"
 
 ## Branch
 
-**1/** @sadhuIGI
+**1/** **@sadhuIGI** ^2066453103344292290
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Also this font is cursed
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/index.md b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/index.md
index 7accc95..a02a80f 100644
--- a/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2066184005632786736
 
 On Linux I do speculative pinning of CPU memory via mlockall. Learned that later Linux actually allows some amount of pinned memory without admin. So this is succeeding on my new Artix box.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-AgileJebrim-sendmmsg-recvmmsg-can-only-work-with-1024-packets.md b/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-AgileJebrim-sendmmsg-recvmmsg-can-only-work-with-1024-packets.md
index b37cc7b..759bbd2 100644
--- a/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-AgileJebrim-sendmmsg-recvmmsg-can-only-work-with-1024-packets.md
+++ b/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-AgileJebrim-sendmmsg-recvmmsg-can-only-work-with-1024-packets.md
@@ -26,37 +26,37 @@ parent_post_id: "2070337342854832468"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^2070338320765165758
 
 sendmmsg/recvmmsg can only work with 1024 packets at a time unfortunately. You’ve gotta loop them. While they’re surprisingly fairly deterministic in execution times, their throughput isn’t the best. The Linux kernel takes far longer to process sending the packets out than my own code does to process the sim and build the packets in the first place lol.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2070343193963397129
 
-@AgileJebrim
+**@AgileJebrim**
 
 Yes 1024 max, so best case 1/1024 the syscall count (well factored). As for overhead, for a co-located server you could always hijack the network card driver and just move your server into it and run kernel side if you really wanted to.
 
-**3/** @AgileJebrim
+**3/** **@AgileJebrim** ^2070343454048039360
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 If you want to be locked in to a particular NIC yeah.
 
-**4/** @aepau2
+**4/** **@aepau2** ^2070408887455420544
 
-@AgileJebrim @NOTimothyLottes
+**@AgileJebrim** **@NOTimothyLottes**
 
 You can use eBPF as a poor man's kernel bypass.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2070461630165532941
 
-@aepau2 @AgileJebrim
+**@aepau2** **@AgileJebrim**
 
 Not that any of my source would pass their nanny tester. When I was younger and running my own business, I used to host my business website off of a really old laptop running an in-kernel web server that I wrote. It wasn’t that hard to do long ago.
 
-**6/** @AgileJebrim
+**6/** **@AgileJebrim** ^2070473555070836962
 
-@NOTimothyLottes @aepau2
+**@NOTimothyLottes** **@aepau2**
 
 eBPF doesn’t support SIMD lol
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-BigP4P4Smurf-take-a-look-at-http-lalists-stanford-edu-lad-2001.md b/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-BigP4P4Smurf-take-a-look-at-http-lalists-stanford-edu-lad-2001.md
index b94c7d7..09a47df 100644
--- a/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-BigP4P4Smurf-take-a-look-at-http-lalists-stanford-edu-lad-2001.md
+++ b/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/2026-06-26-BigP4P4Smurf-take-a-look-at-http-lalists-stanford-edu-lad-2001.md
@@ -26,9 +26,9 @@ parent_post_id: "2070337342854832468"
 
 ## Branch
 
-**1/** @BigP4P4Smurf
+**1/** **@BigP4P4Smurf** ^2070411240514420892
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Take a look at http://lalists.stanford.edu/lad/2001/Nov/0248.html
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/index.md b/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/index.md
index 85bd6ca..9a1a390 100644
--- a/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2070337342854832468
 
 Quick summary of why not {pselect, ppoll, epoll_pwait2} style non-TCP IO [it can amplify kernel transitions]. For UDP stuff blocking {sendmmsg,recvmmsg (with timeout)} amortizes out kernel transitions.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-27-deterrent-to-alsa-is-just-parsing-through-snd-pcm/index.md b/archive/threads/NOTimothyLottes/2026-06-27-deterrent-to-alsa-is-just-parsing-through-snd-pcm/index.md
index 49e8c49..0ce2dfc 100644
--- a/archive/threads/NOTimothyLottes/2026-06-27-deterrent-to-alsa-is-just-parsing-through-snd-pcm/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-27-deterrent-to-alsa-is-just-parsing-through-snd-pcm/index.md
@@ -25,12 +25,12 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2070734717825986566
 
 Deterrent to ALSA is just parsing through snd_pcm_open() source. It's death by boiler plate and complexity. Tinyalsa isn't much better. Likely easier to think about this from perspective of devices that can be open()ed from /dev/snd. On my machine doesn't seem to hot plug
 
 ![](https://pbs.twimg.com/media/HLy5-C9XMAAfs_w?format=png&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2070735722043023873
 
 Assuming 'p'&'c' are PLAYBACK & CAPTURE, so opening different devices (instead of both in one device). Then just have user provide a device, or have the API war-dial open() constructing possible devices to probe what is available 'pcmC{c}D{d}{p|c}'. Easier than listing files.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-29-AlexABPerson-have-you-actually-reached-out-to-said-developers.md b/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-29-AlexABPerson-have-you-actually-reached-out-to-said-developers.md
index ffbe15f..e68cb3a 100644
--- a/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-29-AlexABPerson-have-you-actually-reached-out-to-said-developers.md
+++ b/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-29-AlexABPerson-have-you-actually-reached-out-to-said-developers.md
@@ -26,27 +26,27 @@ parent_post_id: "2071706805114216559"
 
 ## Branch
 
-**1/** @AlexABPerson
+**1/** **@AlexABPerson** ^2071714528635527401
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Have you actually reached out to said developers and offered to start a documentation effort/ask them some questions about things? It seems a little unfair to be rage posting about this all the time when the point is you (and me, and everyone) have the power to make it better.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2071718568899624987
 
-@AlexABPerson
+**@AlexABPerson**
 
 Haha I could start that with an email: hello godly ALSA dev, as a vintage pee-on programmer from the stone age, I was trying to ignore your advice about using the user-space API and thus needing GPL, and instead using the undocumented IOCTLs of the kernel driver directly ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2071720126966034812
 
-@AlexABPerson
+**@AlexABPerson**
 
 But on a serious note, I mostly shit post for the entertainment, because once in a while I actually learn something from a response. And often documenting the process might help someone else too ...
 
-**4/** @AlexABPerson
+**4/** **@AlexABPerson** ^2071741638162956648
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 That's fair, thank you for the honest reply! It *is* interesting to see a lot of these sorts of inner workings, and I definitely sympathise with the "I can't believe it works like this" feeling 😂 Stuff does have a tendency to get like that huh
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-30-mrsteyk1-tinyplay-does-sndrv-pcm-ioctl-hw-params-ioctl.md b/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-30-mrsteyk1-tinyplay-does-sndrv-pcm-ioctl-hw-params-ioctl.md
index 447c23c..fd01697 100644
--- a/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-30-mrsteyk1-tinyplay-does-sndrv-pcm-ioctl-hw-params-ioctl.md
+++ b/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-30-mrsteyk1-tinyplay-does-sndrv-pcm-ioctl-hw-params-ioctl.md
@@ -26,23 +26,23 @@ parent_post_id: "2071725181576319370"
 
 ## Branch
 
-**1/** @mrsteyk1
+**1/** **@mrsteyk1** ^2071774178374812018
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 tinyplay does SNDRV_PCM_IOCTL_HW_PARAMS ioctl (referenced in the article alongside REFINE)
 
 ![](https://pbs.twimg.com/media/HMBrjrxbkAAID_C?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2071777347888455933
 
-@mrsteyk1
+**@mrsteyk1**
 
 I believe the method the ALSA people wanted users to go by was to first REFINE to grab the full PCM limits, then iteratively make changes (via REFINE ioctl) until it converges to one configuration, at which point the HW_PARAMS ioctl is used to finalize that config.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2071778086111105025
 
-@mrsteyk1
+**@mrsteyk1**
 
 Maybe it works sometimes to just use HW_PARAMs directly, but I have not got that working. I also cannot seem to get the refinement process to work either. And I don't get error returns, so still no idea what is wrong yet.
 
diff --git a/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/index.md b/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/index.md
index 0145e6c..162fd6a 100644
--- a/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2071706805114216559
 
 ALSA hell month continues: remember it might be "open source" but it is definitely "closed documentation" [those docs are securely trapped in the minds of the authors]. Now that I have aplay playing a sound, it's time for garbage sifting through STRACE to see what is going on ...
 
@@ -33,35 +33,35 @@ ALSA hell month continues: remember it might be "open source" but it is definite
 
 Branches: [[archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-29-AlexABPerson-have-you-actually-reached-out-to-said-developers]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2071710958397898929
 
 For devs working on linux, strace is a good friend, besides reverse engineering undocumented crap, it's useful to run on your own app as a bug test, like look what this idiot [me] did with nanosleep()
 
 ![](https://pbs.twimg.com/media/HMAx0PmW0AAdUAy?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2071714384225681440
 
 In my ALSA interface I war-dial the possible /dev/snd/pcm devices instead of just listing the directory. It's a lot easier in source code.
 
 ![](https://pbs.twimg.com/media/HMA1CA9XIAAwRAB?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2071715941688258752
 
 Using 'strace' showed another bug in my setting schedule priority code (I didn't yet validate that code and check for errors). Definitely my ALSA test app shows ZERO errors in ALSA system calls, but doesn't actually play anything. Broken without errors = crappy API.
 
 ![](https://pbs.twimg.com/media/HMA2LibWMAAMW3O?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2071716495667708051
 
 In theory a good API, SNDRV_PCM_IOCTL_PREPARE would fail if the next SNDRV_PCM_IOCTL_WRITEI_FRAMES wouldn't accept the write. And that WRITEI should also fail instead of pass and setting .result=0 (of the snd xferi structure).
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2071717187623030935
 
 The best I can guess thus far is that the aplay app goes through some HW_REFINE ioctls before setting the HW_PARAMS, and perhaps the "magic missing thing" is in that process.
 
 ![](https://pbs.twimg.com/media/HMA3sGVXwAAVDMT?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2071725181576319370
 
 Best docs on REFINE that I've found yet is indirectly through this. Note tinyalsa doesn't seem to use this interface other than through pcm_params_get(), not the interative process seen in aplay strace. Maybe because tinyalsa is for android (different drivers)
 
@@ -69,14 +69,14 @@ Best docs on REFINE that I've found yet is indirectly through this. Note tinyals
 
 Branches: [[archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-30-mrsteyk1-tinyplay-does-sndrv-pcm-ioctl-hw-params-ioctl]]
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^2071759816725311959
 
 SNDRV_PCM_IOCTL_HW_REFINE
 If send out a zeroed snd_pcm_hw_params, the ioctl will fail. There is a special magic sauce to the structure that must be initialized correctly before you can even fetch hardware parameters. It's high level skill in Obfuscation. See *_any( in ALSA src
 
 ![](https://pbs.twimg.com/media/HMBePMXXwAE5_1M?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^2071760520852410838
 
 magiz/
 clear snd_pcm_hw_params
@@ -85,11 +85,11 @@ set intervals[0 ... 11].max=~0
 set rmask=~0
 set info=~0
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^2071767401411084399
 
 The rmask and cmask use bit indexed by the DEFINE so 
 1<<SNDRV_PCM_HW_PARAM_{thing}
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^2071769518246953293
 
 Hats off to Abramo Bagnara of the ALSA project for the worst kernel system interface I have ever used in my life. This refinement required just to configure an audio device is a master class on the worst way to do something. And still have a few hours left in reverse engineering
diff --git a/archive/threads/NOTimothyLottes/2026-06-29-eventually-figure-out-enough-to-get-aplay-to/index.md b/archive/threads/NOTimothyLottes/2026-06-29-eventually-figure-out-enough-to-get-aplay-to/index.md
index 70f90a5..38a15b4 100644
--- a/archive/threads/NOTimothyLottes/2026-06-29-eventually-figure-out-enough-to-get-aplay-to/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-29-eventually-figure-out-enough-to-get-aplay-to/index.md
@@ -25,12 +25,12 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2071415096304193820
 
 Eventually figure out enough to get aplay to actually play a wave file, had to find an explicitly stereo wav else it would refuse to just duplicate the mono channels. Basically the a'tools unfriendlyness mirrors that of ALSA. Still cannot understand 'boundary' ...
 
 ![](https://pbs.twimg.com/media/HL8km6eWsAEq6xb?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2071445744389611593
 
 No luck getting ALSA to play anything from my app. State is always 2 SNDRV_PCM_STATE_PREPARED, haven't been able to get it to run. If I try the start ioctl, then it errors with -EPIPE.
diff --git a/archive/threads/NOTimothyLottes/2026-06-30-working-on-the-linux-thread-priority-code/index.md b/archive/threads/NOTimothyLottes/2026-06-30-working-on-the-linux-thread-priority-code/index.md
index bf1d02c..8d22e42 100644
--- a/archive/threads/NOTimothyLottes/2026-06-30-working-on-the-linux-thread-priority-code/index.md
+++ b/archive/threads/NOTimothyLottes/2026-06-30-working-on-the-linux-thread-priority-code/index.md
@@ -25,16 +25,16 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2071937360288235902
 
 Working on the Linux thread priority code. Linux doesn't allow sched_attr.size to be minimized to just what is required for the scheduling mode (my prior bug). So I statically allocate the structures already filled in and cacheline aligned ...
 
 ![](https://pbs.twimg.com/media/HMD_iq0XcAASnSn?format=png&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2071938112175890466
 
 Theory says: better for size, worse for perf! Global structure will miss the cache. The alternative is to allow the code to generate the structure on the stack, which is likely in cache, and burn a few more cachelines of code (which gets linear prefetch).
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2071938677584863448
 
 Clearly the default linux won't allow my non-blessed user to get SCHED_FIFO, and it also seems like my nice(-20) SCHED_OTHER backup is also not allowed either. Damn. More stuff to workaround.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-01-did-manage-to-get-alsa-to-function-without-sndrv/index.md b/archive/threads/NOTimothyLottes/2026-07-01-did-manage-to-get-alsa-to-function-without-sndrv/index.md
index dc5fcc2..737f7e7 100644
--- a/archive/threads/NOTimothyLottes/2026-07-01-did-manage-to-get-alsa-to-function-without-sndrv/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-01-did-manage-to-get-alsa-to-function-without-sndrv/index.md
@@ -25,11 +25,11 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2072194202851549432
 
 Did manage to get ALSA to function without SNDRV_PCM_IOCTL_HW_REFINE and only with SNDRV_PCM_IOCTL_HW_PARAMS. My structures are different but aliased (snd_interval.interger -> .flag=4). Apparently setting the core values is enough for the driver.
 
 ![](https://pbs.twimg.com/media/HMHoiZAWcAAjn6j?format=png&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2072195623265178013
 
 Don't actually have to set {.flags,.rmask,.info} on my machine. Absolutely do have to set ".max=~0" for the intervals not being hardcoded. I only do double buffered, 48000Hz stereo, and just vary the frames/period sizing.
diff --git a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-never_released-theres-a-lot-of-old-news-around-1-wine-doesnt.md b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-never_released-theres-a-lot-of-old-news-around-1-wine-doesnt.md
index 2bf6d7b..86e658a 100644
--- a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-never_released-theres-a-lot-of-old-news-around-1-wine-doesnt.md
+++ b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-never_released-theres-a-lot-of-old-news-around-1-wine-doesnt.md
@@ -26,9 +26,9 @@ parent_post_id: "2072447378242552093"
 
 ## Branch
 
-**1/** @never_released
+**1/** **@never_released** ^2072462016803926439
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 There's a lot of old news around.
 
@@ -37,9 +37,9 @@ There's a lot of old news around.
 
 This explicitly blocks this trick. Please do not use it
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2072472166256312444
 
-@never_released
+**@never_released**
 
 Well they could put it on a command line toggle. Or have some other back door. Today I’m blocked on wine ntdll compatibility with bugs filed. So Im still looking for workarounds, going direct to Linux syscalls would have been the best and easiest option.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-opdroid1234-the-two-truths-ive-come-to-accept-in-life-a.md b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-opdroid1234-the-two-truths-ive-come-to-accept-in-life-a.md
index 0614698..63f5cab 100644
--- a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-opdroid1234-the-two-truths-ive-come-to-accept-in-life-a.md
+++ b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-opdroid1234-the-two-truths-ive-come-to-accept-in-life-a.md
@@ -26,9 +26,9 @@ parent_post_id: "2072445315370590266"
 
 ## Branch
 
-**1/** @opdroid1234
+**1/** **@opdroid1234** ^2072447876987314447
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 the two truths ive come to accept in life
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-SheriefFYI-i-was-just-about-to-say-i-recall-pulling-this-off.md b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-SheriefFYI-i-was-just-about-to-say-i-recall-pulling-this-off.md
index ddda25a..61582fa 100644
--- a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-SheriefFYI-i-was-just-about-to-say-i-recall-pulling-this-off.md
+++ b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-SheriefFYI-i-was-just-about-to-say-i-recall-pulling-this-off.md
@@ -26,9 +26,9 @@ parent_post_id: "2072447378242552093"
 
 ## Branch
 
-**1/** @SheriefFYI
+**1/** **@SheriefFYI** ^2072527709708915136
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I was just about to say I recall pulling this off before for _reasons_
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-winning_tactic-you-could-pretend-to-be-an-audio-jack.md b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-winning_tactic-you-could-pretend-to-be-an-audio-jack.md
index cfbb363..979fa00 100644
--- a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-winning_tactic-you-could-pretend-to-be-an-audio-jack.md
+++ b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-winning_tactic-you-could-pretend-to-be-an-audio-jack.md
@@ -26,9 +26,9 @@ parent_post_id: "2072445315370590266"
 
 ## Branch
 
-**1/** @winning_tactic
+**1/** **@winning_tactic** ^2072558923215712441
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 You could pretend to be an audio jack implementation? If impersonating wine doesn't work.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/index.md b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/index.md
index 84b7a9b..fd3a230 100644
--- a/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2072445315370590266
 
 Haha damn, I thought I had a great idea, for Wine workarounds, I could just detect Wine (easy), and then make the associated Linux system call from inside Wine using inline asm! [no surprise, it doesn't work]
 
@@ -33,7 +33,7 @@ Haha damn, I thought I had a great idea, for Wine workarounds, I could just dete
 
 Branches: [[archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-01-opdroid1234-the-two-truths-ive-come-to-accept-in-life-a]], [[archive/threads/NOTimothyLottes/2026-07-01-haha-damn-i-thought-i-had-a-great-idea-for-wine/2026-07-02-winning_tactic-you-could-pretend-to-be-an-audio-jack]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2072447378242552093
 
 https://gpfault.net/posts/drunk-exe.html - So it apparently is possible, likely I'm screwing up my register saves for the ABI differences ...
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-01-linux-by-default-doesnt-allow-any-increase-in/index.md b/archive/threads/NOTimothyLottes/2026-07-01-linux-by-default-doesnt-allow-any-increase-in/index.md
index 286de54..97dd9ba 100644
--- a/archive/threads/NOTimothyLottes/2026-07-01-linux-by-default-doesnt-allow-any-increase-in/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-01-linux-by-default-doesnt-allow-any-increase-in/index.md
@@ -25,16 +25,16 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2072135292115427728
 
 Linux by default doesn't allow any increase in scheduling priority. Users need to manually setup special user|group with elevated rights. Also system calls that try elevated scheduling don't clamp, instead they fail -EPREM if out of bounds. So all around a pain in the ass.
 
 ![](https://pbs.twimg.com/media/HMGz-64W4AABeaH?format=png&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2072136089070961073
 
 I'm a little lazy right now and don't feel like trying SteamOS big picture mode to see what the default ulimits are. Curious what they allow.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2072147378480566273
 
 Linux priority workarounds
 (a.) Use getrlimit() to get {soft,hard} limits
@@ -44,11 +44,11 @@ Linux priority workarounds
 ![](https://pbs.twimg.com/media/HMG-UCRXIAEKbdj?format=png&name=orig)
 
 ![](https://pbs.twimg.com/media/HMG-zRxWwAAWtI4?format=png&name=orig)
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2072147765157638479
 
 I don't do one-time global priority maximums, just in case someone sudo's higher priority hard limit dynamically it should pickup the new limit.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2072149707107787035
 
 Also while on setrlimit, I also bump up the RLIMIT_MEMLOCK to it's maximum just in case before the mlockall().
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-02-settings-im-using-for-snd-pcm-sw-params-for-alsa/index.md b/archive/threads/NOTimothyLottes/2026-07-02-settings-im-using-for-snd-pcm-sw-params-for-alsa/index.md
index 4f41674..bccd088 100644
--- a/archive/threads/NOTimothyLottes/2026-07-02-settings-im-using-for-snd-pcm-sw-params-for-alsa/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-02-settings-im-using-for-snd-pcm-sw-params-for-alsa/index.md
@@ -25,20 +25,20 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2072506103401754653
 
 Settings I'm using for snd_pcm_sw_params for ALSA, don't have docs for all of this, seems to work. I'm doing 64 frame period size on a double buffer right now without any thread priority, and not getting xruns, so not yet sure of bad behavior
 
 ![](https://pbs.twimg.com/media/HMMFAHiX0AAzY_R?format=png&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2072507664576164085
 
 I put in a forced thread sleep between writes to force a xrun, and SNDRV_PCM_IOCTL_WRITEI_FRAMES kernel call then returns -32, in which case I run a SNDRV_PCM_IOCTL_PREPARE and then just get back to the write loop, seems to restore normal playback just fine.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2072511121269928165
 
 I reduced asound.h to this basically, the most minimal thing I found I needed. Now I also rename a few things (like structure names), and my IOCTL macros are slightly different in composition than standard.
 
 ![](https://pbs.twimg.com/media/HMMJjYPWAAAY1IE?format=png&name=orig)
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2072511875074421142
 
 After getting this far, it actually looks quite easy, but the route to this was filled with garbage sifting because I couldn't easily find someone else who did this kind of minimalization. I'm only supporting 48KHz stereo 16-bit signed, with double buffering = keep it simple.
diff --git a/archive/threads/NOTimothyLottes/2026-07-02-yuck-starting-on-wdm-ks-audio-interface-for-win32/index.md b/archive/threads/NOTimothyLottes/2026-07-02-yuck-starting-on-wdm-ks-audio-interface-for-win32/index.md
index 8e77e62..4e3b1cb 100644
--- a/archive/threads/NOTimothyLottes/2026-07-02-yuck-starting-on-wdm-ks-audio-interface-for-win32/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-02-yuck-starting-on-wdm-ks-audio-interface-for-win32/index.md
@@ -25,23 +25,23 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2072804183992922296
 
 Yuck, starting on WDM/KS audio interface for WIN32, much more painful than ALSA. But I've been here before. Starting with the include bloat ... the real question is if I'm going to need to file more Wine bugs.
 
 ![](https://pbs.twimg.com/media/HMQT-ALWoAAABEe?format=png&name=orig)
 
 ![](https://pbs.twimg.com/media/HMQUVgpXYAA3h6r?format=png&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2072825642354123190
 
 Wine has a lot of problems with SetConsoleMode() I had to include an extra ENABLE_WRAP_AT_EOL_OUTPUT, and then force a newline right after ASCI ESC[H else it would screw up (and it still does at the end with the ??). But at least the debug is usable now.
 
 ![](https://pbs.twimg.com/media/HMQnWmJXcAAOiSS?format=png&name=orig)
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2072826861449629746
 
 But of course instant bad news, I cannot open the WinMM DRV_QUERYDEVICEINTERFACE, it returned ~0 (INVALID_HANDLE_VALUE). So I'm dead in the water in Wine again. Honestly getting sick of filing bugs in Wine, all the important stuff I do is broken. So what, no games use WDM/KS?
 
 ![](https://pbs.twimg.com/media/HMQoTiQWkAAbwj1?format=png&name=orig)
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2072829727639752830
 
 https://forum.winehq.org/viewtopic.php?t=10225 - Looks like I'm 16 years late to the answer, if they didn't get in WDM/KS in 16 years, certainly it won't happen. Still surprised that all PC games are using the higher level garbage-ware sound APIs on Windows.
diff --git a/archive/threads/NOTimothyLottes/2026-07-03-following-the-succession-thanks-of-re-trying/index.md b/archive/threads/NOTimothyLottes/2026-07-03-following-the-succession-thanks-of-re-trying/index.md
index 1259e0a..82d1417 100644
--- a/archive/threads/NOTimothyLottes/2026-07-03-following-the-succession-thanks-of-re-trying/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-03-following-the-succession-thanks-of-re-trying/index.md
@@ -25,32 +25,32 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2073096069529907441
 
 Following the succession (thanks) of re-trying WASAPI using this example which has been pre-minimized and de-C++'ed: https://gist.github.com/mmozeiko/5a5b168e61aff4c1eaec0381da62808f#file-win32_wasapi-h - But I'm missing something on how to get the C++ as C linking to function (cross compiling), doesn't easily work out of the box.
 
 ![](https://pbs.twimg.com/media/HMUdajFXEAAiaQE?format=png&name=orig)
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2073098899896598550
 
 Of course I'm missing the magic header that does the real work ... curious how messy this will get
 
 ![](https://pbs.twimg.com/media/HMUgZcyWQAA263a?format=jpg&name=orig)
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2073110092447203466
 
 So instead of the massive "mmdeviceapi.h" mess-ware, I defined a stupid CPP_(object,virtual_function_number) macro. This way I just have to write down the index in the VT table for the specific virtual function ...
 
 ![](https://pbs.twimg.com/media/HMUqNm_XIAA0JEP?format=png&name=orig)
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2073111326981783629
 
 Here is initial bring up, function call by function call. No headers, and no C++. The magic of typecasting at usage IC4_(CPP_(... is that I don't ever have to build the headers. That is at least working out well. I do line by line to test in Wine, defer fail handling until later
 
 ![](https://pbs.twimg.com/media/HMUrDz2XsAA9JLP?format=png&name=orig)
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2073113441959616958
 
 More on bring-up. I just run and check visually for output in the console (this time 'B055'). Since compile times are under a second, it is super fast to check as I go. Easy to see how much code bloat there is for C++ this way (doing it manually).
 
 ![](https://pbs.twimg.com/media/HMUs9oLWUAAaHx9?format=png&name=orig)
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2073114409270997497
 
 Example below of how much header bloat I'm factoring out using my simple macros
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-04-NOTimothyLottes-wines-iaudioclient-getdeviceperiod-returns-53333.md b/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-04-NOTimothyLottes-wines-iaudioclient-getdeviceperiod-returns-53333.md
index b2d4275..eb12d10 100644
--- a/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-04-NOTimothyLottes-wines-iaudioclient-getdeviceperiod-returns-53333.md
+++ b/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-04-NOTimothyLottes-wines-iaudioclient-getdeviceperiod-returns-53333.md
@@ -26,7 +26,7 @@ parent_post_id: "2073539101320417502"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2073543950497898839
 
 Wine's IAudioClient::GetDevicePeriod() returns 53333 for minimum (which is 256 samples at 48KHz - really crappy) and 100000 for default (which is 480 samples at 48Khz - even worse), neither which work with EXCLUSIVE mode. Man Wine sucks, nothing but constant show stopping bugs.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-05-mrsteyk1-once-upon-a-time-wine-didnt-implement-a.md b/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-05-mrsteyk1-once-upon-a-time-wine-didnt-implement-a.md
index 84e6aa7..c9e22b4 100644
--- a/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-05-mrsteyk1-once-upon-a-time-wine-didnt-implement-a.md
+++ b/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-05-mrsteyk1-once-upon-a-time-wine-didnt-implement-a.md
@@ -26,9 +26,9 @@ parent_post_id: "2073539101320417502"
 
 ## Branch
 
-**1/** @mrsteyk1
+**1/** **@mrsteyk1** ^2073646660291580102
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Once upon a time Wine didn’t implement a particular cryptography path and game broke when trying to verify file integrity, had to patch it out. It was so bad that Valve made a Proton Hotfix version (I think it ignored integrity check and returned success regardless).
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/index.md b/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/index.md
index 4b6ef35..8e2880b 100644
--- a/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/index.md
@@ -25,17 +25,17 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2073531564655260153
 
 Oh no, maybe another Wine bug (error photo)? I'm also getting an "AUDCLNT_E_DEVICE_IN_USE" (0x8889000A) when http://x.com is open (which would imply pipewire owning the audio device). So still holding out hope that Wine actually tried to emulate exclusive mode ...
 
 ![](https://pbs.twimg.com/media/HMapMOaXIAEqXQe?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2073532910720741875
 
 ... haha what a joke. Nope, actually at another Wine bug, when my other Linux digital twin can open the audio device with exclusive access, the wine'd version cannot. So I'm back to another actual WINE bug where they return AUDCLNT_E_DEVICE_IN_USE to avoid needing to implement
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2073539101320417502
 
 Nothing smells more like the 4th of july, than rain and grepping wine source to track down wine bugs. Does look like they just didn't implement EXCLUSIVE mode. Because I'm passing "*duration == *period" ...
 
@@ -43,6 +43,6 @@ Nothing smells more like the 4th of july, than rain and grepping wine source to
 
 Branches: [[archive/threads/NOTimothyLottes/2026-07-04-oh-no-maybe-another-wine-bug-error-photo-im-also/2026-07-05-mrsteyk1-once-upon-a-time-wine-didnt-implement-a]]
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2073543950497898839
 
 Wine's IAudioClient::GetDevicePeriod() returns 53333 for minimum (which is 256 samples at 48KHz - really crappy) and 100000 for default (which is 480 samples at 48Khz - even worse), neither which work with EXCLUSIVE mode. Man Wine sucks, nothing but constant show stopping bugs.
diff --git a/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/2026-07-08-nullspector-thats-very-neat-but-is-it-really-true-in-practice.md b/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/2026-07-08-nullspector-thats-very-neat-but-is-it-really-true-in-practice.md
index 22702ef..645ee62 100644
--- a/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/2026-07-08-nullspector-thats-very-neat-but-is-it-really-true-in-practice.md
+++ b/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/2026-07-08-nullspector-thats-very-neat-but-is-it-really-true-in-practice.md
@@ -26,15 +26,15 @@ parent_post_id: "2074108624553554387"
 
 ## Branch
 
-**1/** @nullspector
+**1/** **@nullspector** ^2074888721959149995
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 That's very neat, but is it really true in practice that the max distance between symbols can't exceed 4GB? I think it would be a sane guarantee that it can't, but I assumed the worst and got scared off from the idea...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2074892435038077125
 
-@nullspector
+**@nullspector**
 
 It’s working thus far, if I find a case it doesn’t work I’ll change it. I keep a different base per library, so likely safe enough.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/index.md b/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/index.md
index ea5b55d..f1e6dfa 100644
--- a/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-06-vulkan-starts-with-the-ping-pong-between-getting/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2074108624553554387
 
 Vulkan starts with the ping pong between getting an instance proc addr so one can get vkCreateInstance, then using that to create an instance so one can get the remaining functions. I reuse my Lib() code modified for VK, that keeps a 64-bit base and 32-bit offsets for symbols.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-08-oh-my-radv-driver-says-vkgetshaderinfoamd-is/index.md b/archive/threads/NOTimothyLottes/2026-07-08-oh-my-radv-driver-says-vkgetshaderinfoamd-is/index.md
index 34ebbbe..c5ce0ab 100644
--- a/archive/threads/NOTimothyLottes/2026-07-08-oh-my-radv-driver-says-vkgetshaderinfoamd-is/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-08-oh-my-radv-driver-says-vkgetshaderinfoamd-is/index.md
@@ -25,26 +25,26 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2074720328161411450
 
 Oh, my RADV driver says vkGetShaderInfoAMD is available [GPU disassembly dumps]. Going to be exciting to see how RADV compiler does. Will definitely be filing optimization bugs, would like to help the RADV team make this the best AMD Vulkan driver that can exist.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2074721638378086822
 
 One other concern was if RADV would support DEVICE_UNCACHED_BIT_AMD - and looks like RADV already has that, which means low-latency CPU/GPU communication should just work out of the box
 
 ![](https://pbs.twimg.com/media/HMrkGrMXwAA9Cr0?format=jpg&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2074723430734111222
 
 One of the pain points of doing header-free Vulkan is the VkPhysicalDeviceLimits structure. I avoid it completely and replace the structure with an equal size array of 63 64-bit values (504 bytes total). Then use direct byte offset for timestampPeriod (only thing useful in there)
 
 ![](https://pbs.twimg.com/media/HMrlR1cWQAAsqXD?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2074724166956118253
 
 The other component of vkGetPhysicalDeviceProperties that is useful is the vendorID, which is important for vendor specific engine permutations -> I use to enable vkGetShaderInfoAMD disassembly dumps automatically on all shaders
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2074725506050642021
 
 Next pre-device opening activity is choosing queue(s). Going to make another effort at beam racing, this time on Linux, so probably want a separate queue for presentation only. To fully decouple {dispatch, and swap}. Will see why later ...
diff --git a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-BigP4P4Smurf-and-preempt-rt.md b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-BigP4P4Smurf-and-preempt-rt.md
index 02fb334..f8320a8 100644
--- a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-BigP4P4Smurf-and-preempt-rt.md
+++ b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-BigP4P4Smurf-and-preempt-rt.md
@@ -26,9 +26,9 @@ parent_post_id: "2075107966018105449"
 
 ## Branch
 
-**1/** @BigP4P4Smurf
+**1/** **@BigP4P4Smurf** ^2075119067497640350
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 And PREEMPT_RT
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-idoccor-you-can-also-set-nohz-so-theres-no-timer.md b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-idoccor-you-can-also-set-nohz-so-theres-no-timer.md
index 189777a..d0c48b0 100644
--- a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-idoccor-you-can-also-set-nohz-so-theres-no-timer.md
+++ b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-09-idoccor-you-can-also-set-nohz-so-theres-no-timer.md
@@ -26,9 +26,9 @@ parent_post_id: "2075107966018105449"
 
 ## Branch
 
-**1/** @idoccor
+**1/** **@idoccor** ^2075201490549920023
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 You can also set nohz so there's no timer interrupts on the isolated cores + set up transparent huge pages (or manually use them)
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-10-darrellprograms-i-think-this-is-simply-available-as-a-kmsdrm.md b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-10-darrellprograms-i-think-this-is-simply-available-as-a-kmsdrm.md
index f1e1f66..69b17f7 100644
--- a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-10-darrellprograms-i-think-this-is-simply-available-as-a-kmsdrm.md
+++ b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-10-darrellprograms-i-think-this-is-simply-available-as-a-kmsdrm.md
@@ -26,27 +26,27 @@ parent_post_id: "2075107519588933655"
 
 ## Branch
 
-**1/** @darrellprograms
+**1/** **@darrellprograms** ^2075380301933736444
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I think this is simply available as a KMSDRM option in SDL for essentially zero development effort (if your game is built with SDL).
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2075388553446445179
 
-@darrellprograms
+**@darrellprograms**
 
 Never really understood the desire for zero development effort. As a developer I'm here to practice the art, ideally by pushing the state of the art. But will take looking at SDL source as a good reference if I get lost in the process.
 
-**3/** @darrellprograms
+**3/** **@darrellprograms** ^2075398576101093766
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I respect that, as long as you know what wheels you're reinventing. Note that you can keep Wayland or X11 running (or both, for that matter) for your dev environment, and just do control-alt-fN switching to test Wayland/X11-independent KMSDRM stuff.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2075403544111263795
 
-@darrellprograms
+**@darrellprograms**
 
 Oh I probably have a lot to learn here, building from scratch = understanding deeply. For example I wonder if VT switching fully pages out to clean VRAM, exclusive GPU ownership state.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/index.md b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/index.md
index 893d9f1..a4c3437 100644
--- a/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/index.md
@@ -25,17 +25,17 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2075106888950088099
 
 So most run Linux from a graphical login, I still prefer to boot into a framebuffer console. Next step for me is to get my LottesCode6x12 font into PSF2 so I can use it in a framebuffer terminal for editing source. So I can try for Vulkan swap bringup without X/Wayland.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2075107519588933655
 
 If we want a true console or arcade like experience on Linux, you'd want nothing else running on the machine, so running without X/Wayland is the way to do that.
 
 Branches: [[archive/threads/NOTimothyLottes/2026-07-09-so-most-run-linux-from-a-graphical-login-i-still/2026-07-10-darrellprograms-i-think-this-is-simply-available-as-a-kmsdrm]]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2075107966018105449
 
 One major option with Linux is the ability for the owner of the box to allow realtime priority scheduling, along with locking memory, and taking CPU cores out of general scheduling. Meaning transform Linux into something as close as possible to a realtime system.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/2026-07-11-konrad_kubacki_-am-i-having-a-stroke-what-is-this-font-it-feels.md b/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/2026-07-11-konrad_kubacki_-am-i-having-a-stroke-what-is-this-font-it-feels.md
index 30fdcd2..f96c202 100644
--- a/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/2026-07-11-konrad_kubacki_-am-i-having-a-stroke-what-is-this-font-it-feels.md
+++ b/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/2026-07-11-konrad_kubacki_-am-i-having-a-stroke-what-is-this-font-it-feels.md
@@ -26,9 +26,9 @@ parent_post_id: "2075769880092037309"
 
 ## Branch
 
-**1/** @konrad_kubacki_
+**1/** **@konrad_kubacki_** ^2075830291499737598
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Am I having a stroke? What is this font? It feels like reading a captcha. Is it only me?
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/index.md b/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/index.md
index e70d676..b017fbc 100644
--- a/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/index.md
@@ -25,21 +25,21 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2075769880092037309
 
 Rethinking Vulkan queue choice. Traditional double-buffered games might do something like the code below. Find the queue that does {presentation,graphics,compute}. First off this seems like a lot of unnecessary work when one could just choose queue 0 and be done with it ...
 
 ![](https://pbs.twimg.com/media/HM6desTW0AAHA_H?format=png&name=orig)
 Branches: [[archive/threads/NOTimothyLottes/2026-07-11-rethinking-vulkan-queue-choice/2026-07-11-konrad_kubacki_-am-i-having-a-stroke-what-is-this-font-it-feels]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2075770634349527454
 
 AMD on Linux (RADV) and Windows. Queue 0 just works. But note both platforms support doing present on queue 1. So on AMD I'm likely going to render via compute on queue 0 [to reduce chance of preemption] and present on queue 1. And have both decoupled (for front buffer rendering)
 
 ![](https://pbs.twimg.com/media/HM6d5GnWAAAGOmg?format=jpg&name=orig)
 
 ![](https://pbs.twimg.com/media/HM6d8lcXsAA-8LJ?format=jpg&name=orig)
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2075771407510773906
 
 NVIDIA is more complex. They put a DMA engine in queue 1 slot, and compute engine in queue 2 slot. Some sometimes queue 2 slot can or cannot do present (varies by driver). So maybe present on 0 (gfx queue), and dispatch on queue 2 by default for NV.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-bkaradzic-much-clearer.md b/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-bkaradzic-much-clearer.md
index adfb74f..eb046f5 100644
--- a/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-bkaradzic-much-clearer.md
+++ b/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-bkaradzic-much-clearer.md
@@ -26,9 +26,9 @@ parent_post_id: "2076833886827376782"
 
 ## Branch
 
-**1/** @bkaradzic
+**1/** **@bkaradzic** ^2076844424236265641
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Much clearer... 🤣
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-noop_dev-at-this-point-could-make-a-dsl-with-perl.md b/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-noop_dev-at-this-point-could-make-a-dsl-with-perl.md
index a3c7639..1c407f2 100644
--- a/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-noop_dev-at-this-point-could-make-a-dsl-with-perl.md
+++ b/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/2026-07-14-noop_dev-at-this-point-could-make-a-dsl-with-perl.md
@@ -26,9 +26,9 @@ parent_post_id: "2076833886827376782"
 
 ## Branch
 
-**1/** @noop_dev
+**1/** **@noop_dev** ^2077048344820551917
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 At this point could make a DSL with Perl..
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/index.md b/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/index.md
index 6f16110..ff9453c 100644
--- a/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-13-going-all-in-to-only-if-goto-but-through-better/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2076793671417040973
 
 Going all in to only {if,goto} but through better macros,
 label:
@@ -37,17 +37,17 @@ Can fix up nanorc syntax highlight by layering rules that override color, works
 ![](https://pbs.twimg.com/media/HNJAmyHXkAESBFF?format=png&name=orig)
 ![](https://pbs.twimg.com/media/HNJAuMwXQAABZQ1?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2076794091531100536
 
 Haha no surprise they didn't invite me to the "better software" conference!
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2076828893395218497
 
 Easy set of powerful macros. Brutal customization of C.
 
 ![](https://pbs.twimg.com/media/HNJguqvWMAAIZJN?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2076833886827376782
 
 Example usage after clean-up.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-13-ill-mark-this-down-a-more-code-obfustication-for/index.md b/archive/threads/NOTimothyLottes/2026-07-13-ill-mark-this-down-a-more-code-obfustication-for/index.md
index f3c9195..287be55 100644
--- a/archive/threads/NOTimothyLottes/2026-07-13-ill-mark-this-down-a-more-code-obfustication-for/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-13-ill-mark-this-down-a-more-code-obfustication-for/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2076492543622107480
 
 I'll mark this down a more code obfustication for most humans, but for me it's another useful shorthand.
 define X_ return
@@ -33,12 +33,12 @@ define G_(x) goto x
 
 ![](https://pbs.twimg.com/media/HNEuyadXoAAVxgG?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2076495156316864720
 
 Not been happy with traditional C style {if,while,do,switch,for} so moving to more assembly style {if,goto} instead. This way static branch prediction {backward=taken,forward=not_taken} is more explicit in the code. Prototyping it in the Library loader below
 
 ![](https://pbs.twimg.com/media/HNExHNRWIAAimHM?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2076534605193036043
 
 Another quality of life change, exit with error now triggers the background console render thread to actually quit, so it always draws the console, then draws the error code, then exits.
diff --git a/archive/threads/NOTimothyLottes/2026-07-14-another-round-of-getting-optimized-error-checking/index.md b/archive/threads/NOTimothyLottes/2026-07-14-another-round-of-getting-optimized-error-checking/index.md
index f641e28..57a3ae4 100644
--- a/archive/threads/NOTimothyLottes/2026-07-14-another-round-of-getting-optimized-error-checking/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-14-another-round-of-getting-optimized-error-checking/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2076888631508107561
 
 Another round of getting optimized error checking. Disassembly [after syscall] shows that it works. 
 (1.) Volatile store __LINE__
@@ -36,29 +36,29 @@ AS_MINIMAL_AS_ONE_CAN_GET
 
 ![](https://pbs.twimg.com/media/HNKWJZqXwAADMnN?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2076890340057878586
 
 A macro cheat sheet to try to explain how it works ...
 
 ![](https://pbs.twimg.com/media/HNKX5DhXIAE1BG6?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2076891161898143906
 
 I have a collection of force inline wrappers that test returns from syscalls/functions for error and return the return. These all leverage builtin_expect so the compiler knows to make them fall through in the common case.
 
 ![](https://pbs.twimg.com/media/HNKY8qFXQAAF9Db?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2076892038314741815
 
 Those force inlines call Err() on terminal error. The Err() function ensures the {__LINE__, error} stores are visible, then triggers the console drawing code to kill the app with printed error. Then it sleeps until the termination.
 
 ![](https://pbs.twimg.com/media/HNKZyFTXYAAETnU?format=png&name=orig)
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2076892591216341089
 
 Compiler eventually screws up, but at least it gets the fast path correct, and the slow error path gets an extra call. Effectively it conditionally forward branches to a distant call to Err() instead of just branching to the Err().
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2076893128515112995
 
 So I can liter error checks around stuff with little actual cost,
 (1.) Two stores
diff --git a/archive/threads/NOTimothyLottes/2026-07-15-one-advantage-of-sar-aka-signed-is-that-the-shift/index.md b/archive/threads/NOTimothyLottes/2026-07-15-one-advantage-of-sar-aka-signed-is-that-the-shift/index.md
index 6f61c31..4dab905 100644
--- a/archive/threads/NOTimothyLottes/2026-07-15-one-advantage-of-sar-aka-signed-is-that-the-shift/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-15-one-advantage-of-sar-aka-signed-is-that-the-shift/index.md
@@ -25,23 +25,23 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2077224595858280506
 
 One advantage of SAR (aka signed '>>') is that the shift-by operand HW uses only the 5|6 LSBs automatically. So if you have a mixed used control word, you don't have to mask out the MSBs. Can save an instruction.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2077225347049767246
 
 Working through an idea of a single uber-instruction interpreted language for code generation. Meaning something that never misses the instruction cache and executes fully out of the micro-op cache. Fully data driven with a direct map 64k entry symbol table.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2077227411112870280
 
 Borrows some ideas from SIMD GPU programming. Like instead of branching/predicating to avoid stores, just store to a discarded area (like a negative offset on the GPU, or a designated trash address on the CPU).
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2077234537302556898
 
 Don't want exit condition logic in the infinite loop, so exit will have to be having the program store an exit value into a set address, and an external watchdog polling for exit at some sleep frequency.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2077241596869751029
 
 SAR on a control word can in theory grab 3 values.
 SF (sign flag) is set to MSB bit
diff --git a/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/2026-07-18-furan-sorry-for-the-tangent-what-is-this-font-and-where.md b/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/2026-07-18-furan-sorry-for-the-tangent-what-is-this-font-and-where.md
index f6d1a55..f367cc7 100644
--- a/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/2026-07-18-furan-sorry-for-the-tangent-what-is-this-font-and-where.md
+++ b/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/2026-07-18-furan-sorry-for-the-tangent-what-is-this-font-and-where.md
@@ -26,21 +26,21 @@ parent_post_id: "2078257788732461389"
 
 ## Branch
 
-**1/** @furan
+**1/** **@furan** ^2078295812476404143
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 sorry for the tangent - what is this font and where can I get it?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2078305520314671244
 
-@furan
+**@furan**
 
 It’s one of mine (bitmap front for 640x480 resolution CRT) if I ever figure out some good web hosting again I could put up
 
-**3/** @furan
+**3/** **@furan** ^2078307280257519776
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 or github, I host a bunch of bitmap fonts here: https://github.com/ianhan/bitmapfonts
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/index.md b/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/index.md
index 000741e..768cb87 100644
--- a/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-17-oh-f-it-the-urge-to-drop-the-c-baggage-was-too/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2078257788732461389
 
 Oh, F-it! The urge to drop the C baggage was too strong, using nasm to bootstrap another radical Forth for Linux. Will see how far I can get in a 4 KiB binary to start. Apparently this wants to exist, and I have no choice but to lend some fingers. ELF64 out of the way.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/2026-07-18-noop_dev-even-smaller-code-size-possible-with-custom.md b/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/2026-07-18-noop_dev-even-smaller-code-size-possible-with-custom.md
index 64dfa3b..f56e359 100644
--- a/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/2026-07-18-noop_dev-even-smaller-code-size-possible-with-custom.md
+++ b/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/2026-07-18-noop_dev-even-smaller-code-size-possible-with-custom.md
@@ -26,9 +26,9 @@ parent_post_id: "2078349730204078527"
 
 ## Branch
 
-**1/** @noop_dev
+**1/** **@noop_dev** ^2078359568636080568
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Even smaller code size possible with custom compression scheme, where you design bytecode not for immediate execution but to be decompressed on load.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/index.md b/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/index.md
index cf6b1cf..82f95b7 100644
--- a/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-18-all-0-6-argument-syscall-options-in-32-bytes/index.md
@@ -25,19 +25,19 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2078347557474849137
 
 All {0-6} argument syscall options in 32-bytes. The plan is to embed the interpreter inside the words with a 3-byte overhead {AD (lodsd), FF E0 (jmp rax)} so levering lots of x86-64 stuff for minimal size
 
 ![](https://pbs.twimg.com/media/HNfFmXoXkAAMHM9?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2078348323287716101
 
 Everything forced in lower 32-bit, but still building around 64-bit support. Since I'm not using x86-64 CALL/RET I can free up the stack ops strictly for the data stack.
 
 ![](https://pbs.twimg.com/media/HNfGRZvXEAEtaKH?format=png&name=orig)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2078349730204078527
 
 I realized at some point I can have most interpreted forth-style words in an aligned 8-bytes. So can make a very small interpreter.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/2026-07-19-noop_dev-these-instrs-are-anything-but-fast-and-if-you.md b/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/2026-07-19-noop_dev-these-instrs-are-anything-but-fast-and-if-you.md
index afebb0f..44e39a8 100644
--- a/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/2026-07-19-noop_dev-these-instrs-are-anything-but-fast-and-if-you.md
+++ b/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/2026-07-19-noop_dev-these-instrs-are-anything-but-fast-and-if-you.md
@@ -26,51 +26,51 @@ parent_post_id: "2078729662021111958"
 
 ## Branch
 
-**1/** @noop_dev
+**1/** **@noop_dev** ^2078763409403683061
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 These instrs are anything but fast and if you want both "fast" and compact you run a separate decoding pass where you expand custom bytecode into target instructions that suck less.
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2078851948543910353
 
-@noop_dev
+**@noop_dev**
 
 Basic truth: if the program is tiny and dependency free (ie intrinsically not just glue for libraries) it’s probably already fast even if the machine isn’t. And for the things that need perf there is always assembly
 
-**3/** @noop_dev
+**3/** **@noop_dev** ^2078853226967781591
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Anyway, I am trying you to sell the idea of bytecode-driven macroassembler that expands "macros" on load. Like I did with 4K atari 2600 emu ~20 years ago.. some demosceners I knew also adopted the idea..
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2078856306811691388
 
-@noop_dev
+**@noop_dev**
 
 Many of my other systems had been such that interpreted source generates raw code then executes the code (all at once after code is fully processed). Effectively forth as a macro language and instruction generator, runtime assembler.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2078858446409978111
 
-@noop_dev
+**@noop_dev**
 
 But for cold cache stuff it’s easy to burn more time in binary generation than it would cost to do simple interpreter.
 
-**6/** @noop_dev
+**6/** **@noop_dev** ^2078860015323038149
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Not sure I can understand how cold cache matters for a linear transformation of a relatively small # of bytes.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2078861504284074431
 
-@noop_dev
+**@noop_dev**
 
 If it’s a byte that indexes into say a fixed size physical instruction, yeah it’s just a decompression of source code, sure easy to do fast. Im talking more the multi-branch miss per instruction stuff.
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^2078862606517895324
 
-@noop_dev
+**@noop_dev**
 
 Meaning “mov edi,[rax-0x32]” could be generated from 4 symbol lookups (2 for regs, one for offset, one for instruction). Also my intent here is for GPU code generation for AMD GPUs where youd have sometimes 8+ bitfields in an opcode. So the simple stuff won’t work there …
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/index.md b/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/index.md
index 1feafe8..43ce530 100644
--- a/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-19-probably-shouldnt-consider-this-but-apparently/index.md
@@ -25,17 +25,17 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2078728600912630031
 
 Probably shouldn't consider this -BUT- apparently writing to ax doesn't change the other 48-bits. So one could do a 4-byte overhead interpreter with a 64KiB aligned window of directly jumpable words like this below. [rsi]=addresses to jump to. You'd pay the false dependency stall
 
 ![](https://pbs.twimg.com/media/HNkf6ntX0AA8d1M?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2078729020900823089
 
 It's interesting because it cuts interpreted source size in half. Ie a stream of 16-bit offsets instead of 32-bit addresses.
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2078729662021111958
 
 The aim of course, keep the stuff that doesn't need to go fast optimized instead for low complexity and low size (aka interpreted forth), and keep the stuff that needs to go fast, at peak, assembly. Hits 2 extremes well.
 
diff --git a/archive/threads/NOTimothyLottes/2026-07-22-working-through-rough-draft-of-assembly-for-a/index.md b/archive/threads/NOTimothyLottes/2026-07-22-working-through-rough-draft-of-assembly-for-a/index.md
index af53505..e43232e 100644
--- a/archive/threads/NOTimothyLottes/2026-07-22-working-through-rough-draft-of-assembly-for-a/index.md
+++ b/archive/threads/NOTimothyLottes/2026-07-22-working-through-rough-draft-of-assembly-for-a/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2079742177370841105
 
 Working through rough draft of assembly for a different idea for a micro macro-forth.
 1. 8-bit/word (color to relay meaning)
@@ -36,7 +36,7 @@ Working through rough draft of assembly for a different idea for a micro macro-f
 
 ![](https://pbs.twimg.com/media/HNy5A_uW0AAj1cU?format=png&name=orig)
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2079743328585658532
 
 5. Compile step is branch-free
 6. Compiles to branch-free x86-64 source
@@ -44,14 +44,14 @@ Working through rough draft of assembly for a different idea for a micro macro-f
 
 Noticed that I can pre-compile all the dictionary words into a lookup table. So actual compile just writes unaligned 8-bytes but only advances the write pointer by the actual size
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2079744218122096681
 
 The interesting bits about this micro project was factoring out all branches, using branch-free interpreter loop to inline all calls so later execution is linear. Got messy doing a branch free software return stack. But costs are relatively low (40 ops/character)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2079744804078977381
 
 Intended usage would be for tiny-gramming programs in self contained chunks that include their own code generation (effectively a macro-forth used to generate machine code).
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2079746130309415185
 
 A language that you author in a compressed space directly. So Whitney-esk in using lots of single character variables (or double character with page characters) -BUT- very non-Whitney in that it has no higher order array constructs
diff --git a/archive/threads/NOTimothyLottes/2026-08-02-m64-the-physical-fpga-psram-hardware-offers-such/index.md b/archive/threads/NOTimothyLottes/2026-08-02-m64-the-physical-fpga-psram-hardware-offers-such/index.md
index 751fd20..d11274d 100644
--- a/archive/threads/NOTimothyLottes/2026-08-02-m64-the-physical-fpga-psram-hardware-offers-such/index.md
+++ b/archive/threads/NOTimothyLottes/2026-08-02-m64-the-physical-fpga-psram-hardware-offers-such/index.md
@@ -25,22 +25,22 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2083774527255740917
 
 M64, the physical FPGA+PSRAM hardware offers such an extremely challenging problem to solve for a neo-vintage retro machine design. One has the capacity for an extreme amount of DSPs paired with relatively low on-chip memory and still limited off-chip bandwidth ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2083774870630928444
 
 M64/MiSTer and others burn up nearly everything on emulation, but we have yet to see what a bespoke engineering effort would look like if it was unleashed on those FGPAs
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2083775826303021409
 
 The obvious stuff, like on M64, you have >200x {36-bit x 512 entry} memories, and double that number in IMAD units (DSPs), doesn't really map well to vintage single CPU or even old simple multi-chip designs. Meaning a bespoke parallel machine could likely knock some socks off ...
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2083777028449263884
 
 Most of the 3D HW that sits firmly in the post 2D to 3D transition region that has low enough clocks to FPGA emulate, seems quite strangled. Meaning an evolved sprite super-scalar (perhaps depth sprites) might actually have been a better alternative timeline to go after ...
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2083778960945562067
 
 Most of the puzzle of targeting a machine with massive ALU capacity is a compression problem, how to have a small number of 'things' transform into a lot of 'stuff' without round-tripping through memory
diff --git a/archive/threads/NOTimothyLottes/2026-08-02-re-fpga-land-alus-im-firmly-distracted-by-an/index.md b/archive/threads/NOTimothyLottes/2026-08-02-re-fpga-land-alus-im-firmly-distracted-by-an/index.md
index 5835495..dc8c6fe 100644
--- a/archive/threads/NOTimothyLottes/2026-08-02-re-fpga-land-alus-im-firmly-distracted-by-an/index.md
+++ b/archive/threads/NOTimothyLottes/2026-08-02-re-fpga-land-alus-im-firmly-distracted-by-an/index.md
@@ -25,58 +25,58 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2083757874686161259
 
 Re-FPGA-land ALUs - I'm firmly distracted by an alternative history of the unexplored left justified extreme fixed point. Where signed integer numbers represent {-1.0 to <1.0}. Where the primary IMAD op includes a huge fixed signed right shift ...
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2083758603945513244
 
 For those planted in the right-justified current fixed point timeline, your bytes get loaded into the LSBs, and your addressing uses the LSBs. The idea of doing the reverse of this is probably completely alien -> loading smaller bit types into the MSBs first ...
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2083759192721043871
 
 Meaning standard integer thinking is to start with small things like an index and scale that by the stride into a larger number. But with what I'm suggesting you start with something large and instead make it smaller.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2083761583776301374
 
 In a traditional right-justified CPU, you'd have three ops {MUL, ADD, SHR} which could be reduced to {IMAD, SHR}, but would be just one op on a left justified machine. Meaning doing 'fixed point' stuff is a bit faster.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2083762609094889861
 
 32-bit left justified machine, can easily leverage say a 18-bit * 25-bit multiplier (Xlinix DSP) because the MSBs are always fed in, and the useful MSBs are always pulled out of the accumulator (P). Right justified machines really need that full 32-bit x 32-bit MUL
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2083764013570093330
 
 Left justified variable bit-width loads make a lot more sense, partly because the LSBs index into bits (or sub-bits depending on mapping) effectively (instead of bytes), and one can do {4/8/16/32-bit} extraction with 8 SLICES and one CLB deep [a lot easier than right-justified]
 
 ![](https://pbs.twimg.com/media/HOsENEBXEAAoWlx?format=png&name=orig)
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2083765900436492692
 
 The core normalized IMAD can easily be made -/+ symmetrical simply by feeding in truncated LSBs of the add operand with simple logic based on MSBs of mul operands. In the example below the {-4} represents {-1.0}. Of course -4*-4 overflows to -4 [2's comp]
 
 ![](https://pbs.twimg.com/media/HOsFs-nWAAAUlTy?format=png&name=orig)
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^2083766854980383071
 
 Predicate/bool logic becomes {0.0, -1.0} based, can leverage {a+b} wrap around to implement XOR, and -(a*b) to implement AND.
 
 ![](https://pbs.twimg.com/media/HOsG3VBXAAA92kz?format=png&name=orig)
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^2083768129658765655
 
 Doing a "perspective divide" {s=x/z} can be transformed into a scaled perspective divide {s=x*(a/z)} to work around the {-1.0 to <1.0} range limitation. And one can transform the divide into a binary search for 's' - specifically largest 's' where {s*z<=x*a}
 
 ![](https://pbs.twimg.com/media/HOsIBCBWcAA79PL?format=png&name=orig)
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^2083768853499203838
 
 Notice this binary search test takes just one IMAD {s*z+t} where t=-x*a. Meaning a smart machine can do a test step in 2 ops on a DSP (one IMAD for the test, the next to ADD to 's' for the next search step) ...
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^2083769357906133502
 
 Which requires the opcode ISA to have a latched delayed write to the register file that is conditional on the sign bit of a later IMAD op. This can make binary search for things like sqrt(x) also just as fast.
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^2083771965278388689
 
 I think there are ways to transcend typical integer machine IPCs by having uber ops in the ISA (this left-justified machine has a 1-clock {MUL,ADD,SHIFT,+ signed conditional register STORE,+ extra modifiers (like NOT)}. But still have extremely simple implementations.
diff --git a/archive/threads/NOTimothyLottes/2026-08-23-operands-time-perf/index.md b/archive/threads/NOTimothyLottes/2026-08-23-operands-time-perf/index.md
index 03fa039..a8b114e 100644
--- a/archive/threads/NOTimothyLottes/2026-08-23-operands-time-perf/index.md
+++ b/archive/threads/NOTimothyLottes/2026-08-23-operands-time-perf/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2091652388184572155
 
 Operands/time = Perf
 Mitigating amplifiers
@@ -35,38 +35,38 @@ c. Destination reuse [forwarding]
 d. Scalar constants + SIMD [broadcast]
 e. Parallel subword extraction [inline decompression]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2091655502786699296
 
 f. Banking [for multi-port]
 
 If reg file supports only 1 store source/port/clk then you'd need forwarding to open a clock to do a parallel load (with alu) for the given port. Likewise you'd need an isa "last use" (avoid reg write) to get parallel store [into reg file] (with alu).
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2091657447425380701
 
 Seems like the best one can do on a xilinx fpga is 6 clock pipeline
 [lutRAM]->[CLB1]->[DSP.ab]->[DSP.m]->[DSP.p]->[CLB2]->[lutRAM]
 Where CLB1 does {DSP.p to multiplier operand forwarding to get 4 clock IMAD latency}. And accumulation uses internal c=p routing for "no" latency.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2091659049242599769
 
 CLB2 is injection for loads from BRAM (when regfile port store isn't needed for DSP.p). If register file is 3 way banked, and direct mapped (bank 0 -> CLB -> DSP.A), then there are 3 reads/clk and 3 writes/clk ... given a value is not needed in all banks, lots of pipelinabiliy
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2091659554413064445
 
 But most FPGA SIMD soft processors stick to even longer pipelines, direct regfile in BRAM, and no usage of DSP P->C forwarding (accumulation). Which means they have heavy dilution of their memory/time (too many parallel tasks).
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2091660056156647719
 
 I think it's better to hand unroll parallel tasks into one assembled instruction stream, expose variable latency {forwarded vs round-trip through reg file} --vs-- the alternative of HW managed multi-threading.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2091660458864296247
 
 However, how many arch have actual instruction stream compression? None? (x86 doesn't really count). If you build around massive unrolling, you are doing the same stuff with offset'ed operands -> so obviously wants compression, else a tiny I$ won't survive
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^2091661084079878540
 
 Ok, I lied, there are some historic examples of multi-component + SIMD which leverage a {1,2,3,4} ISA bitfield to repeat the op/compent, or SIMD itself via looping instruction -- which technically is a great example of "compression"
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^2091661665175482794
 
 Getting the 3x local memory vs operand data rate amplifier, along with memory hierarchy pipelining, sorted is perhaps the most important thing for realized IPC, but there is still the 100x operand vs external bandwidth mitigation which defines the platform ...
diff --git a/archive/threads/NOTimothyLottes/2026-08-25-one-downsides-to-being-a-left-justified-machine/index.md b/archive/threads/NOTimothyLottes/2026-08-25-one-downsides-to-being-a-left-justified-machine/index.md
index 2c49f71..aeffa8e 100644
--- a/archive/threads/NOTimothyLottes/2026-08-25-one-downsides-to-being-a-left-justified-machine/index.md
+++ b/archive/threads/NOTimothyLottes/2026-08-25-one-downsides-to-being-a-left-justified-machine/index.md
@@ -25,28 +25,28 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2092088375205359693
 
 One downsides to being a left justified machine and emulated on a FPGA is that one cannot use the built-in DSP's rounding capability through CIN. So the end of accumulation requires a long latency feedback of the MSB of P to effect LSB bits of C for final add before right shift
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2092090397967179785
 
 Yields 2 options - that accumulation + expensive post accumulation rounding --OR-- round after each MUL by setting the shifted out LSBs of C based on XOR(A,B) MSBs and don't accumulate (no P) which means always a fixed 4 clk ALU latency [with forwarding]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2092091710100648026
 
 For reference - Left-justified signed IMAD: Reduced to a 3-bit machine with a 16-bit accumulator for testing [below], being used as a C model proxy for a 24-bit A expanded to 7 series 25-bits (the LSB 0), with a 18-bit B, and 24-bit C (and extracted 24-bit result in same slot).
 
 ![](https://pbs.twimg.com/media/HQiZnwQXIAAFcvO?format=png&name=orig)
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2092092992957915640
 
 This is for a vector SIMD (a soft GPU). Effectively a 32-bit memory driving a 24-bit ALU with variable sub-word size {24,16,8,4} as inline compression/decompression HW. Noticed sub-word extraction gets less expensive if one uses SR on the registering flip-flop for LSB zeros.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2092094320295694357
 
 Been working on my little FPGA GPU project for quite some time, mostly trying to engineer out enough of the pipeline as mapped to CLBs/DSPs/dRAMs/bRAMs with basic rules like one CLB deep per pipeline stage per registering and no cascading, etc, to target peak frequency ...
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2092095830916239796
 
 I'm engineering some horribly unconventional things, like a one instruction SIMD VLIW ALU (IMAD) with modifiers and surrounding support for binary searching "a*b/c" and "sqrt", etc, paired to a sub-word bit extraction/packing unit, sign conditional swap store to banked reg file
diff --git a/archive/threads/SebAaltonen/2024-04-04-this-is-how-slow-code-feels-like/index.md b/archive/threads/SebAaltonen/2024-04-04-this-is-how-slow-code-feels-like/index.md
index f31ad40..f9f3512 100644
--- a/archive/threads/SebAaltonen/2024-04-04-this-is-how-slow-code-feels-like/index.md
+++ b/archive/threads/SebAaltonen/2024-04-04-this-is-how-slow-code-feels-like/index.md
@@ -25,34 +25,34 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1775820153793515892
 
 This is how slow code feels like:
 
 ![](https://pbs.twimg.com/media/GKT6_a3WAAAdh4v?format=jpg&name=orig)
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1775820774848258212
 
 And this is how clever you feel after finding the optimization:
 
 ![](https://pbs.twimg.com/media/GKT7h0iXEAAxYAY?format=jpg&name=orig)
 
-**3/** @MartinJIFuller
+**3/** **@MartinJIFuller** ^1776518700230721688
 
-@SebAaltonen
+**@SebAaltonen**
 
 Sad that the compiler isn’t doing this for us in 2024
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1776597200073568623
 
-@MartinJIFuller @SebAaltonen
+**@MartinJIFuller** **@SebAaltonen**
 
 On https://mastodon.gamedev.place/@NOTimothyLottes I'm collecting posts with AMD GPU disassembly dumps for a book on everything the shader compiler 'isn't doing'. Constant AMD GPU compiler perf bug SPAM is a key part of my online strategy to keep a low follower count.
 
 ![](https://pbs.twimg.com/media/GKe8HDtXYAAOrfj?format=jpg&name=orig)
 
-**5/** @MartinJIFuller
+**5/** **@MartinJIFuller** ^1776703621435933035
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 A worthwhile project, knowledge well worth sharing, but is a book the right format? Perhaps yes, just thinking out loud.
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ASupersay-who-cares-do-what-makes-you-happiest-and.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ASupersay-who-cares-do-what-makes-you-happiest-and.md
index fed0d27..684e0af 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ASupersay-who-cares-do-what-makes-you-happiest-and.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ASupersay-who-cares-do-what-makes-you-happiest-and.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @ASupersay
+**1/** **@ASupersay** ^1786382315767115881
 
-@SebAaltonen
+**@SebAaltonen**
 
 Who cares? Do what makes you happiest and wealthiest.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-i-wish-visual-studio-had-better-code-context.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-i-wish-visual-studio-had-better-code-context.md
index eb5bfbc..69fd1c0 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-i-wish-visual-studio-had-better-code-context.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-i-wish-visual-studio-had-better-code-context.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @AronThoughts
+**1/** **@AronThoughts** ^1786371614994493715
 
-@SebAaltonen
+**@SebAaltonen**
 
 I wish visual studio had better code context colorization. At one point I was using a source editor called source insight. It had amazing code colorization and I had this theme where warm/cool colors meant certain things so I could instantly look at a variable know about it
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-static-globals-defines-were-warm-members-blue.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-static-globals-defines-were-warm-members-blue.md
index b177794..769cc92 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-static-globals-defines-were-warm-members-blue.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-static-globals-defines-were-warm-members-blue.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @AronThoughts
+**1/** **@AronThoughts** ^1786372350612578469
 
-@SebAaltonen
+**@SebAaltonen**
 
 Static/globals/#defines were warm
 Members blue hues
@@ -39,15 +39,15 @@ Namespaces dotted underlined
 Static methods purple/red 
 etc
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786372865098437032
 
-@AronThoughts
+**@AronThoughts**
 
 Indeed. Good color coding is important for readability too. IDEs do this very well.
 
-**3/** @AronThoughts
+**3/** **@AronThoughts** ^1786373910155386962
 
-@SebAaltonen
+**@SebAaltonen**
 
 Most IDEs I've used since dont have this level of specificity though but I've not used many different ones
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BenQett-the-only-good-faith-reply-is-if-youre-a-systems.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BenQett-the-only-good-faith-reply-is-if-youre-a-systems.md
index 42c5f78..69a6c39 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BenQett-the-only-good-faith-reply-is-if-youre-a-systems.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BenQett-the-only-good-faith-reply-is-if-youre-a-systems.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @BenQett
+**1/** **@BenQett** ^1786395978787946875
 
-@SebAaltonen
+**@SebAaltonen**
 
 The only good faith reply is if you’re a systems engineer and you have to work on remote servers with no ability to run an IDE/Desktop so you’re stuck with VIM (can’t reverse tunnel/mount)
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BugoTheCat-nothing-wrong-with-new-tools-its-just-that-most.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BugoTheCat-nothing-wrong-with-new-tools-its-just-that-most.md
index 291916a..c7b71c1 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BugoTheCat-nothing-wrong-with-new-tools-its-just-that-most.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BugoTheCat-nothing-wrong-with-new-tools-its-just-that-most.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @BugoTheCat
+**1/** **@BugoTheCat** ^1786354630043013130
 
-@SebAaltonen
+**@SebAaltonen**
 
 Nothing wrong with new tools, it's just that most people get used to them and can never go back. It then feels to them like the old ways were horrific or they have an exaggerated negative response about the past.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CobraSwims-same-reason-some-large-corps-demand-that-we-have.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CobraSwims-same-reason-some-large-corps-demand-that-we-have.md
index e918a7f..200bbf4 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CobraSwims-same-reason-some-large-corps-demand-that-we-have.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CobraSwims-same-reason-some-large-corps-demand-that-we-have.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @CobraSwims
+**1/** **@CobraSwims** ^1786507329988591871
 
-@SebAaltonen
+**@SebAaltonen**
 
 Same reason some large corps demand that we have specific paths for random shit we all use autocomplete for. 
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CptCrabhands-you-should-write-your-code-on-paper-by-hand.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CptCrabhands-you-should-write-your-code-on-paper-by-hand.md
index fa212c7..b32fbc6 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CptCrabhands-you-should-write-your-code-on-paper-by-hand.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CptCrabhands-you-should-write-your-code-on-paper-by-hand.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @CptCrabhands
+**1/** **@CptCrabhands** ^1786362572754575769
 
-@SebAaltonen
+**@SebAaltonen**
 
 You should write your code on paper by hand 😤 totally
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-DarthJahus-being-able-to-code-without-assistant-is-a-good.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-DarthJahus-being-able-to-code-without-assistant-is-a-good.md
index bea7063..78c2c47 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-DarthJahus-being-able-to-code-without-assistant-is-a-good.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-DarthJahus-being-able-to-code-without-assistant-is-a-good.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @DarthJahus
+**1/** **@DarthJahus** ^1786491957369352622
 
-@SebAaltonen
+**@SebAaltonen**
 
 Being able to code without assistant is a good thing, maybe?
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Desxon1-still-remember-how-my-technical-school-assigned-a.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Desxon1-still-remember-how-my-technical-school-assigned-a.md
index c7b6f9e..2dd3710 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Desxon1-still-remember-how-my-technical-school-assigned-a.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Desxon1-still-remember-how-my-technical-school-assigned-a.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Desxon1
+**1/** **@Desxon1** ^1786508657745592433
 
-@SebAaltonen
+**@SebAaltonen**
 
 Still remember how my technical school assigned a literal psychopath to teach us do databases. The SQL was done ON FUCKING PAPER and he graded each and every point of it. A lack of "," could cost ya points.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Enhex-because-high-arrogance-low-intelligence.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Enhex-because-high-arrogance-low-intelligence.md
index dd0c01b..46633c0 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Enhex-because-high-arrogance-low-intelligence.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Enhex-because-high-arrogance-low-intelligence.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Enhex
+**1/** **@Enhex** ^1786350991530450966
 
-@SebAaltonen
+**@SebAaltonen**
 
 because high arrogance + low intelligence
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Floppie7th-cant-stand-ides-honestly-i-wouldnt-use-notepad.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Floppie7th-cant-stand-ides-honestly-i-wouldnt-use-notepad.md
index 7c3e7c8..dcdea97 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Floppie7th-cant-stand-ides-honestly-i-wouldnt-use-notepad.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Floppie7th-cant-stand-ides-honestly-i-wouldnt-use-notepad.md
@@ -26,23 +26,23 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Floppie7th
+**1/** **@Floppie7th** ^1786434451657953480
 
-@SebAaltonen
+**@SebAaltonen**
 
 Can't stand IDEs, honestly.  I wouldn't use Notepad because its navigation is horrible, but autocomplete doesn't save any time (typing isn't really a bottleneck), gdb and debug prints are great for debugging, and finding a definition with CTRL+Z followed rg 'whatever' works great
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786435266565046772
 
-@Floppie7th
+**@Floppie7th**
 
 If your tool has code navigation (find symbols, find callers, etc) and color colorization then it is an IDE.
 
 Autocomplete is not a big deal. Code navigation tools and code colorization are the most important things. Writing code is not as important as reading & browsing code.
 
-**3/** @Floppie7th
+**3/** **@Floppie7th** ^1786436290671509715
 
-@SebAaltonen
+**@SebAaltonen**
 
 Starting by mentioning autocomplete and built-in debuggers, then defining IDE as "code colorization", seems like moving the goalposts pretty far.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-GumboatDiplomat-i-pretty-much-agree-with-you-but-i-started-using.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-GumboatDiplomat-i-pretty-much-agree-with-you-but-i-started-using.md
index d1445db..4f70632 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-GumboatDiplomat-i-pretty-much-agree-with-you-but-i-started-using.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-GumboatDiplomat-i-pretty-much-agree-with-you-but-i-started-using.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @GumboatDiplomat
+**1/** **@GumboatDiplomat** ^1786354483758330313
 
-@SebAaltonen
+**@SebAaltonen**
 
 I pretty much agree with you, but I started using nvim recently, and it doesn't have an LSP for the a language that I already know very well (gml)  And I did learn stuff forgoing the autocomplete, I feel like my knowledge deepened, if that makes sense.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-IlyasHairline-to-flex-on-others.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-IlyasHairline-to-flex-on-others.md
index 07c97c1..fb1a771 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-IlyasHairline-to-flex-on-others.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-IlyasHairline-to-flex-on-others.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @IlyasHairline
+**1/** **@IlyasHairline** ^1786458723541524506
 
-@SebAaltonen
+**@SebAaltonen**
 
 To flex on others
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Jerroudi_Yass-i-remember-having-an-argument-with-one-of-the.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Jerroudi_Yass-i-remember-having-an-argument-with-one-of-the.md
index 153841d..c608678 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Jerroudi_Yass-i-remember-having-an-argument-with-one-of-the.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Jerroudi_Yass-i-remember-having-an-argument-with-one-of-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1786349827669790823"
 
 ## Branch
 
-**1/** @Jerroudi_Yass
+**1/** **@Jerroudi_Yass** ^1786365002519089480
 
-@SebAaltonen
+**@SebAaltonen**
 
 I remember having an argument with one of the staffs of 42 about allowing the usage of debuggers in exams as he was totally against the idea leaving us with printf debugging in a 2h exam session. I never understood why there is so much hate/reluctance about the usage of debuggers
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Junts-as-a-kid-i-thought-coding-seemed-cool-and-wrote-a.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Junts-as-a-kid-i-thought-coding-seemed-cool-and-wrote-a.md
index 6c5d710..af05794 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Junts-as-a-kid-i-thought-coding-seemed-cool-and-wrote-a.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Junts-as-a-kid-i-thought-coding-seemed-cool-and-wrote-a.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Junts
+**1/** **@Junts** ^1786445991211684144
 
-@SebAaltonen
+**@SebAaltonen**
 
 As a kid I thought coding seemed cool and wrote a 30 second program in basic in a text file I renamed to an .exe.  it was so aggravating that I decided programming was a pain
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-KasperArnklit-gate-keeping-programming-and-thinking-it-makes.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-KasperArnklit-gate-keeping-programming-and-thinking-it-makes.md
index 5f93ce2..b925bcb 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-KasperArnklit-gate-keeping-programming-and-thinking-it-makes.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-KasperArnklit-gate-keeping-programming-and-thinking-it-makes.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @KasperArnklit
+**1/** **@KasperArnklit** ^1786393718829768718
 
-@SebAaltonen
+**@SebAaltonen**
 
 Gate keeping programming and thinking it makes you special is incredibly sad.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Kinker_0-theres-a-big-difference-between-being-able-to-and.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Kinker_0-theres-a-big-difference-between-being-able-to-and.md
index 3c4e6e3..1424a3c 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Kinker_0-theres-a-big-difference-between-being-able-to-and.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Kinker_0-theres-a-big-difference-between-being-able-to-and.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Kinker_0
+**1/** **@Kinker_0** ^1786367923868639701
 
-@SebAaltonen
+**@SebAaltonen**
 
 There's a big difference between "being able to" and actually doing it.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Lascif-people-have-a-superiority-complex-for-working-in.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Lascif-people-have-a-superiority-complex-for-working-in.md
index 4b6bef7..90a5adb 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Lascif-people-have-a-superiority-complex-for-working-in.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Lascif-people-have-a-superiority-complex-for-working-in.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Lascif
+**1/** **@Lascif** ^1786353508901384368
 
-@SebAaltonen
+**@SebAaltonen**
 
 People have a superiority complex for working in the hardest way possible because “that’s how I had to do it”.
 They forget that they should work smarter not harder.
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-MacGyver1618-you-should-be-able-to-code-in-notepad-just-so-you.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-MacGyver1618-you-should-be-able-to-code-in-notepad-just-so-you.md
index fab5dd1..622dcc7 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-MacGyver1618-you-should-be-able-to-code-in-notepad-just-so-you.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-MacGyver1618-you-should-be-able-to-code-in-notepad-just-so-you.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @MacGyver1618
+**1/** **@MacGyver1618** ^1786373263947432188
 
-@SebAaltonen
+**@SebAaltonen**
 
 You should be able to code in Notepad just so you can truly relish the joy of not having to.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Naam_Hai_Bulla-major-disagree-especially-if-youre-learning-a-new.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Naam_Hai_Bulla-major-disagree-especially-if-youre-learning-a-new.md
index 5da6cc4..4ec5d01 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Naam_Hai_Bulla-major-disagree-especially-if-youre-learning-a-new.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Naam_Hai_Bulla-major-disagree-especially-if-youre-learning-a-new.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Naam_Hai_Bulla
+**1/** **@Naam_Hai_Bulla** ^1786462326905848066
 
-@SebAaltonen
+**@SebAaltonen**
 
 MAJOR DISAGREE
 Especially if you're learning a new tech stack modern IDEs are too user friendly
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Natnew7-you-shouldnt-have-to-code-this-way-for-serious.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Natnew7-you-shouldnt-have-to-code-this-way-for-serious.md
index 108f3f0..b63e94d 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Natnew7-you-shouldnt-have-to-code-this-way-for-serious.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Natnew7-you-shouldnt-have-to-code-this-way-for-serious.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Natnew7
+**1/** **@Natnew7** ^1786410474407436585
 
-@SebAaltonen
+**@SebAaltonen**
 
 You shouldn’t have to code this way for serious projects. But you should be capable of it.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-NeutralRational-hes-a-boomer.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-NeutralRational-hes-a-boomer.md
index 506ca96..da2a39d 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-NeutralRational-hes-a-boomer.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-NeutralRational-hes-a-boomer.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @NeutralRational
+**1/** **@NeutralRational** ^1786498531068428288
 
-@SebAaltonen
+**@SebAaltonen**
 
 He's a boomer.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Niko_sk2x-i-think-the-point-is-that-you-should-be-able-to.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Niko_sk2x-i-think-the-point-is-that-you-should-be-able-to.md
index db9e9bc..89c423a 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Niko_sk2x-i-think-the-point-is-that-you-should-be-able-to.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Niko_sk2x-i-think-the-point-is-that-you-should-be-able-to.md
@@ -26,51 +26,51 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Niko_sk2x
+**1/** **@Niko_sk2x** ^1786374000802746449
 
-@SebAaltonen
+**@SebAaltonen**
 
 I think the point is that you should be able to code well enough that IDE is a tool to help you and make you more efficient, not a tool that allows you to do it at all - you can still do it without an IDE, it's just slow and annoying. If you can't at all, that's not a good sign
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786374953358487940
 
-@Barteks2x
+**@Barteks2x**
 
 There's no real difference in practice. Of course I could write code on notepad and press space 4 times manually. The main problem with notepad is not writing code. It's reading code. And coding is 90% reading, 10% writing. Color coding, jumping to symbols, etc.
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1786375194686210338
 
-@Barteks2x
+**@Barteks2x**
 
 Reading a big code base with notepad is super painful, as you have to open the cmake file to see where the includes actually are and then find the .cpp files if you need to investigate further. That's over 10x slower reading experience in big code base.
 
-**4/** @SebAaltonen
+**4/** **@SebAaltonen** ^1786375792085106853
 
-@Barteks2x
+**@Barteks2x**
 
 For a new junior programmer it is super important that their code reading experience is as good as possible so that they learn the big code base as quickly as possible. Thus they should use an IDE. Seniors should not ask them to use notepad instead to learn it. That's just stupid
 
-**5/** @SebAaltonen
+**5/** **@SebAaltonen** ^1786376107018567696
 
-@Barteks2x
+**@Barteks2x**
 
 It doesn't really matter if a programmer can't write code on notepad, as they should never be doing that in any reasonably sized project. Their productivity when reading code is so much worse, and reading is 90% of the job.
 
-**6/** @Niko_sk2x
+**6/** **@Niko_sk2x** ^1786377689521143866
 
-@SebAaltonen
+**@SebAaltonen**
 
 Yes you shouldn't ever need to do that for anything nontrivial. But I've seen people who could just about get by with an IDE and seemingly able to do some things but not able to write a "hello world" without an IDE. The IDE was hiding real issues here.
 
-**7/** @SebAaltonen
+**7/** **@SebAaltonen** ^1786379429066768658
 
-@Barteks2x
+**@Barteks2x**
 
 When I am hiring a junior, I wouldn't want to make them code in notepad without Google, because nobody actually does that. If it was a code assignment, we can sit down and they can explain what their code does and why. I can also check their hobby projects in github.
 
-**8/** @Niko_sk2x
+**8/** **@Niko_sk2x** ^1786382425829872015
 
-@SebAaltonen
+**@SebAaltonen**
 
 Sure there definitely are easier and more reliable ways to judge someone's skill. It's not particularly good test of anything but still something you should be bake to do to some extent, at least a "hello world" and some other trivial programs.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-OscarBR92-to-assert-dominance.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-OscarBR92-to-assert-dominance.md
index 6ec4b78..5b48dd0 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-OscarBR92-to-assert-dominance.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-OscarBR92-to-assert-dominance.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @OscarBR92
+**1/** **@OscarBR92** ^1786385352522911990
 
-@SebAaltonen
+**@SebAaltonen**
 
 To assert dominance
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-PurpleNinjaGrrl-nothing-has-more-forever-a-junior-level.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-PurpleNinjaGrrl-nothing-has-more-forever-a-junior-level.md
index 209619a..0348b06 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-PurpleNinjaGrrl-nothing-has-more-forever-a-junior-level.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-PurpleNinjaGrrl-nothing-has-more-forever-a-junior-level.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @PurpleNinjaGrrl
+**1/** **@PurpleNinjaGrrl** ^1786457120608505969
 
-@SebAaltonen
+**@SebAaltonen**
 
 Nothing has more forever-a-junior-level-programmer energy than “You should spend more time and energy looking up API calls and typing console commands instead of using that time to iterate on your design and improve your code” takes
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-RatherSnideBun-that-is-just-another-it-twitter-bait-just-mute-or.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-RatherSnideBun-that-is-just-another-it-twitter-bait-just-mute-or.md
index 9759702..15eeea9 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-RatherSnideBun-that-is-just-another-it-twitter-bait-just-mute-or.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-RatherSnideBun-that-is-just-another-it-twitter-bait-just-mute-or.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @RatherSnideBun
+**1/** **@RatherSnideBun** ^1786405179580964870
 
-@SebAaltonen
+**@SebAaltonen**
 
 That is just another IT-twitter bait, just mute or block him, he is fuckwad.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-SebAaltonen-i-could-write-all-my-code-in-assembler-too-but.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-SebAaltonen-i-could-write-all-my-code-in-assembler-too-but.md
index 2ad5459..25d5c4a 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-SebAaltonen-i-could-write-all-my-code-in-assembler-too-but.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-SebAaltonen-i-could-write-all-my-code-in-assembler-too-but.md
@@ -26,15 +26,15 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1786347046741377418
 
 I could write all my code in assembler too. But why would I do that? Modern tools give me better productivity so I use them instead. I know how to read assembly when debugging code, but I want my compiler to write it.
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786347846360240538
 
 I personally use git from command line, but when I need to look at the history or solve a merge conflict, I jump into a modern GUI to do those tasks. GUI is just so much more productive for those tasks.
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1786349827669790823
 
 Professional programmer knows how to use the best tools to make them productive. This includes IDEs, debuggers, profilers, sanitizers, version control, etc, etc. And Google too (for API docs, etc). A 10x coder isn't sitting in dark room with terminal. They know how all the tools.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Shrikanthabudya-chill-bro-its-an-engagement-bait.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Shrikanthabudya-chill-bro-its-an-engagement-bait.md
index 1a7ca63..19efc3a 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Shrikanthabudya-chill-bro-its-an-engagement-bait.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Shrikanthabudya-chill-bro-its-an-engagement-bait.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Shrikanthabudya
+**1/** **@Shrikanthabudya** ^1786455727265157405
 
-@SebAaltonen
+**@SebAaltonen**
 
 chill bro it's an engagement bait
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tankerbot-yeah-if-its-available-use-it-though-in-my-case-i.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tankerbot-yeah-if-its-available-use-it-though-in-my-case-i.md
index 2e5a8d8..e0fd25a 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tankerbot-yeah-if-its-available-use-it-though-in-my-case-i.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tankerbot-yeah-if-its-available-use-it-though-in-my-case-i.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Tankerbot
+**1/** **@Tankerbot** ^1786435736582906182
 
-@SebAaltonen
+**@SebAaltonen**
 
 Yeah if it's available use it. Though in my case I end up using Notepad (Notepad++) for most of the C++ stuff I code mostly because it's Nintendo DS/DSi homebrew and setting them up in a IDE would be a pain given the build system they use so I've never bothered doing it. :P
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-TechTolley-old-guys-trying-to-act-like-their-depreciating.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-TechTolley-old-guys-trying-to-act-like-their-depreciating.md
index 9cfed30..aebbd7a 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-TechTolley-old-guys-trying-to-act-like-their-depreciating.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-TechTolley-old-guys-trying-to-act-like-their-depreciating.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @TechTolley
+**1/** **@TechTolley** ^1786378649324736838
 
-@SebAaltonen
+**@SebAaltonen**
 
 Old guys trying to act like their depreciating skillset makes them more valuable... somehow...
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ThePunkHucker-its-a-showcase-of-the-im-stronger-than-you.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ThePunkHucker-its-a-showcase-of-the-im-stronger-than-you.md
index 28a71e1..57f9513 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ThePunkHucker-its-a-showcase-of-the-im-stronger-than-you.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ThePunkHucker-its-a-showcase-of-the-im-stronger-than-you.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @ThePunkHucker
+**1/** **@ThePunkHucker** ^1786378176765059276
 
-@SebAaltonen
+**@SebAaltonen**
 
 It’s a showcase of the « I’m stronger than you » syndrome so many programmers have. It’s stupid.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tuuveee-for-the-first-few-months-of-my-first-web.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tuuveee-for-the-first-few-months-of-my-first-web.md
index 4293c8d..8313008 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tuuveee-for-the-first-few-months-of-my-first-web.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tuuveee-for-the-first-few-months-of-my-first-web.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Tuuveee
+**1/** **@Tuuveee** ^1786376771375431847
 
-@SebAaltonen
+**@SebAaltonen**
 
 For the first few months of my first web development job I was using notepad++. Which works fine for small projects, sure. But you'd have to threaten me with physical harm to make me go back. Using an IDE just makes the workflow so much better when working with more than one file
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-WillGermany-i-was-once-interviewed-where-they-asked-me-to.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-WillGermany-i-was-once-interviewed-where-they-asked-me-to.md
index c099575..65dd9a9 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-WillGermany-i-was-once-interviewed-where-they-asked-me-to.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-WillGermany-i-was-once-interviewed-where-they-asked-me-to.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @WillGermany
+**1/** **@WillGermany** ^1786376026483753449
 
-@SebAaltonen
+**@SebAaltonen**
 
 I was once interviewed where they asked me to write code and diagram databases in Notepad 🤦‍♂️
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XBigand-i-start-to-consider-to-go-back-to-a-simple-text.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XBigand-i-start-to-consider-to-go-back-to-a-simple-text.md
index 8789d73..a19e819 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XBigand-i-start-to-consider-to-go-back-to-a-simple-text.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XBigand-i-start-to-consider-to-go-back-to-a-simple-text.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @XBigand
+**1/** **@XBigand** ^1786376101192778096
 
-@SebAaltonen
+**@SebAaltonen**
 
 I start to consider to go back to a simple text editor, like when I was using emacs at school, juste because VS is getting worse.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XenoVoid112-you-shouldnt-actually-do-it-you-should-be-able-to.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XenoVoid112-you-shouldnt-actually-do-it-you-should-be-able-to.md
index 6aca6a1..28afbe3 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XenoVoid112-you-shouldnt-actually-do-it-you-should-be-able-to.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XenoVoid112-you-shouldnt-actually-do-it-you-should-be-able-to.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @XenoVoid112
+**1/** **@XenoVoid112** ^1786445740434235519
 
-@SebAaltonen
+**@SebAaltonen**
 
 You shouldn't actually do it. You should be *ABLE* to do it. They mean you should be able to know a language enough that you don't need tools to assist. At least, that is my interpretation
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ZoldenGames-some-people-feel-scared-to-give-up-lower-level.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ZoldenGames-some-people-feel-scared-to-give-up-lower-level.md
index e92c4d8..c32fd90 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ZoldenGames-some-people-feel-scared-to-give-up-lower-level.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ZoldenGames-some-people-feel-scared-to-give-up-lower-level.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @ZoldenGames
+**1/** **@ZoldenGames** ^1786394607338623091
 
-@SebAaltonen
+**@SebAaltonen**
 
 Some people feel scared to give up lower level tasks to automatization. But that's how progress works and productivity grows.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_Felipe-blue-check-farming-engagement.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_Felipe-blue-check-farming-engagement.md
index 3d40de5..85b2530 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_Felipe-blue-check-farming-engagement.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_Felipe-blue-check-farming-engagement.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @_Felipe
+**1/** **@_Felipe** ^1786409180720472164
 
-@SebAaltonen
+**@SebAaltonen**
 
 blue check farming engagement
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_benwick-the-key-word-is-able-how-many-people-cannot.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_benwick-the-key-word-is-able-how-many-people-cannot.md
index aae5c86..297b0e4 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_benwick-the-key-word-is-able-how-many-people-cannot.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_benwick-the-key-word-is-able-how-many-people-cannot.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @_benwick
+**1/** **@_benwick** ^1786368655640453619
 
-@SebAaltonen
+**@SebAaltonen**
 
 The key word is ABLE. How many people cannot compile a program without the visual studio ide? You're only cheating yourself if you don't understand how your toolchain does its work.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-atomlib-its-a-meme-from-a-person-who-posts-nothing-but.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-atomlib-its-a-meme-from-a-person-who-posts-nothing-but.md
index 99286d7..0954c10 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-atomlib-its-a-meme-from-a-person-who-posts-nothing-but.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-atomlib-its-a-meme-from-a-person-who-posts-nothing-but.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @atomlib
+**1/** **@atomlib** ^1786380669016224073
 
-@SebAaltonen
+**@SebAaltonen**
 
 It's a meme from a person who posts nothing but memes on Twitter. There's no meaningful debate here. Frankly, there's simply nothing worth paying attention to as this person is only interested in your engagement.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-baris2c-its-bait.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-baris2c-its-bait.md
index 09ecd0e..2dc0375 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-baris2c-its-bait.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-baris2c-its-bait.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @baris2c
+**1/** **@baris2c** ^1786442578306707791
 
-@SebAaltonen
+**@SebAaltonen**
 
 it's bait.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-bozoid-its-just-coder-bravado-to-show-off-toy-algorithms.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-bozoid-its-just-coder-bravado-to-show-off-toy-algorithms.md
index 56a477d..b75923f 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-bozoid-its-just-coder-bravado-to-show-off-toy-algorithms.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-bozoid-its-just-coder-bravado-to-show-off-toy-algorithms.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @bozoid
+**1/** **@bozoid** ^1786382993696727539
 
-@SebAaltonen
+**@SebAaltonen**
 
 it's just coder bravado to show off toy algorithms
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-burlapDD-they-are-signaling-but-its-like-being-proud-of.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-burlapDD-they-are-signaling-but-its-like-being-proud-of.md
index cd5055c..19dc857 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-burlapDD-they-are-signaling-but-its-like-being-proud-of.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-burlapDD-they-are-signaling-but-its-like-being-proud-of.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @burlapDD
+**1/** **@burlapDD** ^1786439905972732411
 
-@SebAaltonen
+**@SebAaltonen**
 
 They are signaling 
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-coolkoon-because-when-you-have-to-fix-something-on-a.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-coolkoon-because-when-you-have-to-fix-something-on-a.md
index 66c46f2..0f18dd2 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-coolkoon-because-when-you-have-to-fix-something-on-a.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-coolkoon-because-when-you-have-to-fix-something-on-a.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @coolkoon
+**1/** **@coolkoon** ^1786523621361344970
 
-@SebAaltonen
+**@SebAaltonen**
 
 Because when you have to fix something on a customer system then usually notepad/vim/nano is literally the only option you have, that's why.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-damianGray-you-should-be-able-to-code-with-punch-cards.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-damianGray-you-should-be-able-to-code-with-punch-cards.md
index b7a7144..1298ade 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-damianGray-you-should-be-able-to-code-with-punch-cards.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-damianGray-you-should-be-able-to-code-with-punch-cards.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @damianGray
+**1/** **@damianGray** ^1786470064260051263
 
-@SebAaltonen
+**@SebAaltonen**
 
 "You should be able to code with punch cards directly in binary" same energy
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-deejayyhu-debate-is-not-about-when-you-dont-want-to-use.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-deejayyhu-debate-is-not-about-when-you-dont-want-to-use.md
index 05998b4..ea9a1c4 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-deejayyhu-debate-is-not-about-when-you-dont-want-to-use.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-deejayyhu-debate-is-not-about-when-you-dont-want-to-use.md
@@ -26,9 +26,9 @@ parent_post_id: "1786349827669790823"
 
 ## Branch
 
-**1/** @deejayyhu
+**1/** **@deejayyhu** ^1786422302373974029
 
-@SebAaltonen
+**@SebAaltonen**
 
 Debate is not about when you don't want to use notepad, but when you are not able to use it.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dmitriid-the-anti-tooling-discourse-in-programming-is.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dmitriid-the-anti-tooling-discourse-in-programming-is.md
index 9871b63..624cb55 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dmitriid-the-anti-tooling-discourse-in-programming-is.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dmitriid-the-anti-tooling-discourse-in-programming-is.md
@@ -26,9 +26,9 @@ parent_post_id: "1786349827669790823"
 
 ## Branch
 
-**1/** @dmitriid
+**1/** **@dmitriid** ^1786352488557191368
 
-@SebAaltonen
+**@SebAaltonen**
 
 The anti-tooling discourse in programming is quite tiring
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dorithegreat128-you-should-be-able-to-it-shows-that-you.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dorithegreat128-you-should-be-able-to-it-shows-that-you.md
index c82e032..abd1597 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dorithegreat128-you-should-be-able-to-it-shows-that-you.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dorithegreat128-you-should-be-able-to-it-shows-that-you.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @dorithegreat128
+**1/** **@dorithegreat128** ^1786485165029564483
 
-@SebAaltonen
+**@SebAaltonen**
 
 You should be *able* to, it shows that you understand what you're writing, but you shouldn't *actually* do it because it's ridiculously inefficient
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-fightuntil-real-programmers-use-a-magnetized-needle-and-a.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-fightuntil-real-programmers-use-a-magnetized-needle-and-a.md
index 803692a..23d768c 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-fightuntil-real-programmers-use-a-magnetized-needle-and-a.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-fightuntil-real-programmers-use-a-magnetized-needle-and-a.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @fightuntil
+**1/** **@fightuntil** ^1786509624205566416
 
-@SebAaltonen
+**@SebAaltonen**
 
 Real programmers use a magnetized needle and a steady hand.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-foudre_tempete-tbf-intelisense-is-just-a-faster-way-of-finding.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-foudre_tempete-tbf-intelisense-is-just-a-faster-way-of-finding.md
index 7d5ac5d..2332375 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-foudre_tempete-tbf-intelisense-is-just-a-faster-way-of-finding.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-foudre_tempete-tbf-intelisense-is-just-a-faster-way-of-finding.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @foudre_tempete
+**1/** **@foudre_tempete** ^1786517465356177659
 
-@SebAaltonen
+**@SebAaltonen**
 
 Tbf intelisense is just a faster way of finding the right code/method to do something instead of finding it online or in a book...
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-frostyfrog-i-started-in-notepad-now-i-use-vim-for-all-my.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-frostyfrog-i-started-in-notepad-now-i-use-vim-for-all-my.md
index 02663c0..e66a4b4 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-frostyfrog-i-started-in-notepad-now-i-use-vim-for-all-my.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-frostyfrog-i-started-in-notepad-now-i-use-vim-for-all-my.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @frostyfrog
+**1/** **@frostyfrog** ^1786446908376166773
 
-@SebAaltonen
+**@SebAaltonen**
 
 I started in notepad, now I use vim for all my programming needs
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-games_pants-i-had-that-at-an-interview-once-a-programming.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-games_pants-i-had-that-at-an-interview-once-a-programming.md
index dd9304e..b44798f 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-games_pants-i-had-that-at-an-interview-once-a-programming.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-games_pants-i-had-that-at-an-interview-once-a-programming.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @games_pants
+**1/** **@games_pants** ^1786349232997142887
 
-@SebAaltonen
+**@SebAaltonen**
 
 I had that at an interview once. A programming test in Notepad.  90% of my time was spent battling the text editor! I probably should have got up and walked out.. it was a sign of worse things to come when I got the job :)
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-gregrthenson-i-once-was-in-an-interview-where-they-handed-me-a.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-gregrthenson-i-once-was-in-an-interview-where-they-handed-me-a.md
index 44c848a..3e4b1f8 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-gregrthenson-i-once-was-in-an-interview-where-they-handed-me-a.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-gregrthenson-i-once-was-in-an-interview-where-they-handed-me-a.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @gregrthenson
+**1/** **@gregrthenson** ^1786425967688524176
 
-@SebAaltonen
+**@SebAaltonen**
 
 I once was in an interview where they handed me a pen and paper and said "write this program"
 I started writing pseudo code and they stopped me and said "no, actually write it"
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-h15panicatd-honestly-the-meme-works-infinitely-better-if-you.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-h15panicatd-honestly-the-meme-works-infinitely-better-if-you.md
index 91cae25..8c107f6 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-h15panicatd-honestly-the-meme-works-infinitely-better-if-you.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-h15panicatd-honestly-the-meme-works-infinitely-better-if-you.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @h15panicatd
+**1/** **@h15panicatd** ^1786451570667708834
 
-@SebAaltonen
+**@SebAaltonen**
 
 Honestly the meme works infinitely better if you sub IntelliSense out for Copilot.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-heyotetsuo-use-whatever-you-want.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-heyotetsuo-use-whatever-you-want.md
index 0dc6613..28f8c94 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-heyotetsuo-use-whatever-you-want.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-heyotetsuo-use-whatever-you-want.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @heyotetsuo
+**1/** **@heyotetsuo** ^1786388450779824330
 
-@SebAaltonen @SebAaltonen
+**@SebAaltonen** **@SebAaltonen**
 
 use whatever you want
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-jmac_ai-the-meme-isnt-saying-you-shouldnt-use-it-its.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-jmac_ai-the-meme-isnt-saying-you-shouldnt-use-it-its.md
index 69e19e2..49eae8b 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-jmac_ai-the-meme-isnt-saying-you-shouldnt-use-it-its.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-jmac_ai-the-meme-isnt-saying-you-shouldnt-use-it-its.md
@@ -26,51 +26,51 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @jmac_ai
+**1/** **@jmac_ai** ^1786374064958849320
 
-@SebAaltonen
+**@SebAaltonen**
 
 The meme isn't saying you shouldn't use it, it's saying you should be *able* to still program without it.
 
 The implied meaning is that you should have a strong foundational understanding to build what you need that tools amplify.
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786377316001624088
 
-@jmac_ai
+**@jmac_ai**
 
 Yes. But programming is 90% reading code, and browsing though a big code base in notepad is just insanely slow. You open cmake files to multiple tabs and file browsers to others to find the files, etc. In good IDE you just click. Reading code is the problem, not writing.
 
-**3/** @jmac_ai
+**3/** **@jmac_ai** ^1786377462764462587
 
-@SebAaltonen
+**@SebAaltonen**
 
 Of course it's slow. Again, that's not the point :p
 
-**4/** @SebAaltonen
+**4/** **@SebAaltonen** ^1786377665504489478
 
-@jmac_ai
+**@jmac_ai**
 
 Why would anybody want to learn a slow cumbersome practice that nobody should use in professional development? I still don't understand.
 
-**5/** @jmac_ai
+**5/** **@jmac_ai** ^1786379822073008231
 
-@SebAaltonen
+**@SebAaltonen**
 
 Bc it forces you to build a foundational knowledge. That helps when tools have a bug; it helps you understand where to look for things; allows you to make better tools, etc.
 
 E.g., When an IDE isn't working right for someone I can help fix it, bc I understand the foundations.
 
-**6/** @the_vertigamer
+**6/** **@the_vertigamer** ^1786384656960745761
 
-@jmac_ai @SebAaltonen
+**@jmac_ai** **@SebAaltonen**
 
 Does it really though? It never (at least for me) does much more than autocomplete particularly long types. That's not really doing the code for me, I'm still having to design the algorithm. 
 
 Further inteli often gets it wrong so you have to know what ur doing. It's  !copilot.
 
-**7/** @jmac_ai
+**7/** **@jmac_ai** ^1786386782600208791
 
-@the_vertigamer @SebAaltonen
+**@the_vertigamer** **@SebAaltonen**
 
 Plausibly you could learn all the foundations in different ways. The meme isn't prescriptive that you learn by doing it the hard way, only that you *could* do it the hard way. If you couldn't, then it suggests you haven't learned all the foundations.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-leonpalafox-because-thats-how-we-learned-and-you-should-too.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-leonpalafox-because-thats-how-we-learned-and-you-should-too.md
index 3128790..c2faf32 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-leonpalafox-because-thats-how-we-learned-and-you-should-too.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-leonpalafox-because-thats-how-we-learned-and-you-should-too.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @leonpalafox
+**1/** **@leonpalafox** ^1786402943597437170
 
-@SebAaltonen
+**@SebAaltonen**
 
 Because that’s how we learned and you should too 😂
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-lethal_guitar-its-like-telling-a-carpenter-you-should-be-able.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-lethal_guitar-its-like-telling-a-carpenter-you-should-be-able.md
index 84bcfd4..135fb05 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-lethal_guitar-its-like-telling-a-carpenter-you-should-be-able.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-lethal_guitar-its-like-telling-a-carpenter-you-should-be-able.md
@@ -26,15 +26,15 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @lethal_guitar
+**1/** **@lethal_guitar** ^1786371061866697103
 
-@SebAaltonen
+**@SebAaltonen**
 
 It's like telling a carpenter "You should be able to do all your work without power tools". Yeah it's possible, but it's extremely slow and exhausting so there's no good reason to do it when better alternatives exist.
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786371709991354639
 
-@lethal_guitar
+**@lethal_guitar**
 
 Yeah. You have done it manually a few times first and then you learn how to use tools. Technically you would still be able to do the thing manually, but you haven't done that in a few years. I could code with notepad, but it would just be much slower and more painful.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maessof91-it-makes-old-people-feel-cool-because-they-at.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maessof91-it-makes-old-people-feel-cool-because-they-at.md
index 7043ae0..9651628 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maessof91-it-makes-old-people-feel-cool-because-they-at.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maessof91-it-makes-old-people-feel-cool-because-they-at.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @maessof91
+**1/** **@maessof91** ^1786440206758858835
 
-@SebAaltonen
+**@SebAaltonen**
 
 It makes old people feel cool, because they at some point were forced to code like that
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maisakal-you-are-an-intellisense-yourself-if-you-have-the.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maisakal-you-are-an-intellisense-yourself-if-you-have-the.md
index ebeac0b..9a54fef 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maisakal-you-are-an-intellisense-yourself-if-you-have-the.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maisakal-you-are-an-intellisense-yourself-if-you-have-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @maisakal
+**1/** **@maisakal** ^1786521520094740901
 
-@SebAaltonen
+**@SebAaltonen**
 
 You are an intellisense yourself if you have the references at your disposal. You just need to look it up. Don’t be a lazyass, go look it up.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-mbc0der-should-be-able-to-doesnt-mean-prefer-to-its-just.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-mbc0der-should-be-able-to-doesnt-mean-prefer-to-its-just.md
index 3212e6b..b329c94 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-mbc0der-should-be-able-to-doesnt-mean-prefer-to-its-just.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-mbc0der-should-be-able-to-doesnt-mean-prefer-to-its-just.md
@@ -26,21 +26,21 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @mbc0der
+**1/** **@mbc0der** ^1786375791606911412
 
-@SebAaltonen
+**@SebAaltonen**
 
 "Should be able to" doesn't mean "prefer to."  It's just a base line level of fluency that implies more experience and probably more competency.
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786376814434087383
 
-@mbc0der
+**@mbc0der**
 
 I really can't read a big code base using notepad. It's so painful to manually juggle dozen of cmake files to find where every header is so that I can read them. Coding is 90% reading. Of course everybody can write on notepad. That's not the problem.
 
-**3/** @mbc0der
+**3/** **@mbc0der** ^1786387977955836044
 
-@SebAaltonen
+**@SebAaltonen**
 
 Yes, I agree it's unwieldy to do so in a very large codebase or one that you are unfamiliar with. Obviously this is just a meme so there's not much nuance, and you can interpret it in different ways.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-megaloid6-you-are-weak.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-megaloid6-you-are-weak.md
index e16ad2a..b8602e0 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-megaloid6-you-are-weak.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-megaloid6-you-are-weak.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @megaloid6
+**1/** **@megaloid6** ^1786492057105678716
 
-@SebAaltonen
+**@SebAaltonen**
 
 You are weak
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-officiallyninja-i-think-there-is-some-value-in-this-at-least-for.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-officiallyninja-i-think-there-is-some-value-in-this-at-least-for.md
index ff7b3d5..26f71fd 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-officiallyninja-i-think-there-is-some-value-in-this-at-least-for.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-officiallyninja-i-think-there-is-some-value-in-this-at-least-for.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @officiallyninja
+**1/** **@officiallyninja** ^1786436393788653753
 
-@SebAaltonen
+**@SebAaltonen**
 
 I think there is some value in this. At least for a beginner. You should be able to use notepad + terminal to write simple programs. That doesn't mean it's practical. But any intermediate dev should be able to do it, it'll be annoying yes, but not *that* hard for small problems
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-pepite2choc-its-not-about-wanting-its-about-being-able-to.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-pepite2choc-its-not-about-wanting-its-about-being-able-to.md
index 4fd1173..fac032e 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-pepite2choc-its-not-about-wanting-its-about-being-able-to.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-pepite2choc-its-not-about-wanting-its-about-being-able-to.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @pepite2choc
+**1/** **@pepite2choc** ^1786371808930799629
 
-@SebAaltonen
+**@SebAaltonen**
 
 It's not about wanting, it's about being able to.
 Just a car driver should be able to drive without driving assistance.
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-redhog_org-no-need-to-do-that-but-to-be-able-to-if-unable.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-redhog_org-no-need-to-do-that-but-to-be-able-to-if-unable.md
index 8a18345..0b635a2 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-redhog_org-no-need-to-do-that-but-to-be-able-to-if-unable.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-redhog_org-no-need-to-do-that-but-to-be-able-to-if-unable.md
@@ -26,33 +26,33 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @redhog_org
+**1/** **@redhog_org** ^1786423454129905799
 
-@SebAaltonen
+**@SebAaltonen**
 
 No need to do that. But to be able to. If unable, the tools are fooling you to think you understand the code better than you actually do.
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1786424712878326005
 
-@redhog_org
+**@redhog_org**
 
 Is there really some benefit for finding each symbol in 10 million line code base by browsing directory structure manually? You could just click on a symbol to find the implementation in IDE, read it and continue. 10x+ faster. Coding is 90% reading. Notepad is not great for that.
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1786425086351671740
 
-@redhog_org
+**@redhog_org**
 
 Anybody could write code in notepad. The problem is reading. Writing code is less than <10% of programmer's time. Reading and browsing the code base is what matters. For that you need code highlight and jump to symbols, caller graphs, etc. Step flow with debugger.
 
-**4/** @SebAaltonen
+**4/** **@SebAaltonen** ^1786425333098438679
 
-@redhog_org
+**@redhog_org**
 
 I would be much more concerned if a junior programmer would not be using IDE to boost their productivity. I don't need to know whether they could write the code in notepad, since nobody really does that. That's not the job.
 
-**5/** @redhog_org
+**5/** **@redhog_org** ^1786436848308342875
 
-@SebAaltonen
+**@SebAaltonen**
 
 It is exactly the junior devs that need an IDE because their mental model of thew whole project is lacking, that build spaghetti across the project. Their productivity is only worth it if it doesn't cost more in PR review and reefaactoring.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ruch483-they-just-gaslight-themselves-that-their-broken.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ruch483-they-just-gaslight-themselves-that-their-broken.md
index f4d6039..7cf0489 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ruch483-they-just-gaslight-themselves-that-their-broken.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ruch483-they-just-gaslight-themselves-that-their-broken.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @ruch483
+**1/** **@ruch483** ^1786443239559504004
 
-@SebAaltonen
+**@SebAaltonen**
 
 they just gaslight themselves that their broken vim config is equivalent to a proper IDE
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-saarw-simple-editors-tend-to-lead-to-other-bad-choices.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-saarw-simple-editors-tend-to-lead-to-other-bad-choices.md
index 940f607..cc12bf3 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-saarw-simple-editors-tend-to-lead-to-other-bad-choices.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-saarw-simple-editors-tend-to-lead-to-other-bad-choices.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @saarw
+**1/** **@saarw** ^1786425298981933267
 
-@SebAaltonen
+**@SebAaltonen**
 
 Simple editors tend to lead to other bad choices to compensate. Such as preference for languages that have so little syntax and type information that they create maintenance nightmares
 https://x.com/saarw/status/1755529704180720114?t=zfjfI-8BhZ915QDCMRRjAQ&s=19
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-sksauli-this.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-sksauli-this.md
index 9ad145b..c35335d 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-sksauli-this.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-sksauli-this.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @sksauli
+**1/** **@sksauli** ^1786361331567796680
 
-@SebAaltonen
+**@SebAaltonen**
 
 This?
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-smurfpappa123-the-decel-mind-is-perplexing.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-smurfpappa123-the-decel-mind-is-perplexing.md
index 8133aa2..f0c39db 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-smurfpappa123-the-decel-mind-is-perplexing.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-smurfpappa123-the-decel-mind-is-perplexing.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @smurfpappa123
+**1/** **@smurfpappa123** ^1786489038234382830
 
-@SebAaltonen
+**@SebAaltonen**
 
 The decel mind is perplexing 🤔
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-streetsofboston-folks-advocating-for-notepad-coding-is-much-like.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-streetsofboston-folks-advocating-for-notepad-coding-is-much-like.md
index 8f68f85..1d2befe 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-streetsofboston-folks-advocating-for-notepad-coding-is-much-like.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-streetsofboston-folks-advocating-for-notepad-coding-is-much-like.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @streetsofboston
+**1/** **@streetsofboston** ^1786460687641813039
 
-@SebAaltonen
+**@SebAaltonen**
 
 Folks advocating for "notepad" coding is much like a grandfather boasting how he walked to school during a blizzard.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-theogramme_dev-to-prove-twitter-theyre-good-coders.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-theogramme_dev-to-prove-twitter-theyre-good-coders.md
index be87af1..f4a0483 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-theogramme_dev-to-prove-twitter-theyre-good-coders.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-theogramme_dev-to-prove-twitter-theyre-good-coders.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @theogramme_dev
+**1/** **@theogramme_dev** ^1786473324903592323
 
-@SebAaltonen
+**@SebAaltonen**
 
 To prove twitter they're good coders
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thewillsykes-i-sort-of-agree-but-im-so-often-forced-to-code.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thewillsykes-i-sort-of-agree-but-im-so-often-forced-to-code.md
index 34adb83..28e7aa7 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thewillsykes-i-sort-of-agree-but-im-so-often-forced-to-code.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thewillsykes-i-sort-of-agree-but-im-so-often-forced-to-code.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @thewillsykes
+**1/** **@thewillsykes** ^1786531082961141959
 
-@SebAaltonen
+**@SebAaltonen**
 
 i sort of agree, but i'm so often forced to code with no functional IDE when teaching students (cos they haven't set up correctly) that i can say it's a helpful skill to keep. When i started coding C, I used "Edit" in Dos... I hugely prefer auto complete but it has made me weaker
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thr0wsException-its-obvious-engagement-farming-rage-bait-just.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thr0wsException-its-obvious-engagement-farming-rage-bait-just.md
index 7b4f2a1..7e0efe2 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thr0wsException-its-obvious-engagement-farming-rage-bait-just.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thr0wsException-its-obvious-engagement-farming-rage-bait-just.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @thr0wsException
+**1/** **@thr0wsException** ^1786437232456278458
 
-@SebAaltonen
+**@SebAaltonen**
 
 It's obvious engagement farming / rage bait. Just ignore it tbh
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-unmodify-its-a-desire-to-appear-extraordinarily-competent.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-unmodify-its-a-desire-to-appear-extraordinarily-competent.md
index d1b6edf..e52e1f2 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-unmodify-its-a-desire-to-appear-extraordinarily-competent.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-unmodify-its-a-desire-to-appear-extraordinarily-competent.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @unmodify
+**1/** **@unmodify** ^1786410294052327835
 
-@SebAaltonen
+**@SebAaltonen**
 
 It's a desire to appear extraordinarily competent without having worked enough for it. Ie. Youth.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-virtuallyfun-because-i-dont-want-the-distractions-i-dont-want.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-virtuallyfun-because-i-dont-want-the-distractions-i-dont-want.md
index 4963c9b..620dd8c 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-virtuallyfun-because-i-dont-want-the-distractions-i-dont-want.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-virtuallyfun-because-i-dont-want-the-distractions-i-dont-want.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @virtuallyfun
+**1/** **@virtuallyfun** ^1786514434338288033
 
-@SebAaltonen
+**@SebAaltonen**
 
 Because I don’t want the distractions, I don’t want my hand held, I just want to type, typos and all.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-wrd83-i-would-agree-with-the-original-poster-you-should.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-wrd83-i-would-agree-with-the-original-poster-you-should.md
index e281a17..c020702 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-wrd83-i-would-agree-with-the-original-poster-you-should.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-wrd83-i-would-agree-with-the-original-poster-you-should.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @wrd83
+**1/** **@wrd83** ^1786410316886073424
 
-@SebAaltonen
+**@SebAaltonen**
 
 I would agree with the original poster. You should be able to code in notepad.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ytvizthex-hell-i-used-notepad-for-my-shitty-terraria-mods.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ytvizthex-hell-i-used-notepad-for-my-shitty-terraria-mods.md
index 8bbddb7..5371b2b 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ytvizthex-hell-i-used-notepad-for-my-shitty-terraria-mods.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ytvizthex-hell-i-used-notepad-for-my-shitty-terraria-mods.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @ytvizthex
+**1/** **@ytvizthex** ^1786444946322399302
 
-@SebAaltonen
+**@SebAaltonen**
 
 Hell, I used notepad++ for my shitty terraria mods and the TML discord act like I sacrificed them all to Satan lmfao
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-AdmiralMemo-i-think-people-should-be-able-to-code-without.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-AdmiralMemo-i-think-people-should-be-able-to-code-without.md
index 6693277..646c084 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-AdmiralMemo-i-think-people-should-be-able-to-code-without.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-AdmiralMemo-i-think-people-should-be-able-to-code-without.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @AdmiralMemo
+**1/** **@AdmiralMemo** ^1786553588770099354
 
-@SebAaltonen
+**@SebAaltonen**
 
 I think people should be able to code without tools, but I'm not going to try to take the tools away. If you can't code without it, you should git gud, but until then, keep coding at least. Something's better than nothing.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Ancients-there-is-an-argument-where-people-build-systems.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Ancients-there-is-an-argument-where-people-build-systems.md
index 385e260..4071319 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Ancients-there-is-an-argument-where-people-build-systems.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Ancients-there-is-an-argument-where-people-build-systems.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Ancients
+**1/** **@Ancients** ^1786548526392254591
 
-@SebAaltonen
+**@SebAaltonen**
 
 There is an argument where people build systems as complex and resource intensive as their tooling will allow. 
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-CHChistris-i-guess-this-is-just-another-expression-of-the-if.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-CHChistris-i-guess-this-is-just-another-expression-of-the-if.md
index c180608..a47eee8 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-CHChistris-i-guess-this-is-just-another-expression-of-the-if.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-CHChistris-i-guess-this-is-just-another-expression-of-the-if.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @CHChistris
+**1/** **@CHChistris** ^1786749107635154982
 
-@SebAaltonen
+**@SebAaltonen**
 
 I guess this is just another expression of the "if I had to suffer, you should too. To give sense to why I had to suffer" school of thought. 
 I prefer the "this sucks, and I hope I can make it better for everyone" school of thought
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-FChapeau-its-gatekeeping-really-there-has-never-been-a.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-FChapeau-its-gatekeeping-really-there-has-never-been-a.md
index 8df1748..9e37f40 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-FChapeau-its-gatekeeping-really-there-has-never-been-a.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-FChapeau-its-gatekeeping-really-there-has-never-been-a.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @FChapeau
+**1/** **@FChapeau** ^1786635431813034178
 
-@SebAaltonen
+**@SebAaltonen**
 
 It’s gatekeeping really. There has never been a better time to learn programming, with fantastic free tools, but you apparently need to be able to work a specific way if you want to be a “real” programmer.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-JasonKn99664124-honestly-a-lot-of-the-framework-and-transpiler.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-JasonKn99664124-honestly-a-lot-of-the-framework-and-transpiler.md
index 4b18c30..0320ff1 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-JasonKn99664124-honestly-a-lot-of-the-framework-and-transpiler.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-JasonKn99664124-honestly-a-lot-of-the-framework-and-transpiler.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @JasonKn99664124
+**1/** **@JasonKn99664124** ^1786546828088844682
 
-@SebAaltonen
+**@SebAaltonen**
 
 Honestly a lot of the "framework" and "transpiler" idiocy  is what makes you reliant on tooling you don't need. 
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-KlavsPeder-sometimes-we-are-limited-by-our-environment-which.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-KlavsPeder-sometimes-we-are-limited-by-our-environment-which.md
index d950402..da2c1de 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-KlavsPeder-sometimes-we-are-limited-by-our-environment-which.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-KlavsPeder-sometimes-we-are-limited-by-our-environment-which.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @KlavsPeder
+**1/** **@KlavsPeder** ^1786736699826917681
 
-@SebAaltonen
+**@SebAaltonen**
 
 Sometimes we are limited by our environment, which may limit us to the tools available on the device we are working on. This may be 'cat > file.c', ed, ex, notepad or whatever.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Matagi1996-its-not-like-you-should-only-code-without-support.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Matagi1996-its-not-like-you-should-only-code-without-support.md
index 1d1d719..ee63dbf 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Matagi1996-its-not-like-you-should-only-code-without-support.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Matagi1996-its-not-like-you-should-only-code-without-support.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @Matagi1996
+**1/** **@Matagi1996** ^1786611007932203092
 
-@SebAaltonen
+**@SebAaltonen**
 
 Its not like you should only code without Support, but its nice to be able to. Sometimes you only are connected to a machine over a console via ssh and have to use Vim.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-NohBody3-why-do-they-teach-arithmetic-we-all-have.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-NohBody3-why-do-they-teach-arithmetic-we-all-have.md
index 62d63dc..b350369 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-NohBody3-why-do-they-teach-arithmetic-we-all-have.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-NohBody3-why-do-they-teach-arithmetic-we-all-have.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @NohBody3
+**1/** **@NohBody3** ^1786647295032951196
 
-@SebAaltonen
+**@SebAaltonen**
 
 Why do they teach arithmetic, we all have calculators
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-RyanAlban1-not-notepad-but-i-have-done-a-non-zero-amount-of.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-RyanAlban1-not-notepad-but-i-have-done-a-non-zero-amount-of.md
index 12b2c3e..9325f31 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-RyanAlban1-not-notepad-but-i-have-done-a-non-zero-amount-of.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-RyanAlban1-not-notepad-but-i-have-done-a-non-zero-amount-of.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @RyanAlban1
+**1/** **@RyanAlban1** ^1786746136751149410
 
-@SebAaltonen
+**@SebAaltonen**
 
 Not Notepad, but I have done a non-zero amount of programming in source control diff tools that have none of those features. It was the quickest way to solve the problem at the time.😅
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-YohanOttie-people-will-justify-programming-c-c-on-linux-on.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-YohanOttie-people-will-justify-programming-c-c-on-linux-on.md
index 318cd82..ae6be8a 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-YohanOttie-people-will-justify-programming-c-c-on-linux-on.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-YohanOttie-people-will-justify-programming-c-c-on-linux-on.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @YohanOttie
+**1/** **@YohanOttie** ^1786718354339721619
 
-@SebAaltonen
+**@SebAaltonen**
 
 People will justify programming C/C++ on Linux. On leafpad.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-andokal-if-you-cant-code-tcl-using-vi-through-a-bash.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-andokal-if-you-cant-code-tcl-using-vi-through-a-bash.md
index 2025d05..d0adbe7 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-andokal-if-you-cant-code-tcl-using-vi-through-a-bash.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-andokal-if-you-cant-code-tcl-using-vi-through-a-bash.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @andokal
+**1/** **@andokal** ^1786764675725541769
 
-@SebAaltonen
+**@SebAaltonen**
 
 If you can’t code TCL using VI through a bash terminal on a remote Unix box with CVS SC, you can’t code. But seriously, more than half of the modern internet ran on that for about a decade (AOL).
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-bmarci7-i-would-say-you-should-code-in-a-way-that-is.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-bmarci7-i-would-say-you-should-code-in-a-way-that-is.md
index a088c5b..75ebb7b 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-bmarci7-i-would-say-you-should-code-in-a-way-that-is.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-bmarci7-i-would-say-you-should-code-in-a-way-that-is.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @bmarci7
+**1/** **@bmarci7** ^1786660310956347746
 
-@SebAaltonen
+**@SebAaltonen**
 
 I would say, you should code in a way that is readable even in notepad.
 Using auto keyword and other modern stuff makes your code look like a cryptography without a good ide :/
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-codesonpaper-the-skill-issue-is-strong-with-this-one.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-codesonpaper-the-skill-issue-is-strong-with-this-one.md
index 2ed4c1d..94626cd 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-codesonpaper-the-skill-issue-is-strong-with-this-one.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-codesonpaper-the-skill-issue-is-strong-with-this-one.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @codesonpaper
+**1/** **@codesonpaper** ^1786619675755114626
 
-@SebAaltonen
+**@SebAaltonen**
 
 The skill issue is strong with this one
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-cpps93-i-learn-to-code-in-c-back-in-2011-and-my-teacher.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-cpps93-i-learn-to-code-in-c-back-in-2011-and-my-teacher.md
index ca61d96..23c2de5 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-cpps93-i-learn-to-code-in-c-back-in-2011-and-my-teacher.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-cpps93-i-learn-to-code-in-c-back-in-2011-and-my-teacher.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @cpps93
+**1/** **@cpps93** ^1786651316023902407
 
-@SebAaltonen
+**@SebAaltonen**
 
 I learn to code in C++ back in 2011 and my teacher advised us to work for the moment in Notepad++ just to LEARN,for example,I remember when a function receives a pointer to try to call it placing a lot of '*' or '&' and wait for intellisense not to complain about what i'd written
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-daihaminkey-and-when-there-is-no-tool-for-something-they.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-daihaminkey-and-when-there-is-no-tool-for-something-they.md
index c0d68ba..3b270e5 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-daihaminkey-and-when-there-is-no-tool-for-something-they.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-daihaminkey-and-when-there-is-no-tool-for-something-they.md
@@ -26,9 +26,9 @@ parent_post_id: "1786349827669790823"
 
 ## Branch
 
-**1/** @daihaminkey
+**1/** **@daihaminkey** ^1786617722962686400
 
-@SebAaltonen
+**@SebAaltonen**
 
 And when there is no tool for something, they develop it.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-fforw-you-never-know-when-a-time-machine-will-transport.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-fforw-you-never-know-when-a-time-machine-will-transport.md
index 37fbfd1..e5ce9d1 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-fforw-you-never-know-when-a-time-machine-will-transport.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-fforw-you-never-know-when-a-time-machine-will-transport.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @fforw
+**1/** **@fforw** ^1786603596831699134
 
-@SebAaltonen
+**@SebAaltonen**
 
 You never know when a time machine will transport you back into the early 90s and you have to live there and earn a living as software developer.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-gengsterrebber-its-about-gatekeeping-and-feeling-superior.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-gengsterrebber-its-about-gatekeeping-and-feeling-superior.md
index 7d3b04a..dafb79d 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-gengsterrebber-its-about-gatekeeping-and-feeling-superior.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-gengsterrebber-its-about-gatekeeping-and-feeling-superior.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @gengsterrebber
+**1/** **@gengsterrebber** ^1786759021136876020
 
-@SebAaltonen
+**@SebAaltonen**
 
 It's about gatekeeping and feeling superior, Sebastian. Duh.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kechogarcia-ctags-and-cscope-if-you-know-you-know.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kechogarcia-ctags-and-cscope-if-you-know-you-know.md
index 6e5a450..b6fe76a 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kechogarcia-ctags-and-cscope-if-you-know-you-know.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kechogarcia-ctags-and-cscope-if-you-know-you-know.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @kechogarcia
+**1/** **@kechogarcia** ^1786556130254094548
 
-@SebAaltonen
+**@SebAaltonen**
 
 ctags and cscope. If you know, you know. Unfortunately not many know how to use them.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kinjalkishor-why-one-would-waste-time-do-things-in-more-error.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kinjalkishor-why-one-would-waste-time-do-things-in-more-error.md
index 74e3735..1c0a08d 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kinjalkishor-why-one-would-waste-time-do-things-in-more-error.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kinjalkishor-why-one-would-waste-time-do-things-in-more-error.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @kinjalkishor
+**1/** **@kinjalkishor** ^1786607375253672156
 
-@SebAaltonen
+**@SebAaltonen**
 
 Why one would waste time & do things in more error prone ways, when good tools are available.
 Even best language will see very less adoption without good tools.
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-ok_devesh-legends-use-nano-or-vim-as-well.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-ok_devesh-legends-use-nano-or-vim-as-well.md
index 233fcd0..3636a45 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-ok_devesh-legends-use-nano-or-vim-as-well.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-ok_devesh-legends-use-nano-or-vim-as-well.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @ok_devesh
+**1/** **@ok_devesh** ^1786591865829015630
 
-@SebAaltonen
+**@SebAaltonen**
 
 Legends use nano or vim as well!
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-real7a-thread.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-real7a-thread.md
index eef37bf..7df2d78 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-real7a-thread.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-real7a-thread.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @real7a
+**1/** **@real7a** ^1786649667536613425
 
-@SebAaltonen
+**@SebAaltonen**
 
 :-)
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sagiritarius-using-codeblocks-instead-of-visual-studio-for.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sagiritarius-using-codeblocks-instead-of-visual-studio-for.md
index b974a40..12c2a49 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sagiritarius-using-codeblocks-instead-of-visual-studio-for.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sagiritarius-using-codeblocks-instead-of-visual-studio-for.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @sagiritarius
+**1/** **@sagiritarius** ^1786675436941959201
 
-@SebAaltonen
+**@SebAaltonen**
 
 Using CodeBlocks instead of Visual Studio for some time taught me that we created IntelliSense for a reason.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sean_of_w-i-know-a-lot-of-professionals-who-cant-code-at.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sean_of_w-i-know-a-lot-of-professionals-who-cant-code-at.md
index 3b08e7e..53a60c8 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sean_of_w-i-know-a-lot-of-professionals-who-cant-code-at.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sean_of_w-i-know-a-lot-of-professionals-who-cant-code-at.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @sean_of_w
+**1/** **@sean_of_w** ^1786752619983028462
 
-@SebAaltonen
+**@SebAaltonen**
 
 I know a lot of “professionals” who can’t code at all without an IDE, even on small projects. If you can’t work without it even at a low level of productivity, your ability to earn a living exists only at the whims of the IDE vendor. That’s one hell of a career risk.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-simplex_fx-you-should-be-able-to-program-on-paper-thats-what.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-simplex_fx-you-should-be-able-to-program-on-paper-thats-what.md
index 1d6e66f..bd847b2 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-simplex_fx-you-should-be-able-to-program-on-paper-thats-what.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-simplex_fx-you-should-be-able-to-program-on-paper-thats-what.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @simplex_fx
+**1/** **@simplex_fx** ^1786689811182452913
 
-@SebAaltonen
+**@SebAaltonen**
 
 You should be able to program on paper! 
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sylioning-ah-yes-high-school-memories-where-we-all-wrote.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sylioning-ah-yes-high-school-memories-where-we-all-wrote.md
index abfb5ec..5f08a80 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sylioning-ah-yes-high-school-memories-where-we-all-wrote.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sylioning-ah-yes-high-school-memories-where-we-all-wrote.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @sylioning
+**1/** **@sylioning** ^1786582180606730583
 
-@SebAaltonen
+**@SebAaltonen**
 
 Ah yes, high school memories where we all wrote HTML code in Notepad.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-xusifob-if-you-wouldnt-be-able-to-do-your-job-without-an.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-xusifob-if-you-wouldnt-be-able-to-do-your-job-without-an.md
index d5341eb..49b3823 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-xusifob-if-you-wouldnt-be-able-to-do-your-job-without-an.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-xusifob-if-you-wouldnt-be-able-to-do-your-job-without-an.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @xusifob
+**1/** **@xusifob** ^1786708701509800223
 
-@SebAaltonen
+**@SebAaltonen**
 
 If you wouldn't be able to do your job without an IDE there's a problem
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-joimboim-it-could-be-a-good-idea-to-start-without.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-joimboim-it-could-be-a-good-idea-to-start-without.md
index 53c0718..97950d6 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-joimboim-it-could-be-a-good-idea-to-start-without.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-joimboim-it-could-be-a-good-idea-to-start-without.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @joimboim
+**1/** **@joimboim** ^1787040804738895884
 
-@SebAaltonen
+**@SebAaltonen**
 
 It could be a good idea to start without intellisense. Just to learn and not get overwhelmed. It is also pretty distracting when it gets something wrong. 
 I mean there is no valid reason why someone shouldn't use it. But you should be able to make something without it, i guess.
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-ren_metal_n_dev-its-about-leveraging-the-tools-to-be-as.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-ren_metal_n_dev-its-about-leveraging-the-tools-to-be-as.md
index a26b41a..64b5d62 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-ren_metal_n_dev-its-about-leveraging-the-tools-to-be-as.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-ren_metal_n_dev-its-about-leveraging-the-tools-to-be-as.md
@@ -26,9 +26,9 @@ parent_post_id: "1786346729547153794"
 
 ## Branch
 
-**1/** @ren_metal_n_dev
+**1/** **@ren_metal_n_dev** ^1787076046405464324
 
-@SebAaltonen
+**@SebAaltonen**
 
 It’s about leveraging the tools to be as productive as possible. Who cares if you use an IDE. If someone on my team is dragging behind because of their tool choice on the other hand, that would be annoying.
 
diff --git a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/index.md b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/index.md
index e0f536b..e6c589b 100644
--- a/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/index.md
+++ b/archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/index.md
@@ -25,46 +25,46 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1786346729547153794
 
 Why should one be able to code without autocomplete and without a good IDE? I want to click on a symbol to find where it's defined and click on include file to go there, etc. And notepad doesn't have a debugger. I just don't get it. Why would anybody want to do that?
 
 Branches: [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-SebAaltonen-i-could-write-all-my-code-in-assembler-too-but]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-games_pants-i-had-that-at-an-interview-once-a-programming]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Enhex-because-high-arrogance-low-intelligence]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Lascif-people-have-a-superiority-complex-for-working-in]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-GumboatDiplomat-i-pretty-much-agree-with-you-but-i-started-using]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BugoTheCat-nothing-wrong-with-new-tools-its-just-that-most]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-sksauli-this]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CptCrabhands-you-should-write-your-code-on-paper-by-hand]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Kinker_0-theres-a-big-difference-between-being-able-to-and]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_benwick-the-key-word-is-able-how-many-people-cannot]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-lethal_guitar-its-like-telling-a-carpenter-you-should-be-able]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-i-wish-visual-studio-had-better-code-context]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-pepite2choc-its-not-about-wanting-its-about-being-able-to]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-AronThoughts-static-globals-defines-were-warm-members-blue]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-MacGyver1618-you-should-be-able-to-code-in-notepad-just-so-you]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Niko_sk2x-i-think-the-point-is-that-you-should-be-able-to]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-jmac_ai-the-meme-isnt-saying-you-shouldnt-use-it-its]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-mbc0der-should-be-able-to-doesnt-mean-prefer-to-its-just]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-WillGermany-i-was-once-interviewed-where-they-asked-me-to]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XBigand-i-start-to-consider-to-go-back-to-a-simple-text]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tuuveee-for-the-first-few-months-of-my-first-web]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ThePunkHucker-its-a-showcase-of-the-im-stronger-than-you]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-TechTolley-old-guys-trying-to-act-like-their-depreciating]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-atomlib-its-a-meme-from-a-person-who-posts-nothing-but]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ASupersay-who-cares-do-what-makes-you-happiest-and]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-bozoid-its-just-coder-bravado-to-show-off-toy-algorithms]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-OscarBR92-to-assert-dominance]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-heyotetsuo-use-whatever-you-want]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-KasperArnklit-gate-keeping-programming-and-thinking-it-makes]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ZoldenGames-some-people-feel-scared-to-give-up-lower-level]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-BenQett-the-only-good-faith-reply-is-if-youre-a-systems]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-leonpalafox-because-thats-how-we-learned-and-you-should-too]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-RatherSnideBun-that-is-just-another-it-twitter-bait-just-mute-or]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-_Felipe-blue-check-farming-engagement]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-unmodify-its-a-desire-to-appear-extraordinarily-competent]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-wrd83-i-would-agree-with-the-original-poster-you-should]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Natnew7-you-shouldnt-have-to-code-this-way-for-serious]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-redhog_org-no-need-to-do-that-but-to-be-able-to-if-unable]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-saarw-simple-editors-tend-to-lead-to-other-bad-choices]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-gregrthenson-i-once-was-in-an-interview-where-they-handed-me-a]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Floppie7th-cant-stand-ides-honestly-i-wouldnt-use-notepad]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Tankerbot-yeah-if-its-available-use-it-though-in-my-case-i]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-officiallyninja-i-think-there-is-some-value-in-this-at-least-for]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thr0wsException-its-obvious-engagement-farming-rage-bait-just]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-burlapDD-they-are-signaling-but-its-like-being-proud-of]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maessof91-it-makes-old-people-feel-cool-because-they-at]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-baris2c-its-bait]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ruch483-they-just-gaslight-themselves-that-their-broken]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-ytvizthex-hell-i-used-notepad-for-my-shitty-terraria-mods]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-XenoVoid112-you-shouldnt-actually-do-it-you-should-be-able-to]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Junts-as-a-kid-i-thought-coding-seemed-cool-and-wrote-a]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-frostyfrog-i-started-in-notepad-now-i-use-vim-for-all-my]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-h15panicatd-honestly-the-meme-works-infinitely-better-if-you]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Shrikanthabudya-chill-bro-its-an-engagement-bait]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-PurpleNinjaGrrl-nothing-has-more-forever-a-junior-level]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-IlyasHairline-to-flex-on-others]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-streetsofboston-folks-advocating-for-notepad-coding-is-much-like]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Naam_Hai_Bulla-major-disagree-especially-if-youre-learning-a-new]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-damianGray-you-should-be-able-to-code-with-punch-cards]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-theogramme_dev-to-prove-twitter-theyre-good-coders]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-dorithegreat128-you-should-be-able-to-it-shows-that-you]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-smurfpappa123-the-decel-mind-is-perplexing]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-DarthJahus-being-able-to-code-without-assistant-is-a-good]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-megaloid6-you-are-weak]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-NeutralRational-hes-a-boomer]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-CobraSwims-same-reason-some-large-corps-demand-that-we-have]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-Desxon1-still-remember-how-my-technical-school-assigned-a]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-fightuntil-real-programmers-use-a-magnetized-needle-and-a]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-virtuallyfun-because-i-dont-want-the-distractions-i-dont-want]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-foudre_tempete-tbf-intelisense-is-just-a-faster-way-of-finding]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-maisakal-you-are-an-intellisense-yourself-if-you-have-the]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-coolkoon-because-when-you-have-to-fix-something-on-a]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-03-thewillsykes-i-sort-of-agree-but-im-so-often-forced-to-code]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-JasonKn99664124-honestly-a-lot-of-the-framework-and-transpiler]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Ancients-there-is-an-argument-where-people-build-systems]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-AdmiralMemo-i-think-people-should-be-able-to-code-without]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kechogarcia-ctags-and-cscope-if-you-know-you-know]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sylioning-ah-yes-high-school-memories-where-we-all-wrote]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-ok_devesh-legends-use-nano-or-vim-as-well]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-fforw-you-never-know-when-a-time-machine-will-transport]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-kinjalkishor-why-one-would-waste-time-do-things-in-more-error]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-Matagi1996-its-not-like-you-should-only-code-without-support]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-codesonpaper-the-skill-issue-is-strong-with-this-one]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-FChapeau-its-gatekeeping-really-there-has-never-been-a]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-NohBody3-why-do-they-teach-arithmetic-we-all-have]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-real7a-thread]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-cpps93-i-learn-to-code-in-c-back-in-2011-and-my-teacher]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-bmarci7-i-would-say-you-should-code-in-a-way-that-is]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sagiritarius-using-codeblocks-instead-of-visual-studio-for]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-simplex_fx-you-should-be-able-to-program-on-paper-thats-what]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-xusifob-if-you-wouldnt-be-able-to-do-your-job-without-an]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-YohanOttie-people-will-justify-programming-c-c-on-linux-on]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-KlavsPeder-sometimes-we-are-limited-by-our-environment-which]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-RyanAlban1-not-notepad-but-i-have-done-a-non-zero-amount-of]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-CHChistris-i-guess-this-is-just-another-expression-of-the-if]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-sean_of_w-i-know-a-lot-of-professionals-who-cant-code-at]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-gengsterrebber-its-about-gatekeeping-and-feeling-superior]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-04-andokal-if-you-cant-code-tcl-using-vi-through-a-bash]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-joimboim-it-could-be-a-good-idea-to-start-without]], [[archive/threads/SebAaltonen/2024-05-03-why-should-one-be-able-to-code-without/2024-05-05-ren_metal_n_dev-its-about-leveraging-the-tools-to-be-as]]
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1786417122320523457
 
-@SebAaltonen
+**@SebAaltonen**
 
 i code in notepad2, i don't use debuggers, i don't create bugs, i don't use multiple files, the C code compiles faster than i can notice after saving the single file (via a shell script) ... why anyone wants the alternative insane code complexity, i'll never know
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1786417422838210652
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Works for hobby projects. But not for big work projects with 50+ people teams.
 
-**4/** @Nerfoxingaround
+**4/** **@Nerfoxingaround** ^1786544722762203505
 
-@SebAaltonen @NOTimothyLottes
+**@SebAaltonen** **@NOTimothyLottes**
 
 No. It works for low level projects regardless of the team size. This whole discussion is yet another case of programmers taking their work as religion or their personality. 
 
 I wouldn't handle stepper motors in C# and I wouldn't code games in assembler.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1786550199894102428
 
-@Nerfoxingaround @SebAaltonen
+**@Nerfoxingaround** **@SebAaltonen**
 
 Back in the day we would write everything, from the DOS extender (to 32bit mode) the sound blaster drivers, the VGA interface, etc, and the UI and audio synth and sequencer/editor ... all in assembly and it was dead easy, a lot easter than say bringing up a triangle in Vulkan.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1786551133416161720
 
-@Nerfoxingaround @SebAaltonen
+**@Nerfoxingaround** **@SebAaltonen**
 
 There is nothing complex or hard about assembly with a good macro preprocessor. It's easier IMO than high level languages because you know exactly what you get out of it. Interrupts and syscalls are easy.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1786551881504104518
 
-@Nerfoxingaround @SebAaltonen
+**@Nerfoxingaround** **@SebAaltonen**
 
 It was only later when systems forced C ABI library interfaces with it's stacks and junk that things got messy and only because of the C. Then C++ happened and things got much worse. Pure ASM is easy, its interfacing with the bloat world that got hard.
diff --git a/archive/threads/SebAaltonen/2024-12-18-fixed-all-our-vulkan-bugs/index.md b/archive/threads/SebAaltonen/2024-12-18-fixed-all-our-vulkan-bugs/index.md
index a68ddc9..6bafeab 100644
--- a/archive/threads/SebAaltonen/2024-12-18-fixed-all-our-vulkan-bugs/index.md
+++ b/archive/threads/SebAaltonen/2024-12-18-fixed-all-our-vulkan-bugs/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1869350790487523825
 
 Fixed all our Vulkan bugs:
 - ARM: BGR swapchain handled incorrectly (our bug)
@@ -37,6 +37,6 @@ Now we are ready to ship Vulkan for end users.
 
 ![](https://pbs.twimg.com/media/GfFDoE5XYAAprel?format=jpg&name=orig)
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1869361815454699648
 
 Our Vulkan backend has been in internal production for 1.5 years already. We were just waiting for Google to ship the Vulkan renderer on Flutter. We have a custom Flutter version that allows us to run our engine in the side. I carved holes to get their Vulkan device ptr, etc.
diff --git a/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/2025-03-08-NOTimothyLottes-actually-this-is-a-super-important-question-imo.md b/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/2025-03-08-NOTimothyLottes-actually-this-is-a-super-important-question-imo.md
index 978aae9..2ef8d4c 100644
--- a/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/2025-03-08-NOTimothyLottes-actually-this-is-a-super-important-question-imo.md
+++ b/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/2025-03-08-NOTimothyLottes-actually-this-is-a-super-important-question-imo.md
@@ -26,9 +26,9 @@ parent_post_id: "1898272635277967509"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1898352640825651644
 
-@SebAaltonen
+**@SebAaltonen**
 
 Actually this is a super important question IMO. 
 
@@ -38,208 +38,208 @@ opcodes have {6-bit wait barrier mask, 3-bit read barrier index, 3-bit write bar
 
 So don't need a u64 bitmask
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1898354182895145287
 
-@SebAaltonen
+**@SebAaltonen**
 
 AMD pre-GCN was a fixed TEX/ALU clause based arch. GCN went to their counter system (decade+ back). So there is a very long compiler & HW design technical debt inertia probably keeping the HW design on this counter based evolutionary tract
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1898355207085412488
 
-@SebAaltonen
+**@SebAaltonen**
 
 K$ loads are out of order, so the only counter that makes any sense is 0, ie waiting until all prior loads have finished.
 
 VMEM loads had traditionally been in-order only so counter made more sense. AMD's compiler would trickle-feed waits so tiny bits of VALU could move forward..
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1898355695017201734
 
-@SebAaltonen
+**@SebAaltonen**
 
 Vs say pre-GCN which was all-or-nothing. And vs NV which is all (for the mask of 6 barriers or nothing). So I think the counter design mixed with in-order VMEM was an attempt to reduce latency at the time
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1898356057782571048
 
-@SebAaltonen
+**@SebAaltonen**
 
 And also keep in mind TEX$ had traditionally been very small with respect to the number of clients (waves). So cacheline life was quite short, so in-order with counter like this might have had line-life benefits
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^1898356807229174069
 
-@SebAaltonen
+**@SebAaltonen**
 
 However in modern times TEX$ is bigger, and ALU issue is faster (compared to GCN's round robin wave64 on simd16). Also modern GPUs have operand caching. And trickle feeding waitcnts would break operand caching (more irregular switching to other waves) ...
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1898357381806850073
 
-@SebAaltonen
+**@SebAaltonen**
 
 And at the point where vector memory requests can go out-of-order (hit-under-miss, etc), counters are just legacy baggage that might not really make sense any more ...
 
-**8/** @NOTimothyLottes
+**8/** **@NOTimothyLottes** ^1898358090556211565
 
-@SebAaltonen
+**@SebAaltonen**
 
 Also the elephant in the room, dynamic wave scheduling. In theory with a chunky granularity design like NVIDIA, NVIDIA could build in hardware wave scheduling something that tries to keep waves at similar barriers! ->
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1898358611874549939
 
-@SebAaltonen
+**@SebAaltonen**
 
 -> Meaning better uniform forward progress of groups of waves. Trying to keep higher cache reuse. Where as AMD oldest first does allow the older wave(s) to get extremely out-of-sync with possible cache reuse across waves
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1898359204911448387
 
-@SebAaltonen
+**@SebAaltonen**
 
 On AMD I've always wanted to try to play with waitcnt placement for better dynamic scheduling (chunky vs fine-granularity, etc) BUT AMD refuses to ever allow ASM shaders in CS VK (even though ROCm supports ASM shaders without VK) ->
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1898360479778545879
 
-@SebAaltonen
+**@SebAaltonen**
 
 I do know traditionally that AMD often has a lot of trouble getting to 100% utilization of ALU-bound stuff. Typically sitting in the low 90%s instead, all due to wave scheduling (oldest first VALU base camping, preventing other waves to get VMEM issue out = bubbles) ->
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1898361569982984570
 
-@SebAaltonen
+**@SebAaltonen**
 
 AMD also wouldn't provide any access to s_setprio via intrinsics. So the two most important scheduling tools {waitcnt placement/grouping,setprio} are simply non-accessible to us "idiots" (who could never actually responsibly use intrinsics)
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1898362253230903368
 
-@SebAaltonen
+**@SebAaltonen**
 
 So what we actually do on AMD, is to do semi-persistent (or fully persistent) waves that instead of exiting, loop through groups of work instead. And this can sometimes actually fix HW scheduling issues by depending on oldest-first schedule behavior ->
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1898362581913411642
 
-@SebAaltonen
+**@SebAaltonen**
 
 Effectively the more scheduling one takes away from the dynamic HW scheduler and places instead into the static scheduling of a compiler, often seriously improves behavior by removing the worst case dynamic irregular behavior at runtime ->
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1898362900479094936
 
-@SebAaltonen
+**@SebAaltonen**
 
 I say "sometimes" because if you get out of I$ you hit perf death. And if the compiler explodes VGPR count then typically it can also be perf-death too
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1898363452063728020
 
-@SebAaltonen
+**@SebAaltonen**
 
 Historically the highest utilization stuff on AMD hardware would be 4-2 waves/SIMD actually [multiple work/wave] ... which will come to a surprise to UE material shader people who are dead in the water on performance at that wave count [single work/wave] ...
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1898364719573971083
 
-@SebAaltonen
+**@SebAaltonen**
 
 [IRONY] those who actually know what they are doing on AMD are fixed high-register-count low-wave-count persistent-wave folks with unrolling and static scheduling-focused (VS) the masses are lower-register-count high-wave-count non-persistent-wave dynamic-sched focused
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1898365132591247490
 
-@SebAaltonen
+**@SebAaltonen**
 
 One other point: in HW, how many waves should one actually keep live? The answer is only enough to reach high highest perf. But how does one build hardware to do that? With NVIDIA's design I think it is a lot easier, with the chunky barriers
 
-**19/** @SebAaltonen
+**19/** **@SebAaltonen** ^1898440015182729598
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I said WG_RR_EN (round-robin arbitration) in the RDNA4 ISA-docs, but no explanation. Wondering what this is.
 
-**20/** @NOTimothyLottes
+**20/** **@NOTimothyLottes** ^1898448182566076787
 
-@SebAaltonen
+**@SebAaltonen**
 
 I think it means oldest-workgroup first scheduling with round-robin scheduling across waves in the workgroups at the given workgroup priorities.
 
-**21/** @AgileJebrim
+**21/** **@AgileJebrim** ^1898365622955786473
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 What about losing shader occupancy and the latency-hiding benefits it provides for memory ops?
 
-**22/** @NOTimothyLottes
+**22/** **@NOTimothyLottes** ^1898366617559482567
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 The higher the occupancy the higher the clients on the caches = the lower the cache/client. So you never actually want highest occupancy, you want lowest occupancy that enables just enough latency hiding to keep highest utilization ...
 
-**23/** @NOTimothyLottes
+**23/** **@NOTimothyLottes** ^1898367105537306918
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 ... To be more detailed, what you really really want, is to keep the memory requests grouped by locality (for highest cache hit rate) and NO unnecessary bubbles in the memory request queues that would result in ALU stalling !!! - this is basic real-world supply chain management
 
-**24/** @AgileJebrim
+**24/** **@AgileJebrim** ^1898369377801581028
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 Now what if you want to reuse the same shared memory buffer for a larger workgroup rather than needlessly duplicating it with many smaller workgroups? Wouldn’t that be an argument for a larger workgroup size than 64,1,1?
 
-**25/** @NOTimothyLottes
+**25/** **@NOTimothyLottes** ^1898370376486236270
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 Right, that is the CU-sized workgroup. Something that takes over the full CU. That is one of the persistent-wave usage models. But a CU-sized workgroup for non-persistent work is perf-death, because of the idle time during workgroup barriers (horrible with oldest-wave sched)
 
-**26/** @AgileJebrim
+**26/** **@AgileJebrim** ^1898371880400163008
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 I’m not as well versed in AMD. 4 SIMDs per CU, so do 64x4 = 256 invocations per workgroup?
 
-**27/** @NOTimothyLottes
+**27/** **@NOTimothyLottes** ^1898374853507346826
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 That topic gets complex with RDNA: CU vs WGP mode, wave32 vs wave64, 8 vs 12 VGPRs per allocation granularity, etc
 
-**28/** @AgileJebrim
+**28/** **@AgileJebrim** ^1898378086829236447
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 Managed to get this info out of Grok.
 
 ![](https://pbs.twimg.com/media/GlhkzywXMAAQJQf?format=jpg&name=orig)
 
-**29/** @AgileJebrim
+**29/** **@AgileJebrim** ^1898379236173320496
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 Oh.
 
 ![](https://pbs.twimg.com/media/Glhl2ruXUAA1bhu?format=jpg&name=orig)
 
-**30/** @AgileJebrim
+**30/** **@AgileJebrim** ^1898379449038500054
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 Seems like just using 128 is a safe bet for most hardware?
 
-**31/** @NOTimothyLottes
+**31/** **@NOTimothyLottes** ^1898382213080605002
 
-@AgileJebrim @SebAaltonen
+**@AgileJebrim** **@SebAaltonen**
 
 Yeah safe bet like one-size-fits-all unisex underwear
 
-**32/** @AgileJebrim
+**32/** **@AgileJebrim** ^1898382509865382170
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 😆
 
-**33/** @AgileJebrim
+**33/** **@AgileJebrim** ^1898385745892495810
 
 On the flip side, it appears that using 128 would only use half the register file capacity on each. If we did 256 instead, then when the hardware scheduler became active, I imagine it’d only have a single choice to choose from for another thread to schedule and can use 255-256 registers each?
 
 ![](https://pbs.twimg.com/media/GlhrxYPWMAAAAY0?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/GlhrxYRXQAEamW5?format=jpg&name=orig)
 
-**34/** @AgileJebrim
+**34/** **@AgileJebrim** ^1898386242405834880
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 I’m imagining scheduler going back and forth between the same two SIMDs but dunno if such even distribution is what would actually happen in practice?
 
diff --git a/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/index.md b/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/index.md
index c454823..7b1010b 100644
--- a/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/index.md
+++ b/archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1898272635277967509
 
 Stupid hardware question: Why does AMD use several counters instead of one u64 bitmask for memory ops? 
 Each load/store would have a bit index and wait would have a bitmask (marked bits need to be set = finished).
@@ -34,10 +34,10 @@ Each load/store would have a bit index and wait would have a bitmask (marked bit
 
 Branches: [[archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/2025-03-08-NOTimothyLottes-actually-this-is-a-super-important-question-imo]]
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1898272964908359917
 
 I am glad that RDNA4 has separate counters for sampling (long latency) and lower latency raw loads now. That's a good improvement.
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1898280870462554297
 
 Some thoughts: Compiler managed bitfield slot indices would be iffy with loops and branches. One bit per register (big bitfield) would always work, but that would be much more than 64 bits. And wait instructions would be iffy (how to describe a massive bitfield).
diff --git a/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/2025-03-28-VoxelBoy-any-tips-or-existing-solutions-on-achieving.md b/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/2025-03-28-VoxelBoy-any-tips-or-existing-solutions-on-achieving.md
index 34992eb..361af28 100644
--- a/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/2025-03-28-VoxelBoy-any-tips-or-existing-solutions-on-achieving.md
+++ b/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/2025-03-28-VoxelBoy-any-tips-or-existing-solutions-on-achieving.md
@@ -26,81 +26,81 @@ parent_post_id: "1905523331496828964"
 
 ## Branch
 
-**1/** @VoxelBoy
+**1/** **@VoxelBoy** ^1905551799790006590
 
-@SebAaltonen
+**@SebAaltonen**
 
 Any tips or existing solutions on achieving something similar in Unity? (in terms of indoor lighting)
 
-**2/** @BenSimsTech
+**2/** **@BenSimsTech** ^1905565847059661090
 
-@VoxelBoy @SebAaltonen
+**@VoxelBoy** **@SebAaltonen**
 
 In Unity I do it this way: Custom EnvProbe component, capture gbuffer albedo normal and depth into cubemap on load. Pick 1 probe per frame and relight similar to deferred lighting using current sun/sky etc. Convolve to SH for diffuse and GGX for spec. Combine during deferred pass
 
-**3/** @BenSimsTech
+**3/** **@BenSimsTech** ^1905566465274892341
 
-@VoxelBoy @SebAaltonen
+**@VoxelBoy** **@SebAaltonen**
 
 This is a custom pipeline though. You'll need a decent amount of graphics code/shaders to get it working, will be very hard to retrofit into HDRP, might be feasible in URP/BiRP. I'm still working on it, may switch to octmaps instead of cubemaps. Unity is still very behind with GI
 
-**4/** @VoxelBoy
+**4/** **@VoxelBoy** ^1905573689317339393
 
-@BenSimsTech @SebAaltonen
+**@BenSimsTech** **@SebAaltonen**
 
 Also, with your custom render pipeline, how easy would you say it is to exceed URP performance if what’s being used are the most basic features such as Lit shader + lightmaps? Is there a lot of cruft in URP that causes overhead in your opinion?
 
-**5/** @BenSimsTech
+**5/** **@BenSimsTech** ^1905585393078251755
 
-@VoxelBoy @SebAaltonen
+**@VoxelBoy** **@SebAaltonen**
 
 URP is reasonably lightweight, depends what you're targeting though. For low-end mobile/mobile VR there's a few uneccessary copies/blits etc for things like color grading, depth reads, MSAA resolves etc. Lights are only culled on per-object basis which can waste performance too.
 
-**6/** @Alecazam123
+**6/** **@Alecazam123** ^1905622046685757524
 
-@BenSimsTech @VoxelBoy @SebAaltonen
+**@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 I don’t think msaa is worth it on TBDR.  Too much bandwidth shuffling tiles on/off.  And avoiding swapping out say depth is tough.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1905628963482825079
 
-@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen
+**@Alecazam123** **@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 MSAA+tiler makes sense if no post, assuming one does inline 4 sample tonemap before box summation (HW resolve). Have to super sample alpha test and set coverage mask, and super-sample depth for soft particle blend. Neither should require depth export if HW is good
 
-**8/** @Alecazam123
+**8/** **@Alecazam123** ^1905629412651139223
 
-@NOTimothyLottes @BenSimsTech @VoxelBoy @SebAaltonen
+**@NOTimothyLottes** **@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 Gpu occlusion needs hierZ.  Just not worth it IMHO.
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1905637476334469247
 
-@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen
+**@Alecazam123** **@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 Good HW in theory with wave ops on a full-screen triangle could read the MSAA depth and do an inline down-sample for the wave tile without ever needing to export MSAA depth, hierZ done with last frame's reduced depth and speculation should work for HZB occlusion
 
-**10/** @NOTimothyLottes
+**10/** **@NOTimothyLottes** ^1905638036160811329
 
-@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen
+**@Alecazam123** **@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 On a tiler you don't do mid-frame readback feeding any kind of geometry because the tiler geo passes are too latent (do all VS for the view for tile chunking, then PS)
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1905638813818372537
 
-@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen
+**@Alecazam123** **@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 The MSAA alternative I was pushing for at Unity for "general purpose" deferred g-buffer stuff was 1:2x2 nearest scaling mixed with 8x area STP (scaling-TAA), and hopefully eventually CS based index culling (to keep triangle, and thus chucker DRAM round trip bandwidth low)
 
-**12/** @Alecazam123
+**12/** **@Alecazam123** ^1905640027402764799
 
-@NOTimothyLottes @BenSimsTech @VoxelBoy @SebAaltonen
+**@NOTimothyLottes** **@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 Still a lot of limitations on depth/stencil and color msaa resolves and iOS.  Hw only has it all around A13.  Nice sample shaders for tonemap prior to resolve.   Still think TAA is the most flexible/affordable.   Plus msaa lowers tile size from 32x32@1x to 16x16@4x.
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1905642771387457570
 
-@Alecazam123 @BenSimsTech @VoxelBoy @SebAaltonen
+**@Alecazam123** **@BenSimsTech** **@VoxelBoy** **@SebAaltonen**
 
 MSAA/TAA doesn't change the problem with mid-frame CPU read back. Id still probably go with a mix of vintage precomputed clustered visibility (ratchet and clank style) and model LOD for the static geo of a tri based mobile engine
 
diff --git a/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/index.md b/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/index.md
index 20b96f9..dcabb76 100644
--- a/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/index.md
+++ b/archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1905523331496828964
 
 Indoor scenes in HypeHype are starting to look acceptable. This has no baked lighting. Only a single oct-map (conv.mips) for indirect specular and diffuse, masked with screen space AO (GTAO). No sunlight and no local lights (local lights are coming in a few months).
 
@@ -35,15 +35,15 @@ Game by Allu
 
 Branches: [[archive/threads/SebAaltonen/2025-03-28-indoor-scenes-in-hypehype-are-starting-to-look/2025-03-28-VoxelBoy-any-tips-or-existing-solutions-on-achieving]]
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1905523791322649077
 
 We just shipped textures. This game is using older "pixart" assets only, which allows you to put diffuse-only textures in sprites. The ground and walls are 3d sprites in this game. The new material system allows full PBR texture sets (diffuse, normal, roughness, metallic, AO).
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1905524218160132165
 
 Local light system is shipping before summer. This will be a big improvement for indoor game visual quality. Direct lighting is important, especially when you can't bake lightmaps. Our local lights also have shadows. One big texture atlas caches all local light shadow maps.
 
-**4/** @SebAaltonen
+**4/** **@SebAaltonen** ^1905524846559211822
 
 Example of a game textured with the new PBR material system:
 https://x.com/JohannesVuorine/status/1903305450969526504
@@ -52,9 +52,9 @@ Both games are running smoothly on dirt cheap <$99 phones with all the tech runn
 
 Game by @DanielPalmiArt
 
-**5/** @SebAaltonen
+**5/** **@SebAaltonen** ^1905527913341972664
 
-@DanielPalmiArt
+**@DanielPalmiArt**
 
 Old HypeHype indoor pictures before we landed screen space AO (GTAO) and oct-map indirect lighting. Old version had gradient based indirect lighting. Gradient is bad for indoors, since all wall normals face to horizon direction == same gradient color. And shadow masks sun out.
 
@@ -62,9 +62,9 @@ Old HypeHype indoor pictures before we landed screen space AO (GTAO) and oct-map
 ![](https://pbs.twimg.com/media/GnHLO2zXEAAhygZ?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/GnHLQDVXEAAmBJ6?format=jpg&name=orig)
 
-**6/** @SebAaltonen
+**6/** **@SebAaltonen** ^1905531104720724016
 
-@DanielPalmiArt
+**@DanielPalmiArt**
 
 Exactly one-year-old build versus the latest build. Quite a massive improvement in one year in visuals.
 
diff --git a/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/2026-08-05-NOTimothyLottes-that-clause-based-arch-was-interesting-in-many.md b/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/2026-08-05-NOTimothyLottes-that-clause-based-arch-was-interesting-in-many.md
index 1e07caa..53558b5 100644
--- a/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/2026-08-05-NOTimothyLottes-that-clause-based-arch-was-interesting-in-many.md
+++ b/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/2026-08-05-NOTimothyLottes-that-clause-based-arch-was-interesting-in-many.md
@@ -26,39 +26,39 @@ parent_post_id: "2084985800836477433"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^2084996454175612983
 
-@Triang3l
+**@Triang3l**
 
 That clause based arch was interesting in many ways, mem clause articulates the boundary for write combining. Was also easy to engineer slow perf by fine granularity predication too.
 
-**2/** @Triang3l
+**2/** **@Triang3l** ^2084997747174764975
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 But what is even a memory clause when MEM_RAT is a control flow instruction, or did the GPU group consecutive MEM_RATs into an implicit "clause"? I also wonder when you can mix RAT and RAT_CACHELESS (the OpenCL compiler apparently just stops using DB at all if CB is ever needed).
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2085006802580652188
 
-@Triang3l
+**@Triang3l**
 
 My understanding is that youd need UNCACHED for both write and read. So wouldn’t be all that useful perf wise. My guess is the transition from MEM_EXPORT to MEM_RD (where youd do UNCACHED) implicitly waits for uncached write visibility.
 
-**4/** @Triang3l
+**4/** **@Triang3l** ^2085010581438845269
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Yeah, I really hope so… But I guess I should just look at D3D11/GL/CL shader dumps. So many scary things involved, like WAIT_ACK, and that mention of SCOption_R800_UAV_NONUAV_SYNC_WORKAROUND_BUG216513_1 in disassembly. Unless they just fall back to RAT NOP_RTN for all loads 🤷‍♂️
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2085012846862021052
 
-@Triang3l
+**@Triang3l**
 
 Haha oops, very foggy, sounds like it is explicit via WAIT_ACK, rather than implicit. Fees like the predecessor to s_waitcnt in many respects.
 
-**6/** @NOTimothyLottes
+**6/** **@NOTimothyLottes** ^2085015005095755954
 
-@Triang3l
+**@Triang3l**
 
 There are a lot of good cases to have the same memory bound as read and write simultaneously, but under an implicit contract of no r/w overlap for a given cache line . Then dont need uncached reads, but probly would need WAIT_ACK still if write order visibility matters.
 
diff --git a/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/index.md b/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/index.md
index b307a9c..d3223f8 100644
--- a/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/index.md
+++ b/archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @Triang3l
+**1/** **@Triang3l** ^2084985800836477433
 
 "writes … have write-only caches that are invalidated, and all update bits are sent to memory AT THE END OF A CLAUSE"
 
@@ -35,7 +35,7 @@ Far easier to list what makes sense in TeraScale compute shaders than what doesn
 
 Branches: [[archive/threads/Triang3l/2026-08-05-writes-have-write-only-caches-that-are/2026-08-05-NOTimothyLottes-that-clause-based-arch-was-interesting-in-many]]
 
-**2/** @Triang3l
+**2/** **@Triang3l** ^2084987573382824214
 
 A clause is a sequence of ALU, buffer/texture SRV fetch, or LDS/GDS instructions.
 
@@ -43,6 +43,6 @@ However, UAV writes are "control flow" export instructions outside clauses.
 
 But you can read from buffer UAVs via uncached SRVs (quicker), but what if you read in the first clause after the write?
 
-**3/** @Triang3l
+**3/** **@Triang3l** ^2084991034807750781
 
 (Though it's pretty pointless to read back the value just written to an SSBO, but with storage texel buffers that may be done for format conversion.)
diff --git a/archive/threads/VPCOMPRESSB/2025-11-10-im-not-familiar-with-your-problem/index.md b/archive/threads/VPCOMPRESSB/2025-11-10-im-not-familiar-with-your-problem/index.md
index 83ce588..daa71d8 100644
--- a/archive/threads/VPCOMPRESSB/2025-11-10-im-not-familiar-with-your-problem/index.md
+++ b/archive/threads/VPCOMPRESSB/2025-11-10-im-not-familiar-with-your-problem/index.md
@@ -27,8 +27,8 @@ in_reply_to: "1987733345628013014"
 
 ## Thread
 
-**1/** @VPCOMPRESSB
+**1/** **@VPCOMPRESSB** ^1987744335333622188
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 i'm not familiar with your problem.
diff --git a/archive/threads/VPCOMPRESSB/2025-11-20-no-tokens-and-no-asts/index.md b/archive/threads/VPCOMPRESSB/2025-11-20-no-tokens-and-no-asts/index.md
index d23d2a7..9d3b300 100644
--- a/archive/threads/VPCOMPRESSB/2025-11-20-no-tokens-and-no-asts/index.md
+++ b/archive/threads/VPCOMPRESSB/2025-11-20-no-tokens-and-no-asts/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @VPCOMPRESSB
+**1/** **@VPCOMPRESSB** ^1991383117571957052
 
 no Tokens and no ASTs. (easier because its Forth-like).
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xAgathosDaimon-the-real-crime-is-those-idiots-not-knowing-who.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xAgathosDaimon-the-real-crime-is-those-idiots-not-knowing-who.md
index fb292a6..ff822b0 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xAgathosDaimon-the-real-crime-is-those-idiots-not-knowing-who.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xAgathosDaimon-the-real-crime-is-those-idiots-not-knowing-who.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @0xAgathosDaimon
+**1/** **@0xAgathosDaimon** ^2073442728617365698
 
-@VictorTaelin
+**@VictorTaelin**
 
 the real crime is those idiots not knowing who you are or your work.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xbadface1-what-do-you-mean-by-arguments-to-recursion.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xbadface1-what-do-you-mean-by-arguments-to-recursion.md
index ece362a..7627fe4 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xbadface1-what-do-you-mean-by-arguments-to-recursion.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-0xbadface1-what-do-you-mean-by-arguments-to-recursion.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @0xbadface1
+**1/** **@0xbadface1** ^2073533148101526002
 
-@VictorTaelin
+**@VictorTaelin**
 
 What do you mean by arguments to recursion "decreasing"? ... that looks a bit too "specific" - is that just some layman description of something more general and rigorous?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-An0o0o0o0n-im-not-going-to-read-all-that-im-happy-for-you-or.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-An0o0o0o0n-im-not-going-to-read-all-that-im-happy-for-you-or.md
index 535830b..8a9e60d 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-An0o0o0o0n-im-not-going-to-read-all-that-im-happy-for-you-or.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-An0o0o0o0n-im-not-going-to-read-all-that-im-happy-for-you-or.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @An0o0o0o0n
+**1/** **@An0o0o0o0n** ^2073470021674680637
 
-@VictorTaelin
+**@VictorTaelin**
 
 Im not going to read all that, I'm happy for you or sorry that happened.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-AutorRecomienda-fable-simplemente-hizo-de-placa-base-pitando-para.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-AutorRecomienda-fable-simplemente-hizo-de-placa-base-pitando-para.md
index 66275b9..1bead40 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-AutorRecomienda-fable-simplemente-hizo-de-placa-base-pitando-para.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-AutorRecomienda-fable-simplemente-hizo-de-placa-base-pitando-para.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @AutorRecomienda
+**1/** **@AutorRecomienda** ^2073410146189877657
 
-@VictorTaelin
+**@VictorTaelin**
 
 Fable simplemente hizo de placa base pitando para avisar del error, pero la solución elegante y real requería a alguien al volante.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Court_Reinland-this-is-an-s-tier-post-1-it-proves-non-slop.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Court_Reinland-this-is-an-s-tier-post-1-it-proves-non-slop.md
index 4ec8144..e338700 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Court_Reinland-this-is-an-s-tier-post-1-it-proves-non-slop.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Court_Reinland-this-is-an-s-tier-post-1-it-proves-non-slop.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Court_Reinland
+**1/** **@Court_Reinland** ^2073552721316376790
 
-@VictorTaelin
+**@VictorTaelin**
 
 This is an S tier post! 1. It proves non-slop brained people exist 2. That they use this site successfully and it’s not all a bot minefield. 3. I don’t know what country you’re from but Happy American 4th! 🇺🇸
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ETazou-i-understood-5-but-i-still-enjoyed-it.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ETazou-i-understood-5-but-i-still-enjoyed-it.md
index 89edc3c..31651ed 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ETazou-i-understood-5-but-i-still-enjoyed-it.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ETazou-i-understood-5-but-i-still-enjoyed-it.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @ETazou
+**1/** **@ETazou** ^2073409444029854071
 
-@VictorTaelin
+**@VictorTaelin**
 
 i understood 5% but i still enjoyed it
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-EttoreMariotti-thanks.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-EttoreMariotti-thanks.md
index b4a0c75..73be315 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-EttoreMariotti-thanks.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-EttoreMariotti-thanks.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @EttoreMariotti
+**1/** **@EttoreMariotti** ^2073495200983302242
 
-@VictorTaelin
+**@VictorTaelin**
 
 Thanks
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Foxfire1st-you-speak-simply-into-a-mixed-space-where-most.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Foxfire1st-you-speak-simply-into-a-mixed-space-where-most.md
index da8d645..a2b46ee 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Foxfire1st-you-speak-simply-into-a-mixed-space-where-most.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Foxfire1st-you-speak-simply-into-a-mixed-space-where-most.md
@@ -26,7 +26,7 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Foxfire1st
+**1/** **@Foxfire1st** ^2073465262167277726
 
 You speak simply into a mixed space where most people including me are on the "application layer". Agents, orchestration systems, memory, coding scaffolding. You are way more upstream in the stack. So while I can't find a use case for my own projects I still find it interesting to read how you go about problems. The "how" is universal and can be re-applied to other areas. And the best "hows" come from people who are wrestling with the core of mathematics and logic. Just my 2 cents.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-IncidentNoodle-this-is-a-great-post-i-cant-pretend-that-i-really.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-IncidentNoodle-this-is-a-great-post-i-cant-pretend-that-i-really.md
index 5f547dc..891648b 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-IncidentNoodle-this-is-a-great-post-i-cant-pretend-that-i-really.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-IncidentNoodle-this-is-a-great-post-i-cant-pretend-that-i-really.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @IncidentNoodle
+**1/** **@IncidentNoodle** ^2073480465177305167
 
-@VictorTaelin
+**@VictorTaelin**
 
 This is a great post! I can’t pretend that I really get the math, but it’s obvious that you understand what you’re talking about.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Juanpinha11-i-never-thought-you-had-ai-psychosis-but-the-fact.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Juanpinha11-i-never-thought-you-had-ai-psychosis-but-the-fact.md
index 5f4ec4a..e475d62 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Juanpinha11-i-never-thought-you-had-ai-psychosis-but-the-fact.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Juanpinha11-i-never-thought-you-had-ai-psychosis-but-the-fact.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Juanpinha11
+**1/** **@Juanpinha11** ^2073471371234213962
 
-@VictorTaelin
+**@VictorTaelin**
 
 I never thought you had AI psychosis, but the fact that others thought so led to this wonderful explanation. It makes me want to learn more about Bend2.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kinch_ahoy-i-got-interested-in-bend-for-its-prosaic.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kinch_ahoy-i-got-interested-in-bend-for-its-prosaic.md
index fb5d853..7d0ba11 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kinch_ahoy-i-got-interested-in-bend-for-its-prosaic.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kinch_ahoy-i-got-interested-in-bend-for-its-prosaic.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Kinch_ahoy
+**1/** **@Kinch_ahoy** ^2073472046907158611
 
-@VictorTaelin
+**@VictorTaelin**
 
 I got interested in Bend for its prosaic capabilities. What’s the logic behind trying to make it a theorem prover? Language design should be a flight of fancy, so I approve, but I don’t think I’ve seen you write up why you are colliding these worlds.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kmmer11133-i-enjoyed-reading-this-post-i-think-that-what.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kmmer11133-i-enjoyed-reading-this-post-i-think-that-what.md
index fc0cd05..03b6dd5 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kmmer11133-i-enjoyed-reading-this-post-i-think-that-what.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Kmmer11133-i-enjoyed-reading-this-post-i-think-that-what.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Kmmer11133
+**1/** **@Kmmer11133** ^2073479163550241020
 
-@VictorTaelin
+**@VictorTaelin**
 
 I enjoyed reading this post. I think that what you're currently working on is the most profound and important thing next to AI. I believe that it will practically open the door to reaching kolmogorov complexity compression and as we all know:
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LeeeeeeeeeT_-i-once-implemented-a-type-checker-for.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LeeeeeeeeeT_-i-once-implemented-a-type-checker-for.md
index f25b8b2..fe491e2 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LeeeeeeeeeT_-i-once-implemented-a-type-checker-for.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LeeeeeeeeeT_-i-once-implemented-a-type-checker-for.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @LeeeeeeeeeT_
+**1/** **@LeeeeeeeeeT_** ^2073449105867620454
 
-@VictorTaelin
+**@VictorTaelin**
 
 i once implemented a type checker for impredicative MLTT. i then tried to reproduce hurkens' paradox (simplified girard's paradox) - my type checker got stuck in an infinite loop. so.. you couldn't prove false in it, it just never terminated
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LusciousPear-i-love-this-shit.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LusciousPear-i-love-this-shit.md
index bc37dcd..f11793d 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LusciousPear-i-love-this-shit.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-LusciousPear-i-love-this-shit.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @LusciousPear
+**1/** **@LusciousPear** ^2073478700960493612
 
-@VictorTaelin
+**@VictorTaelin**
 
 I love this shit
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MancerAI_-its-lonely-sometimes-eh-im-excited-about-your.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MancerAI_-its-lonely-sometimes-eh-im-excited-about-your.md
index a7e3ac0..115ba69 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MancerAI_-its-lonely-sometimes-eh-im-excited-about-your.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MancerAI_-its-lonely-sometimes-eh-im-excited-about-your.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @MancerAI_
+**1/** **@MancerAI_** ^2073410416667959304
 
-@VictorTaelin
+**@VictorTaelin**
 
 It's lonely sometimes eh? I'm excited about your stuff and love your posts but I don't know a lot about lambda calculus etc. Applications are amazing though
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MoisasADR-os-caras-acham-que-s-eles-s-o-superinteligentes.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MoisasADR-os-caras-acham-que-s-eles-s-o-superinteligentes.md
index 53913e1..9b8f12a 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MoisasADR-os-caras-acham-que-s-eles-s-o-superinteligentes.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-MoisasADR-os-caras-acham-que-s-eles-s-o-superinteligentes.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @MoisasADR
+**1/** **@MoisasADR** ^2073415831619355067
 
-@VictorTaelin
+**@VictorTaelin**
 
 os caras acham que só eles são superinteligentes mas não conseguem enxergar alem da bolha que ele mesmo se coloca entre os '' inteligentes '', que tipo de inteligência é essa ? é a vida de um engenheiro médio que trabalha em um lab de IA em SF kkkkk
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-NickChapmn-y-combinators-dont-have-valid-types-so-you-are.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-NickChapmn-y-combinators-dont-have-valid-types-so-you-are.md
index a12a1a1..de5ed15 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-NickChapmn-y-combinators-dont-have-valid-types-so-you-are.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-NickChapmn-y-combinators-dont-have-valid-types-so-you-are.md
@@ -26,27 +26,27 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @NickChapmn
+**1/** **@NickChapmn** ^2073408491403071954
 
-@VictorTaelin
+**@VictorTaelin**
 
 y-combinators don't have valid types, so you are safe from them in statically typed functional languages.
 
-**2/** @VictorTaelin
+**2/** **@VictorTaelin** ^2073418722497208598
 
-@NickChapmn
+**@NickChapmn**
 
 that's absolutely false. you can construct the Y-Combinator and even λf.f(f) λf.f(f) in Haskell, Rust, TypeScript, and so on, even though these are statically typed functional language, through paradoxes like the ones I mentioned above. non-terminating languages are inconsistent
 
-**3/** @NickChapmn
+**3/** **@NickChapmn** ^2073419432907714789
 
-@VictorTaelin
+**@VictorTaelin**
 
 Ok they are invalid if you don't allow recursive types
 
-**4/** @VictorTaelin
+**4/** **@VictorTaelin** ^2073419976497643792
 
-@NickChapmn
+**@NickChapmn**
 
 yes
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-impossibility-to-write-fast-interpreter-looks.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-impossibility-to-write-fast-interpreter-looks.md
index 86cad6f..0ccd1ca 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-impossibility-to-write-fast-interpreter-looks.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-impossibility-to-write-fast-interpreter-looks.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Pitometsu
+**1/** **@Pitometsu** ^2073536226678714478
 
-@VictorTaelin
+**@VictorTaelin**
 
 Impossibility to write *fast* interpreter looks like a hardware architecture or compiler issue, not the language expressive power problem.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-qtt-approach-for-this-is-very-elegant-indeed.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-qtt-approach-for-this-is-very-elegant-indeed.md
index 7771f41..d75d5ea 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-qtt-approach-for-this-is-very-elegant-indeed.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Pitometsu-qtt-approach-for-this-is-very-elegant-indeed.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Pitometsu
+**1/** **@Pitometsu** ^2073540037300412645
 
-@VictorTaelin
+**@VictorTaelin**
 
 QTT approach for this is very elegant indeed!
 Elegantly works in relevance setting as well.
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Rafa_Schwinger-no-i-prefer-the-previous-angry-rhetoric-pls.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Rafa_Schwinger-no-i-prefer-the-previous-angry-rhetoric-pls.md
index 2160f7c..52645f6 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Rafa_Schwinger-no-i-prefer-the-previous-angry-rhetoric-pls.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Rafa_Schwinger-no-i-prefer-the-previous-angry-rhetoric-pls.md
@@ -26,15 +26,15 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Rafa_Schwinger
+**1/** **@Rafa_Schwinger** ^2073407479824724353
 
-@VictorTaelin
+**@VictorTaelin**
 
 No, I prefer the previous angry rhetoric pls revert the edit
 
-**2/** @VictorTaelin
+**2/** **@VictorTaelin** ^2073408137512538550
 
-@Rafa_Schwinger
+**@Rafa_Schwinger**
 
 these are only for close followers, enjoy
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RealSchmebulog-sorry-im-not-very-technical-did-you-mean-ai-good.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RealSchmebulog-sorry-im-not-very-technical-did-you-mean-ai-good.md
index 3c08287..3df1acf 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RealSchmebulog-sorry-im-not-very-technical-did-you-mean-ai-good.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RealSchmebulog-sorry-im-not-very-technical-did-you-mean-ai-good.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @RealSchmebulog
+**1/** **@RealSchmebulog** ^2073446880684503444
 
-@VictorTaelin
+**@VictorTaelin**
 
 Sorry, im not very technical. Did you mean AI good or AI bad this time?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RizwanKhuharo-angry-ones-always-get-attention-on-internet.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RizwanKhuharo-angry-ones-always-get-attention-on-internet.md
index b443f27..9c9c60d 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RizwanKhuharo-angry-ones-always-get-attention-on-internet.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-RizwanKhuharo-angry-ones-always-get-attention-on-internet.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @RizwanKhuharo
+**1/** **@RizwanKhuharo** ^2073442806102929513
 
-@VictorTaelin
+**@VictorTaelin**
 
 angry one's always get attention on internet
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SdoGtnepreS-dont-let-them-get-you-down-they-can-barely-see.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SdoGtnepreS-dont-let-them-get-you-down-they-can-barely-see.md
index 65a08d0..68ad8fa 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SdoGtnepreS-dont-let-them-get-you-down-they-can-barely-see.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SdoGtnepreS-dont-let-them-get-you-down-they-can-barely-see.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @SdoGtnepreS
+**1/** **@SdoGtnepreS** ^2073456422826729966
 
-@VictorTaelin
+**@VictorTaelin**
 
 Don't let them get you down. They can barely see the now, much less the future.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SoritesMinor-keep-posting-and-ill-keep-reading-or-trying-to.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SoritesMinor-keep-posting-and-ill-keep-reading-or-trying-to.md
index 64c9c9b..cd74fcf 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SoritesMinor-keep-posting-and-ill-keep-reading-or-trying-to.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-SoritesMinor-keep-posting-and-ill-keep-reading-or-trying-to.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @SoritesMinor
+**1/** **@SoritesMinor** ^2073476545935462869
 
-@VictorTaelin
+**@VictorTaelin**
 
 Keep posting and I'll keep reading. Or trying to.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ThePremiseOfIt-theres-an-emergent-ai-psychosis-psychosis-in.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ThePremiseOfIt-theres-an-emergent-ai-psychosis-psychosis-in.md
index 3696dd7..6ccdfe6 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ThePremiseOfIt-theres-an-emergent-ai-psychosis-psychosis-in.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-ThePremiseOfIt-theres-an-emergent-ai-psychosis-psychosis-in.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @ThePremiseOfIt
+**1/** **@ThePremiseOfIt** ^2073410550831182269
 
-@VictorTaelin
+**@VictorTaelin**
 
 There's an emergent ai psychosis psychosis in which idiots can't understand what you're saying so they cry "AI psychosis." It's a good litmus test for someone's intelligence, imho. Twice someone has suggested I'm expressing AI psychosis, but it was a tell on them.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-TheeKruger-i-think-this-is-a-super-legible-digestible.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-TheeKruger-i-think-this-is-a-super-legible-digestible.md
index bf787cd..8e7ea5c 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-TheeKruger-i-think-this-is-a-super-legible-digestible.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-TheeKruger-i-think-this-is-a-super-legible-digestible.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @TheeKruger
+**1/** **@TheeKruger** ^2073542081390485648
 
-@VictorTaelin
+**@VictorTaelin**
 
 I think this is a super legible, digestible, accessible, and coherent take. Well said, exceptionally based.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Trevor62271128-i-cant-really-comprehend-what-bend2-will-be.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Trevor62271128-i-cant-really-comprehend-what-bend2-will-be.md
index 6395224..543ac6a 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Trevor62271128-i-cant-really-comprehend-what-bend2-will-be.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Trevor62271128-i-cant-really-comprehend-what-bend2-will-be.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Trevor62271128
+**1/** **@Trevor62271128** ^2073472387035660742
 
-@VictorTaelin
+**@VictorTaelin**
 
 I can't really comprehend what Bend2 will be useful for except helping to make bug free software. With AI constantly getting better and better that purpose sounds mundane to me now. However, I'm very interested to see what you come up with for symbolic AI.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Unblinking3Y3-bro-you-dont-hafta-grug-post-to-be-popular-with.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Unblinking3Y3-bro-you-dont-hafta-grug-post-to-be-popular-with.md
index 46f1227..2900906 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Unblinking3Y3-bro-you-dont-hafta-grug-post-to-be-popular-with.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-Unblinking3Y3-bro-you-dont-hafta-grug-post-to-be-popular-with.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Unblinking3Y3
+**1/** **@Unblinking3Y3** ^2073433103838728518
 
-@VictorTaelin
+**@VictorTaelin**
 
 Bro, you dont hafta Grug-post to be popular with the right people.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-VincentLejeune-the-more-ai-advances-the-more-we-need-very-high.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-VincentLejeune-the-more-ai-advances-the-more-we-need-very-high.md
index 4b72079..907fc44 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-VincentLejeune-the-more-ai-advances-the-more-we-need-very-high.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-VincentLejeune-the-more-ai-advances-the-more-we-need-very-high.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @VincentLejeune
+**1/** **@VincentLejeune** ^2073447766437585020
 
-@VictorTaelin
+**@VictorTaelin**
 
 The more AI advances, the more we need very high level experts in very very specialzed narrow fields, to check results ! ❤️
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-WayneBrown6922-i-began-following-you-when-i-scrolled-across-an.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-WayneBrown6922-i-began-following-you-when-i-scrolled-across-an.md
index 6bfe23a..8d55a63 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-WayneBrown6922-i-began-following-you-when-i-scrolled-across-an.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-WayneBrown6922-i-began-following-you-when-i-scrolled-across-an.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @WayneBrown6922
+**1/** **@WayneBrown6922** ^2073415777370382432
 
-@VictorTaelin
+**@VictorTaelin**
 
 I began following you when I scrolled across an image similar to that above, it is the highly technical stuff you post that I enjoy most. Just about everyone else in my timeline I have to "see fewer" but I'll search for yours. Keep up the amazing work, here for the long haul!
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-YgorIsm-texto-mt-bem-escrito-ficou-bem-mais-f-cil-de.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-YgorIsm-texto-mt-bem-escrito-ficou-bem-mais-f-cil-de.md
index 8fde313..1c8365d 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-YgorIsm-texto-mt-bem-escrito-ficou-bem-mais-f-cil-de.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-YgorIsm-texto-mt-bem-escrito-ficou-bem-mais-f-cil-de.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @YgorIsm
+**1/** **@YgorIsm** ^2073436243208114535
 
-@VictorTaelin
+**@VictorTaelin**
 
 Texto mt bem escrito, ficou bem mais fácil de entender os seus objetivos
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-adelbucetta-sometimes-the-problem-isnt-explaining-something.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-adelbucetta-sometimes-the-problem-isnt-explaining-something.md
index 44c1e34..9d97b76 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-adelbucetta-sometimes-the-problem-isnt-explaining-something.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-adelbucetta-sometimes-the-problem-isnt-explaining-something.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @adelbucetta
+**1/** **@adelbucetta** ^2073471127054364991
 
-@VictorTaelin
+**@VictorTaelin**
 
 sometimes the problem isn't explaining something that's hard for people to grasp, but rather getting people to admit when they don't get it
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-altansukhbatbay-high-quality-post.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-altansukhbatbay-high-quality-post.md
index 9426330..517eb45 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-altansukhbatbay-high-quality-post.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-altansukhbatbay-high-quality-post.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @altansukhbatbay
+**1/** **@altansukhbatbay** ^2073493266209690083
 
-@VictorTaelin
+**@VictorTaelin**
 
 high quality post!
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-anghel4d-im-a-big-fan-of-interaction-combinators-and-i.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-anghel4d-im-a-big-fan-of-interaction-combinators-and-i.md
index c5e9ad6..52ab207 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-anghel4d-im-a-big-fan-of-interaction-combinators-and-i.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-anghel4d-im-a-big-fan-of-interaction-combinators-and-i.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @anghel4d
+**1/** **@anghel4d** ^2073421838068191714
 
-@VictorTaelin
+**@VictorTaelin**
 
 I'm a big fan of Interaction Combinators and I hope you keep going. Git push your changes to bend sometime :p
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-billylevin-this-is-so-cool-and-inspiring-not-that-i.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-billylevin-this-is-so-cool-and-inspiring-not-that-i.md
index 761d9e0..2a99636 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-billylevin-this-is-so-cool-and-inspiring-not-that-i.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-billylevin-this-is-so-cool-and-inspiring-not-that-i.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @billylevin
+**1/** **@billylevin** ^2073418462626455984
 
-@VictorTaelin
+**@VictorTaelin**
 
 This is so cool and inspiring (not that I understand all of it; that’s part of what makes it inspiring!). I hope you won’t be dissuaded from posting this kind of thing if you want to in future. Many people (such as me who rarely engages with stuff on here) will be thankful!
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-carmim_13-adorei-ler-esse-post-timo-poder-ler-de-voc-essas.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-carmim_13-adorei-ler-esse-post-timo-poder-ler-de-voc-essas.md
index 10ae283..c372cfd 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-carmim_13-adorei-ler-esse-post-timo-poder-ler-de-voc-essas.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-carmim_13-adorei-ler-esse-post-timo-poder-ler-de-voc-essas.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @carmim_13
+**1/** **@carmim_13** ^2073461299040616534
 
-@VictorTaelin
+**@VictorTaelin**
 
 adorei ler esse post. é ótimo poder ler de você essas explicações. só uma pergunta. você diria que é *confortável* replicar o Mathlib do Lean para o Bend? acho o Bend muito interessante por conta do IC, acho a teoria elegante. mas, claro, gostaria que o Bend fosse bom em math.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-charlesthefool-do-people-not-study-lambda-calculus-in-college-or.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-charlesthefool-do-people-not-study-lambda-calculus-in-college-or.md
index 384db53..f19c45c 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-charlesthefool-do-people-not-study-lambda-calculus-in-college-or.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-charlesthefool-do-people-not-study-lambda-calculus-in-college-or.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @charlesthefool
+**1/** **@charlesthefool** ^2073522750782833148
 
-@VictorTaelin
+**@VictorTaelin**
 
 Do people not study lambda calculus in college or at any other point when looking into programming languages?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-dlbydq-these-guys-have-no-idea-what-theyre-talking-about.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-dlbydq-these-guys-have-no-idea-what-theyre-talking-about.md
index 6ee5c2a..7f0c144 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-dlbydq-these-guys-have-no-idea-what-theyre-talking-about.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-dlbydq-these-guys-have-no-idea-what-theyre-talking-about.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @dlbydq
+**1/** **@dlbydq** ^2073518518910484940
 
-@VictorTaelin
+**@VictorTaelin**
 
 these guys have no idea what they're talking about. I've enjoyed following your work
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-donalfellows-if-you-have-a-system-that-provably-must-terminate.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-donalfellows-if-you-have-a-system-that-provably-must-terminate.md
index 14df90b..75d4432 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-donalfellows-if-you-have-a-system-that-provably-must-terminate.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-donalfellows-if-you-have-a-system-that-provably-must-terminate.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @donalfellows
+**1/** **@donalfellows** ^2073475168328896550
 
-@VictorTaelin
+**@VictorTaelin**
 
 If you have a system that provably must terminate, what "interesting" statements are you unable to express? And what can only be stated in restricted form?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-esa_was_taken-is-another-good-example-this-is-happening-to-both.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-esa_was_taken-is-another-good-example-this-is-happening-to-both.md
index 9ec166a..2b81ab9 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-esa_was_taken-is-another-good-example-this-is-happening-to-both.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-esa_was_taken-is-another-good-example-this-is-happening-to-both.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @esa_was_taken
+**1/** **@esa_was_taken** ^2073467375505039462
 
-@VictorTaelin @tsotchke
+**@VictorTaelin** **@tsotchke**
 
 is another good example this is happening to. Both so on the frontier people start erroring out when they read it lmfao
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-fecklesstit-u-the-best-man-keep-it-up.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-fecklesstit-u-the-best-man-keep-it-up.md
index bc642c7..edd39db 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-fecklesstit-u-the-best-man-keep-it-up.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-fecklesstit-u-the-best-man-keep-it-up.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @fecklesstit
+**1/** **@fecklesstit** ^2073409487055016302
 
-@VictorTaelin
+**@VictorTaelin**
 
 U the best man, keep it up 💙
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-habibislop-this-is-a-very-naive-and-ignorant-question-but.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-habibislop-this-is-a-very-naive-and-ignorant-question-but.md
index c4d7c96..9546007 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-habibislop-this-is-a-very-naive-and-ignorant-question-but.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-habibislop-this-is-a-very-naive-and-ignorant-question-but.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @habibislop
+**1/** **@habibislop** ^2073457431036793335
 
-@VictorTaelin
+**@VictorTaelin**
 
 This is a very naive and ignorant question, but now that you've split Type into two sorts, is there anything that could be represented with both variants? and if so, what would happen if someone selected the wrong one for their use csse
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-iabom-sigh-true-brother-we-smart-people-are-alone-no.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-iabom-sigh-true-brother-we-smart-people-are-alone-no.md
index d3bae37..f2dff13 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-iabom-sigh-true-brother-we-smart-people-are-alone-no.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-iabom-sigh-true-brother-we-smart-people-are-alone-no.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @iabom
+**1/** **@iabom** ^2073443427635831052
 
-@VictorTaelin
+**@VictorTaelin**
 
 *sigh* true brother. We smart people are alone, no one gets us.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-itisnotsavio-one-question-does-bend-have-an-unscoped-lambda.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-itisnotsavio-one-question-does-bend-have-an-unscoped-lambda.md
index 0724207..aecf264 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-itisnotsavio-one-question-does-bend-have-an-unscoped-lambda.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-itisnotsavio-one-question-does-bend-have-an-unscoped-lambda.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @itisnotsavio
+**1/** **@itisnotsavio** ^2073467107937792311
 
-@VictorTaelin
+**@VictorTaelin**
 
 One question: does bend have an unscoped lambda?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kekmaomaster-taelin-ive-been-following-you-since-the-beginning.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kekmaomaster-taelin-ive-been-following-you-since-the-beginning.md
index c1bb107..998157f 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kekmaomaster-taelin-ive-been-following-you-since-the-beginning.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kekmaomaster-taelin-ive-been-following-you-since-the-beginning.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @kekmaomaster
+**1/** **@kekmaomaster** ^2073503384791912785
 
-@VictorTaelin
+**@VictorTaelin**
 
 Taelin I've been following you since the beginning: I think the problem is you need to aggressively position yourself and your program as a painkiller. People need to feel their pain ease as a result of formal + function discovery. You need the palantir-type deployed engineers.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kylemarieb-this-write-up-was-really-well-done-thank-you-for.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kylemarieb-this-write-up-was-really-well-done-thank-you-for.md
index c7206c9..22cd779 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kylemarieb-this-write-up-was-really-well-done-thank-you-for.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-kylemarieb-this-write-up-was-really-well-done-thank-you-for.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @kylemarieb
+**1/** **@kylemarieb** ^2073496231461142754
 
-@VictorTaelin
+**@VictorTaelin**
 
 This write up was really well done, thank you for taking the time to write it! Broke down the concepts well
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-marunarh-most-of-you-cant-understand-my-posts-of-course.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-marunarh-most-of-you-cant-understand-my-posts-of-course.md
index bc9c9fd..616675a 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-marunarh-most-of-you-cant-understand-my-posts-of-course.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-marunarh-most-of-you-cant-understand-my-posts-of-course.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @marunarh
+**1/** **@marunarh** ^2073431581864128568
 
-@VictorTaelin
+**@VictorTaelin**
 
 > most of you can’t understand my posts 
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mikejt4-youre-not-allowed-to-praise-fable-you-must-bag.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mikejt4-youre-not-allowed-to-praise-fable-you-must-bag.md
index b3f712d..990ae52 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mikejt4-youre-not-allowed-to-praise-fable-you-must-bag.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mikejt4-youre-not-allowed-to-praise-fable-you-must-bag.md
@@ -26,7 +26,7 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @mikejt4
+**1/** **@mikejt4** ^2073509336488501736
 
 You’re not allowed to praise Fable, you MUST bag everything on the internet 🤣 And god forbid you do anything genuinely impressive!
 I’ve found Fable excellent so far, it’s night and day compared to Opus… Opus stumbles along pretending to be competent, frequently getting canceled when I realise it’s doing something dumb again… Fable picked up the project, found a bunch of strategic issues, replanned, and got everything working rapidly!!
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-misterclayt0n-many-such-cases-https-x-com-misterclayt0n-status.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-misterclayt0n-many-such-cases-https-x-com-misterclayt0n-status.md
index 55859b9..b9e4f4d 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-misterclayt0n-many-such-cases-https-x-com-misterclayt0n-status.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-misterclayt0n-many-such-cases-https-x-com-misterclayt0n-status.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @misterclayt0n
+**1/** **@misterclayt0n** ^2073492023873581413
 
-@VictorTaelin
+**@VictorTaelin**
 
 many such cases
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mprado-loved-this-long-post-version-of-yours-you-should.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mprado-loved-this-long-post-version-of-yours-you-should.md
index 770834c..2756028 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mprado-loved-this-long-post-version-of-yours-you-should.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-mprado-loved-this-long-post-version-of-yours-you-should.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @mprado
+**1/** **@mprado** ^2073424030481174585
 
-@VictorTaelin
+**@VictorTaelin**
 
 Loved this long post version of yours. You should do this more often, where you break down a problem for people not familiar with your domain. Very fun read! Thanks
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-noam_yy-i-presume-the-issue-was-in-duplication-inside-0.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-noam_yy-i-presume-the-issue-was-in-duplication-inside-0.md
index 9270693..69d51c6 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-noam_yy-i-presume-the-issue-was-in-duplication-inside-0.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-noam_yy-i-presume-the-issue-was-in-duplication-inside-0.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @noam_yy
+**1/** **@noam_yy** ^2073488513618640943
 
-@VictorTaelin
+**@VictorTaelin**
 
 I presume the issue was in duplication inside 0-contexts?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-o1lo01ol1o-do-you-allow-for-non-termination-on-total.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-o1lo01ol1o-do-you-allow-for-non-termination-on-total.md
index d38608b..ed5367a 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-o1lo01ol1o-do-you-allow-for-non-termination-on-total.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-o1lo01ol1o-do-you-allow-for-non-termination-on-total.md
@@ -26,33 +26,33 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @o1lo01ol1o
+**1/** **@o1lo01ol1o** ^2073412350493753796
 
-@VictorTaelin
+**@VictorTaelin**
 
 Do you allow for non-termination on total functions on codata?
 
-**2/** @VictorTaelin
+**2/** **@VictorTaelin** ^2073413824141504595
 
-@o1lo01ol1o
+**@o1lo01ol1o**
 
 no codata yet :(
 
-**3/** @o1lo01ol1o
+**3/** **@o1lo01ol1o** ^2073419678639071503
 
-@VictorTaelin
+**@VictorTaelin**
 
 You just use really big counters for services?
 
-**4/** @VictorTaelin
+**4/** **@VictorTaelin** ^2073420589222559818
 
-@o1lo01ol1o
+**@o1lo01ol1o**
 
 ah, yes you could, but on V1 you'd just disable termination checking there. I don't think proving stuff about IO is a big demand, not a priority for V1. we can add support that later
 
-**5/** @o1lo01ol1o
+**5/** **@o1lo01ol1o** ^2073421257635250671
 
-@VictorTaelin
+**@VictorTaelin**
 
 Good
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-okiwano-im-curious-what-comes-after-bend2-bend3-or-are.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-okiwano-im-curious-what-comes-after-bend2-bend3-or-are.md
index bfc759b..5969cff 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-okiwano-im-curious-what-comes-after-bend2-bend3-or-are.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-okiwano-im-curious-what-comes-after-bend2-bend3-or-are.md
@@ -26,27 +26,27 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @okiwano
+**1/** **@okiwano** ^2073433180397302126
 
-@VictorTaelin
+**@VictorTaelin**
 
 I'm curious. What comes after Bend2? Bend3 or are you going to move onto smaller more personally satisfying projects after this?
 
-**2/** @VictorTaelin
+**2/** **@VictorTaelin** ^2073445519930634656
 
-@okiwano
+**@okiwano**
 
 on HOC, 100% focus on Symbolic AI research
 
-**3/** @Pitometsu
+**3/** **@Pitometsu** ^2073550595747619120
 
-@VictorTaelin @okiwano
+**@VictorTaelin** **@okiwano**
 
 Any possibility to join the party? 😅
 
-**4/** @VictorTaelin
+**4/** **@VictorTaelin** ^2073552983820775569
 
-@Pitometsu @okiwano
+**@Pitometsu** **@okiwano**
 
 yess
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-pakatanatakata-lemme-aske-gpt-for-translating-your-hieroglyph.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-pakatanatakata-lemme-aske-gpt-for-translating-your-hieroglyph.md
index ecd44d4..1c19010 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-pakatanatakata-lemme-aske-gpt-for-translating-your-hieroglyph.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-pakatanatakata-lemme-aske-gpt-for-translating-your-hieroglyph.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @pakatanatakata
+**1/** **@pakatanatakata** ^2073442800704663830
 
-@VictorTaelin
+**@VictorTaelin**
 
 Lemme aske gpt for translating 
 Your hieroglyph
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-qonundrai-man-i-love-what-ur-doing-keep-going-one-of-the.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-qonundrai-man-i-love-what-ur-doing-keep-going-one-of-the.md
index 5853192..a214765 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-qonundrai-man-i-love-what-ur-doing-keep-going-one-of-the.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-qonundrai-man-i-love-what-ur-doing-keep-going-one-of-the.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @qonundrai
+**1/** **@qonundrai** ^2073485219554824377
 
-@VictorTaelin
+**@VictorTaelin**
 
 man I love what ur doing, keep going! one of the few good uses of AI!
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-rom1504-very-cool-indeed-hard-but-important-to-pick-the.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-rom1504-very-cool-indeed-hard-but-important-to-pick-the.md
index 08ca25c..68402ba 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-rom1504-very-cool-indeed-hard-but-important-to-pick-the.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-rom1504-very-cool-indeed-hard-but-important-to-pick-the.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @rom1504
+**1/** **@rom1504** ^2073479001763725815
 
-@VictorTaelin
+**@VictorTaelin**
 
 Very cool. Indeed hard but important to pick the right line on what coding model do vs what you do. One way to think about it is what requires being able to see the consequences 10 years away of some design choices and keep those to yourself.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-taxilogiker-russel-antinomy.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-taxilogiker-russel-antinomy.md
index 1a1936e..638fad1 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-taxilogiker-russel-antinomy.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-taxilogiker-russel-antinomy.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @taxilogiker
+**1/** **@taxilogiker** ^2073420713172594789
 
-@VictorTaelin
+**@VictorTaelin**
 
 russel antinomy •_•
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-trinitotolukeno-karpathy-said-he-had-ai-psychosis-for-a-while-and.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-trinitotolukeno-karpathy-said-he-had-ai-psychosis-for-a-while-and.md
index f15edc9..221bac9 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-trinitotolukeno-karpathy-said-he-had-ai-psychosis-for-a-while-and.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-trinitotolukeno-karpathy-said-he-had-ai-psychosis-for-a-while-and.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @trinitotolukeno
+**1/** **@trinitotolukeno** ^2073427303116202352
 
-@VictorTaelin
+**@VictorTaelin**
 
 karpathy said he had AI psychosis for a while and everyone knows he's very competent
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-willyrgf-wow-thats-impressive-best-argument-on-the-quality.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-willyrgf-wow-thats-impressive-best-argument-on-the-quality.md
index 004ed90..fcbcda3 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-willyrgf-wow-thats-impressive-best-argument-on-the-quality.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-willyrgf-wow-thats-impressive-best-argument-on-the-quality.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @willyrgf
+**1/** **@willyrgf** ^2073411779737047420
 
-@VictorTaelin
+**@VictorTaelin**
 
 Wow, that's impressive! Best argument on the quality of Fable I have read by far.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-yacineMTB-its-not-how-many-likes-you-get-its-likes-from-who.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-yacineMTB-its-not-how-many-likes-you-get-its-likes-from-who.md
index 255e9d0..6dd267b 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-yacineMTB-its-not-how-many-likes-you-get-its-likes-from-who.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-yacineMTB-its-not-how-many-likes-you-get-its-likes-from-who.md
@@ -26,15 +26,15 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @yacineMTB
+**1/** **@yacineMTB** ^2073430827908690365
 
-@VictorTaelin
+**@VictorTaelin**
 
 It's not how many likes you get, it's likes from who that matter. Less likes from better people is my preference
 
-**2/** @VictorTaelin
+**2/** **@VictorTaelin** ^2073441705831874767
 
-@yacineMTB
+**@yacineMTB**
 
 true
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-zyansheep-in-my-language-im-trying-to-do-termination-by.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-zyansheep-in-my-language-im-trying-to-do-termination-by.md
index 7b124e7..6f15215 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-zyansheep-in-my-language-im-trying-to-do-termination-by.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-04-zyansheep-in-my-language-im-trying-to-do-termination-by.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @zyansheep
+**1/** **@zyansheep** ^2073451643010703546
 
-@VictorTaelin
+**@VictorTaelin**
 
 In my language I'm trying to do termination by proxy, I.e. if type checking terminates for a certain validated set of type predicates than the typed program should be guaranteed to not terminate. Thoughts on this strategy?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-IanCSU-sure-i-read-all-that.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-IanCSU-sure-i-read-all-that.md
index 8976971..93065ed 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-IanCSU-sure-i-read-all-that.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-IanCSU-sure-i-read-all-that.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @IanCSU
+**1/** **@IanCSU** ^2073570162427437168
 
-@VictorTaelin
+**@VictorTaelin**
 
 sure, I read all that
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-JaredC1728-quality-over-quantity.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-JaredC1728-quality-over-quantity.md
index d81d935..4ff5f7b 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-JaredC1728-quality-over-quantity.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-JaredC1728-quality-over-quantity.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @JaredC1728
+**1/** **@JaredC1728** ^2073867058010521962
 
-@VictorTaelin
+**@VictorTaelin**
 
 Quality over quantity.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-KleeneAlgebra-i-disagree-on-the-consistency-is-enough-to-do.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-KleeneAlgebra-i-disagree-on-the-consistency-is-enough-to-do.md
index 1a75e73..b29368e 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-KleeneAlgebra-i-disagree-on-the-consistency-is-enough-to-do.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-KleeneAlgebra-i-disagree-on-the-consistency-is-enough-to-do.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @KleeneAlgebra
+**1/** **@KleeneAlgebra** ^2073769031467766029
 
-@VictorTaelin
+**@VictorTaelin**
 
 I disagree on the consistency is enough to do mathematics, you can very weird stuff to MLTT like Nat iso Nat -> Nat and still be consistent. I would like to see you convincing a mathematician to do math in that system.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-MadisonP94618-it-was-easy-to-read-and-i-think-i-understood-most.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-MadisonP94618-it-was-easy-to-read-and-i-think-i-understood-most.md
index 0e3bff9..9100c35 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-MadisonP94618-it-was-easy-to-read-and-i-think-i-understood-most.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-MadisonP94618-it-was-easy-to-read-and-i-think-i-understood-most.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @MadisonP94618
+**1/** **@MadisonP94618** ^2073702157933518998
 
-@VictorTaelin
+**@VictorTaelin**
 
 It was easy to read and I think I understood most of it. 
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Orbiter777-fable-is-educated-c.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Orbiter777-fable-is-educated-c.md
index 170b6dd..b5a6737 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Orbiter777-fable-is-educated-c.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Orbiter777-fable-is-educated-c.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Orbiter777
+**1/** **@Orbiter777** ^2073653687386349760
 
-@VictorTaelin
+**@VictorTaelin**
 
 Fable is educated c
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Siggis_Man-this-is-the-antidote-i-found-to-ai-psychosis-i.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Siggis_Man-this-is-the-antidote-i-found-to-ai-psychosis-i.md
index c6fc7fc..6c46568 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Siggis_Man-this-is-the-antidote-i-found-to-ai-psychosis-i.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Siggis_Man-this-is-the-antidote-i-found-to-ai-psychosis-i.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Siggis_Man
+**1/** **@Siggis_Man** ^2073573831370039610
 
-@VictorTaelin
+**@VictorTaelin**
 
 > this is the antidote I found to AI psychosis. I call it "competency"
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SinghSwapneil-are-languages-built-on-bend-incapable-of.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SinghSwapneil-are-languages-built-on-bend-incapable-of.md
index 483bd68..d01196f 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SinghSwapneil-are-languages-built-on-bend-incapable-of.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SinghSwapneil-are-languages-built-on-bend-incapable-of.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @SinghSwapneil
+**1/** **@SinghSwapneil** ^2073606758073864493
 
-@VictorTaelin
+**@VictorTaelin**
 
 Are languages built on Bend incapable of representing “eval” then? And/or disallowed from looping possibly-infinitely based on an external signal?
 (In-practice both of those are useful operations to interface with reality outside the language VM)
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Snafxemp-loved-ur-rant-these-types-of-posts-deserves.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Snafxemp-loved-ur-rant-these-types-of-posts-deserves.md
index fe17883..14484cf 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Snafxemp-loved-ur-rant-these-types-of-posts-deserves.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-Snafxemp-loved-ur-rant-these-types-of-posts-deserves.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @Snafxemp
+**1/** **@Snafxemp** ^2073707455914328128
 
-@VictorTaelin
+**@VictorTaelin**
 
 loved ur rant. these types of posts deserves attention
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SteveMoraco-legend.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SteveMoraco-legend.md
index 220b413..28f931b 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SteveMoraco-legend.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-SteveMoraco-legend.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @SteveMoraco
+**1/** **@SteveMoraco** ^2073619689889022076
 
-@VictorTaelin
+**@VictorTaelin**
 
 Legend
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-_machi47-im-not-reading-all-that-but-damn-hope-it-works.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-_machi47-im-not-reading-all-that-but-damn-hope-it-works.md
index d626559..6ccc9ed 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-_machi47-im-not-reading-all-that-but-damn-hope-it-works.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-_machi47-im-not-reading-all-that-but-damn-hope-it-works.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @_machi47
+**1/** **@_machi47** ^2073557470350344216
 
-@VictorTaelin
+**@VictorTaelin**
 
 I’m not reading all that but damn hope it works out for ya
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-ant1m4tt3r-stupid-question-alert-in-bends-syntax-what-is-the.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-ant1m4tt3r-stupid-question-alert-in-bends-syntax-what-is-the.md
index 7da2e6a..1db6a3f 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-ant1m4tt3r-stupid-question-alert-in-bends-syntax-what-is-the.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-ant1m4tt3r-stupid-question-alert-in-bends-syntax-what-is-the.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @ant1m4tt3r
+**1/** **@ant1m4tt3r** ^2073770708182720952
 
-@VictorTaelin
+**@VictorTaelin**
 
 stupid question alert. in bends syntax, what is the difference between -> , ~> and +> ?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-bewajitolulope-feels-like-the-precise-symbolic-analogue-of.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-bewajitolulope-feels-like-the-precise-symbolic-analogue-of.md
index a27a003..c6c91df 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-bewajitolulope-feels-like-the-precise-symbolic-analogue-of.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-bewajitolulope-feels-like-the-precise-symbolic-analogue-of.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @bewajitolulope
+**1/** **@bewajitolulope** ^2073773777511444606
 
-@VictorTaelin
+**@VictorTaelin**
 
 Feels like the precise, symbolic analogue of implementing LLM guard rails that aren't too strict and aren't too lax.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-dan_tiema-i-didnt-expect-id-read-all-of-this-but-i-did-cant.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-dan_tiema-i-didnt-expect-id-read-all-of-this-but-i-did-cant.md
index 20ecb7e..3ffb2b8 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-dan_tiema-i-didnt-expect-id-read-all-of-this-but-i-did-cant.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-dan_tiema-i-didnt-expect-id-read-all-of-this-but-i-did-cant.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @dan_tiema
+**1/** **@dan_tiema** ^2073633607634092187
 
-@VictorTaelin
+**@VictorTaelin**
 
 i didn't expect i'd read all of this, but i did.....can't pretend i understand it, but i'm starting to get the picture.....
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-eshear-to-someone-who-doesnt-understand-the-actual.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-eshear-to-someone-who-doesnt-understand-the-actual.md
index 0e70fca..a733896 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-eshear-to-someone-who-doesnt-understand-the-actual.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-eshear-to-someone-who-doesnt-understand-the-actual.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @eshear
+**1/** **@eshear** ^2073637707084136919
 
-@VictorTaelin
+**@VictorTaelin**
 
 To someone who doesn’t understand the actual content, AI psychosis and expert use of AI to drive a breakthrough look the same (modulo institutional credentials). It’s not their fault, it’s literally impossible for them to tell the two cases apart.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-n3ovice-dont-try-to-market-yourself-youre-not-running-for.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-n3ovice-dont-try-to-market-yourself-youre-not-running-for.md
index 2109010..8586b67 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-n3ovice-dont-try-to-market-yourself-youre-not-running-for.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-n3ovice-dont-try-to-market-yourself-youre-not-running-for.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @n3ovice
+**1/** **@n3ovice** ^2073683342059622543
 
-@VictorTaelin
+**@VictorTaelin**
 
 Don't try to market yourself. You're not running for public office.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-nudistofdespair-you-gave-it-a-great-shot-thanks-for-an-engaging.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-nudistofdespair-you-gave-it-a-great-shot-thanks-for-an-engaging.md
index 7ed78de..826a96e 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-nudistofdespair-you-gave-it-a-great-shot-thanks-for-an-engaging.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-nudistofdespair-you-gave-it-a-great-shot-thanks-for-an-engaging.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @nudistofdespair
+**1/** **@nudistofdespair** ^2073747195916861445
 
-@VictorTaelin
+**@VictorTaelin**
 
 You gave it a great shot, thanks for an engaging read.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-phtn458-bro-keep-posting-like-you-do-one-day-well-have.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-phtn458-bro-keep-posting-like-you-do-one-day-well-have.md
index 0c24775..e896e09 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-phtn458-bro-keep-posting-like-you-do-one-day-well-have.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-phtn458-bro-keep-posting-like-you-do-one-day-well-have.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @phtn458
+**1/** **@phtn458** ^2073604241118446014
 
-@VictorTaelin
+**@VictorTaelin**
 
 Bro keep posting like you do. One day we'll have the courage to learn it
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-real_philogy-dont-you-want-to-be-able-to-copy-lambdas-though.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-real_philogy-dont-you-want-to-be-able-to-copy-lambdas-though.md
index e7826fb..c71cca0 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-real_philogy-dont-you-want-to-be-able-to-copy-lambdas-though.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-real_philogy-dont-you-want-to-be-able-to-copy-lambdas-though.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @real_philogy
+**1/** **@real_philogy** ^2073558721368576160
 
-@VictorTaelin
+**@VictorTaelin**
 
 don't you want to be able to copy lambdas though? Or how do you do a lot of the typical FP stuff if you can't pass around and copy functions as you otherwise would?
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-theodorvaryag-this-post-is-not-a-rebuttal-to-a-query-about-ai.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-theodorvaryag-this-post-is-not-a-rebuttal-to-a-query-about-ai.md
index f0cc349..3802a1e 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-theodorvaryag-this-post-is-not-a-rebuttal-to-a-query-about-ai.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-theodorvaryag-this-post-is-not-a-rebuttal-to-a-query-about-ai.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @theodorvaryag
+**1/** **@theodorvaryag** ^2073563133323477361
 
-@VictorTaelin
+**@VictorTaelin**
 
 this post is not a rebuttal to a query about ai psychosis regardless of the merits and robust technical details behind it
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-waefrebeorn-i-have-an-entire-math-proofs-section-in-my-maths.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-waefrebeorn-i-have-an-entire-math-proofs-section-in-my-maths.md
index b512fa1..9ebb2ce 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-waefrebeorn-i-have-an-entire-math-proofs-section-in-my-maths.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-05-waefrebeorn-i-have-an-entire-math-proofs-section-in-my-maths.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @waefrebeorn
+**1/** **@waefrebeorn** ^2073664245816758563
 
-@VictorTaelin
+**@VictorTaelin**
 
 i have an entire math proofs section in my maths repos
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-06-SGuergachi-hopefully-useful-data-point.md b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-06-SGuergachi-hopefully-useful-data-point.md
index 3e87eb8..60d55c5 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-06-SGuergachi-hopefully-useful-data-point.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/2026-07-06-SGuergachi-hopefully-useful-data-point.md
@@ -26,9 +26,9 @@ parent_post_id: "2073406569459368226"
 
 ## Branch
 
-**1/** @SGuergachi
+**1/** **@SGuergachi** ^2073924504544280752
 
-@VictorTaelin @Jonathan_Blow
+**@VictorTaelin** **@Jonathan_Blow**
 
 hopefully useful data point.
 
diff --git a/archive/threads/VictorTaelin/2026-07-04-sighs/index.md b/archive/threads/VictorTaelin/2026-07-04-sighs/index.md
index 7bf53c0..55639b4 100644
--- a/archive/threads/VictorTaelin/2026-07-04-sighs/index.md
+++ b/archive/threads/VictorTaelin/2026-07-04-sighs/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @VictorTaelin
+**1/** **@VictorTaelin** ^2073406569459368226
 
 *sighs*
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-0xlac-the-answers-to-op-install-a-plugin-on-top-of-vs.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-0xlac-the-answers-to-op-install-a-plugin-on-top-of-vs.md
index 20a587b..2e8b768 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-0xlac-the-answers-to-op-install-a-plugin-on-top-of-vs.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-0xlac-the-answers-to-op-install-a-plugin-on-top-of-vs.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @0xlac
+**1/** **@0xlac** ^1691197452387287041
 
-@cmuratori
+**@cmuratori**
 
 The answers to OP : install a plugin on  top of VS to make it work !
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-KDmitriy99-it-cant-even-ctrl-a-after-some-update-a-few.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-KDmitriy99-it-cant-even-ctrl-a-after-some-update-a-few.md
index 53160ef..b2a1365 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-KDmitriy99-it-cant-even-ctrl-a-after-some-update-a-few.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-KDmitriy99-it-cant-even-ctrl-a-after-some-update-a-few.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @KDmitriy99
+**1/** **@KDmitriy99** ^1691218906000629760
 
-@cmuratori
+**@cmuratori**
 
 It can't even Ctrl+A after some update a few monhts before, just the 2022 (VS2019 also got updates but didnot break like this).
 I swear they do this on purpose. There is no way that in the whole multi-gb product they just happened to disable Ctrl+A. There is no way.
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-Saniell_-funny-enough-when-you-write-oop-language-design.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-Saniell_-funny-enough-when-you-write-oop-language-design.md
index 8416ef1..c255a55 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-Saniell_-funny-enough-when-you-write-oop-language-design.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-Saniell_-funny-enough-when-you-write-oop-language-design.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @Saniell_
+**1/** **@Saniell_** ^1691193028046733312
 
-@cmuratori
+**@cmuratori**
 
 Funny enough when you write OOP, language design makes you think that you write less code by using virtual methods.
 Since those are in different files, individual files are small and nice to human brain. Especially compared to "dirty" switches
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TanishqSingla_-not-to-mention-how-modern-software-shamelessly.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TanishqSingla_-not-to-mention-how-modern-software-shamelessly.md
index 94b5925..60a15be 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TanishqSingla_-not-to-mention-how-modern-software-shamelessly.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TanishqSingla_-not-to-mention-how-modern-software-shamelessly.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @TanishqSingla_
+**1/** **@TanishqSingla_** ^1691205716722561027
 
-@cmuratori
+**@cmuratori**
 
 Not to mention how modern software shamelessly assumes the available resources, Many people still use low end laptops and the performance of most modern IDE/code editors are so sluggish and ultimately hurts the life of these machines more.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TheBuzzSaw-just-today-in-vs-2022-the-semantic-analyzer.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TheBuzzSaw-just-today-in-vs-2022-the-semantic-analyzer.md
index f9c4d0e..10a5cfe 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TheBuzzSaw-just-today-in-vs-2022-the-semantic-analyzer.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TheBuzzSaw-just-today-in-vs-2022-the-semantic-analyzer.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @TheBuzzSaw
+**1/** **@TheBuzzSaw** ^1691222152853491714
 
-@cmuratori
+**@cmuratori**
 
 Just today, in VS 2022, the semantic analyzer crashed on me.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-dmitriid-this-is-the-best-metaphor-not-ironically-also.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-dmitriid-this-is-the-best-metaphor-not-ironically-also.md
index 2070dc7..03b7166 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-dmitriid-this-is-the-best-metaphor-not-ironically-also.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-dmitriid-this-is-the-best-metaphor-not-ironically-also.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @dmitriid
+**1/** **@dmitriid** ^1691192339186782208
 
-@cmuratori
+**@cmuratori**
 
 This is the best metaphor (not ironically also about Microsoft) https://x.com/ocornut/status/1691052987605467137?s=20
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-matt_j2-my-approach-is-to-write-code-that-i-can-come-back.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-matt_j2-my-approach-is-to-write-code-that-i-can-come-back.md
index 3abe1cc..18203e5 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-matt_j2-my-approach-is-to-write-code-that-i-can-come-back.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-matt_j2-my-approach-is-to-write-code-that-i-can-come-back.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @matt_j2
+**1/** **@matt_j2** ^1691199889256931328
 
-@cmuratori
+**@cmuratori**
 
 My approach is to write code that I can come back to in a year or two and not want to throw my computer out the window.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-snlwtn-vs2022-on-mac-is-virtually-unusable.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-snlwtn-vs2022-on-mac-is-virtually-unusable.md
index 7d3c096..396d057 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-snlwtn-vs2022-on-mac-is-virtually-unusable.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-snlwtn-vs2022-on-mac-is-virtually-unusable.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @snlwtn
+**1/** **@snlwtn** ^1691200637424345088
 
-@cmuratori
+**@cmuratori**
 
 vs2022 on Mac is virtually unusable
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-t3chn01200-performance-is-a-feature-change-my-mind.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-t3chn01200-performance-is-a-feature-change-my-mind.md
index 1409d88..43a2303 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-t3chn01200-performance-is-a-feature-change-my-mind.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-t3chn01200-performance-is-a-feature-change-my-mind.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @t3chn01200
+**1/** **@t3chn01200** ^1691233618167787521
 
-@cmuratori
+**@cmuratori**
 
 Performance is a feature. Change my mind.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-00jknight-i-largely-consider-clean-code-to-mean-that-the.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-00jknight-i-largely-consider-clean-code-to-mean-that-the.md
index 7c88372..2705ab4 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-00jknight-i-largely-consider-clean-code-to-mean-that-the.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-00jknight-i-largely-consider-clean-code-to-mean-that-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @00jknight
+**1/** **@00jknight** ^1691261726421901312
 
-@cmuratori
+**@cmuratori**
 
 I largely consider 'clean code' to mean that the system enables new content and new designs to be created with low code - ideally all at the same level of abstraction. I design systems, tools and APIs for myself and for my team to be more efficient.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Bordonius-vscode-will-end-up-going-the-way-of-all-editors.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Bordonius-vscode-will-end-up-going-the-way-of-all-editors.md
index 38566c5..0f41fc6 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Bordonius-vscode-will-end-up-going-the-way-of-all-editors.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Bordonius-vscode-will-end-up-going-the-way-of-all-editors.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @Bordonius
+**1/** **@Bordonius** ^1691444543147704320
 
-@cmuratori
+**@cmuratori**
 
 VSCode will end up going the way of all editors that aren't Vim or Emacs. Its legacy will be LSP.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-DefenceForceOrg-i-do-have-both-vs2022-and-vs2019-on-my-machine.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-DefenceForceOrg-i-do-have-both-vs2022-and-vs2019-on-my-machine.md
index 9af3f9e..86a618d 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-DefenceForceOrg-i-do-have-both-vs2022-and-vs2019-on-my-machine.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-DefenceForceOrg-i-do-have-both-vs2022-and-vs2019-on-my-machine.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @DefenceForceOrg
+**1/** **@DefenceForceOrg** ^1691343173077946369
 
-@cmuratori
+**@cmuratori**
 
 I do have both VS2022 and VS2019 on my machine, but I tend to use 2019 as the primary version.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-EduardKafe-developers-had-no-reason-to-uograde-their.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-EduardKafe-developers-had-no-reason-to-uograde-their.md
index 697bcff..3b0c8b5 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-EduardKafe-developers-had-no-reason-to-uograde-their.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-EduardKafe-developers-had-no-reason-to-uograde-their.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @EduardKafe
+**1/** **@EduardKafe** ^1691370830972772352
 
-@cmuratori
+**@cmuratori**
 
 Developers had no reason to uograde their machines every 6months so Microsoft gave them one
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Hannomalie1-does-more-code-automatically-mean-more-code-paths.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Hannomalie1-does-more-code-automatically-mean-more-code-paths.md
index c368660..019da4f 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Hannomalie1-does-more-code-automatically-mean-more-code-paths.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Hannomalie1-does-more-code-automatically-mean-more-code-paths.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @Hannomalie1
+**1/** **@Hannomalie1** ^1691483523385880576
 
-@cmuratori
+**@cmuratori**
 
 Does more code automatically mean more code paths? In the sense of different states your program can have? Or is it Just sth that is "typical".
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-enjoyingthewind-is-there-a-good-reason-to-use-vs-instead-of-vscode.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-enjoyingthewind-is-there-a-good-reason-to-use-vs-instead-of-vscode.md
index 99b4a68..89b9cb4 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-enjoyingthewind-is-there-a-good-reason-to-use-vs-instead-of-vscode.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-enjoyingthewind-is-there-a-good-reason-to-use-vs-instead-of-vscode.md
@@ -26,15 +26,15 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @enjoyingthewind
+**1/** **@enjoyingthewind** ^1691423123931873281
 
-@cmuratori
+**@cmuratori**
 
 Is there a good reason to use VS instead of VSCode?
 
-**2/** @cmuratori
+**2/** **@cmuratori** ^1691500513794338816
 
-@enjoyingthewind
+**@enjoyingthewind**
 
 I don't use either. Last time I looked at VSCode, it couldn't do assembly-level debugging, so that's one reason - but they may have fixed that.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-unclebobmartin-generally-speaking-thats-a-good-principle-but-its.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-unclebobmartin-generally-speaking-thats-a-good-principle-but-its.md
index cbaae71..a781cda 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-unclebobmartin-generally-speaking-thats-a-good-principle-but-its.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-unclebobmartin-generally-speaking-thats-a-good-principle-but-its.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @unclebobmartin
+**1/** **@unclebobmartin** ^1691407659923042304
 
-@cmuratori
+**@cmuratori**
 
 Generally speaking that’s a good principle. But it’s not an absolute. At some point reducing code volume starts to increase coupling. 
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-DavidBBlack-agree-completely-another-aspect-is-the-importance.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-DavidBBlack-agree-completely-another-aspect-is-the-importance.md
index 70cafdc..f6061fd 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-DavidBBlack-agree-completely-another-aspect-is-the-importance.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-DavidBBlack-agree-completely-another-aspect-is-the-importance.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @DavidBBlack
+**1/** **@DavidBBlack** ^1691859487638909212
 
-@cmuratori
+**@cmuratori**
 
 Agree completely.  Another aspect is the importance of eliminating redundancy.  Zero redundancy = minimal code = fast debugging and feature change. See https://www.blackliszt.com/occams-razor-occamality/
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-SamvStachelski-strange-never-had-that-problem-with-that-waaaay.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-SamvStachelski-strange-never-had-that-problem-with-that-waaaay.md
index 82708ad..62e5b56 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-SamvStachelski-strange-never-had-that-problem-with-that-waaaay.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-SamvStachelski-strange-never-had-that-problem-with-that-waaaay.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @SamvStachelski
+**1/** **@SamvStachelski** ^1691695743986524326
 
-@cmuratori
+**@cmuratori**
 
 Strange, never had that problem with that waaaay older editor, called  vim ;)
 (admittedly, LSPs can fail/lag/crash, but I can still code away, even with syntax highlighting :)
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-rudiservo-true-and-false-depends-on-the-project-and-the.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-rudiservo-true-and-false-depends-on-the-project-and-the.md
index 9d0de0c..356375a 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-rudiservo-true-and-false-depends-on-the-project-and-the.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-rudiservo-true-and-false-depends-on-the-project-and-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @rudiservo
+**1/** **@rudiservo** ^1691743453527294388
 
-@cmuratori
+**@cmuratori**
 
 True and false, depends on the project and the compiler.
 CPUs hate jumping around, so having a compiler like C that allows inline functions helps with that, if you try and do DRY in assembly, your program will be slow, sometimes to the extreme.
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-20-hasen_95dx-architecture-is-difficult-and-most-people-have-no.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-20-hasen_95dx-architecture-is-difficult-and-most-people-have-no.md
index d856f7e..dde5156 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-20-hasen_95dx-architecture-is-difficult-and-most-people-have-no.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-20-hasen_95dx-architecture-is-difficult-and-most-people-have-no.md
@@ -26,9 +26,9 @@ parent_post_id: "1691186899212472321"
 
 ## Branch
 
-**1/** @hasen_95dx
+**1/** **@hasen_95dx** ^1693179795423867063
 
-@cmuratori
+**@cmuratori**
 
 Architecture is difficult, and most people have no idea how to approach it.
 
diff --git a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/index.md b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/index.md
index f1de5d4..976a3eb 100644
--- a/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/index.md
+++ b/archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @cmuratori
+**1/** **@cmuratori** ^1691186899212472321
 
 Programming practices that increase total code volume lead to more bugs and less performance. It's not a tradeoff, it's a lose-lose. When you use significantly more code than is necessary to implement a feature, you provide an order of magnitude more code path combinations for bugs.
 
@@ -33,9 +33,9 @@ People think "delivering features" is somehow at odds with delivering reasonable
 
 Branches: [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-dmitriid-this-is-the-best-metaphor-not-ironically-also]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-Saniell_-funny-enough-when-you-write-oop-language-design]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-0xlac-the-answers-to-op-install-a-plugin-on-top-of-vs]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-matt_j2-my-approach-is-to-write-code-that-i-can-come-back]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-snlwtn-vs2022-on-mac-is-virtually-unusable]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TanishqSingla_-not-to-mention-how-modern-software-shamelessly]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-KDmitriy99-it-cant-even-ctrl-a-after-some-update-a-few]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-TheBuzzSaw-just-today-in-vs-2022-the-semantic-analyzer]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-14-t3chn01200-performance-is-a-feature-change-my-mind]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-00jknight-i-largely-consider-clean-code-to-mean-that-the]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-DefenceForceOrg-i-do-have-both-vs2022-and-vs2019-on-my-machine]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-EduardKafe-developers-had-no-reason-to-uograde-their]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-unclebobmartin-generally-speaking-thats-a-good-principle-but-its]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-enjoyingthewind-is-there-a-good-reason-to-use-vs-instead-of-vscode]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Bordonius-vscode-will-end-up-going-the-way-of-all-editors]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-15-Hannomalie1-does-more-code-automatically-mean-more-code-paths]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-SamvStachelski-strange-never-had-that-problem-with-that-waaaay]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-rudiservo-true-and-false-depends-on-the-project-and-the]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-16-DavidBBlack-agree-completely-another-aspect-is-the-importance]], [[archive/threads/cmuratori/2023-08-14-programming-practices-that-increase-total-code/2023-08-20-hasen_95dx-architecture-is-difficult-and-most-people-have-no]]
 
-**2/** @ExodusPgame
+**2/** **@ExodusPgame** ^1691191313599750144
 
-@cmuratori
+**@cmuratori**
 
 When I was into clean code and wrote code to be "future proof", what caused me to slowly snap out of it, was that adding new features became more and more difficult due of the code structure, which directly contradicted the promise.
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-abductee_org-asimov-vibes-intensify.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-abductee_org-asimov-vibes-intensify.md
index b479253..219cfc3 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-abductee_org-asimov-vibes-intensify.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-abductee_org-asimov-vibes-intensify.md
@@ -26,9 +26,9 @@ parent_post_id: "1650678968255913985"
 
 ## Branch
 
-**1/** @abductee_org
+**1/** **@abductee_org** ^1650685805776732160
 
-@kenpex
+**@kenpex**
 
 [Asimov vibes intensify]
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-streleav-indeed-any-thoughts-on-how-agi-could-help-the.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-streleav-indeed-any-thoughts-on-how-agi-could-help-the.md
index 243c4ce..888ee9a 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-streleav-indeed-any-thoughts-on-how-agi-could-help-the.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-streleav-indeed-any-thoughts-on-how-agi-could-help-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1650678968255913985"
 
 ## Branch
 
-**1/** @streleav
+**1/** **@streleav** ^1650915682136240129
 
-@kenpex
+**@kenpex**
 
 Indeed. Any thoughts on how AGI could help the situation?
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ChristerEricson-i-was-curious-about-what-it-would-take-to.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ChristerEricson-i-was-curious-about-what-it-would-take-to.md
index b433c57..8d0598d 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ChristerEricson-i-was-curious-about-what-it-would-take-to.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ChristerEricson-i-was-curious-about-what-it-would-take-to.md
@@ -26,9 +26,9 @@ parent_post_id: "1650678968255913985"
 
 ## Branch
 
-**1/** @ChristerEricson
+**1/** **@ChristerEricson** ^1651086935467917312
 
-@kenpex
+**@kenpex**
 
 I was curious about what it would take to recreate today’s tech “from scratch” if a giant EMP went off. It’s clearly a crazy number of bootstrap steps needed.
 
@@ -38,29 +38,29 @@ No EMPs pls!
 
 ![](https://pbs.twimg.com/media/FunW0KyaYAAPSv1?format=jpg&name=orig)
 
-**2/** @kenpex
+**2/** **@kenpex** ^1651254727160795137
 
-@ChristerEricson
+**@ChristerEricson**
 
 Reminds me of when people used/could to write engines from scratch at every new game/project. Perhaps it's the best way to improve though.
 
-**3/** @npatsiouras
+**3/** **@npatsiouras** ^1651508233243095043
 
-@kenpex @ChristerEricson
+**@kenpex** **@ChristerEricson**
 
 There's an anime series called 7 seeds, where civ ends due to predicted meteorite shower. Each gov selects a bunch of people based on their knowledge, including trained guides, in an attempt to repopulate earth in the aftermath.......and not one of them, knew Forth......amateurs!
 
-**4/** @ChristerEricson
+**4/** **@ChristerEricson** ^1651510424649744385
 
-@npatsiouras @kenpex
+**@npatsiouras** **@kenpex**
 
 Don’t get me wrong, I have fondness for Forth, but if my generation had grown up on Forth instead of Basic, I suspect this would be our world today.
 
 ![](https://pbs.twimg.com/media/FutX-exaMAAag8N?format=jpg&name=orig)
 
-**5/** @ChristerEricson
+**5/** **@ChristerEricson** ^1651511316010663936
 
-@npatsiouras @kenpex
+**@npatsiouras** **@kenpex**
 
 Also, it “almost” happened. One of my friends had one of these:
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ErikHaliewicz-this-is-actually-a-fantastic-project-though.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ErikHaliewicz-this-is-actually-a-fantastic-project-though.md
index 4f9a98f..9f7c3cc 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ErikHaliewicz-this-is-actually-a-fantastic-project-though.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ErikHaliewicz-this-is-actually-a-fantastic-project-though.md
@@ -26,9 +26,9 @@ parent_post_id: "1650678968255913985"
 
 ## Branch
 
-**1/** @ErikHaliewicz
+**1/** **@ErikHaliewicz** ^1651295755293036544
 
-@kenpex
+**@kenpex**
 
 This is actually a fantastic project though.
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-SebAaltonen-some-people-have-too-much-time-for-hobby-projects.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-SebAaltonen-some-people-have-too-much-time-for-hobby-projects.md
index 87b07b8..046b876 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-SebAaltonen-some-people-have-too-much-time-for-hobby-projects.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-SebAaltonen-some-people-have-too-much-time-for-hobby-projects.md
@@ -26,15 +26,15 @@ parent_post_id: "1650678968255913985"
 
 ## Branch
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1651168030557077504
 
-@kenpex
+**@kenpex**
 
 Some people have too much time for hobby projects.
 
-**2/** @HostOfMeta
+**2/** **@HostOfMeta** ^1651211621145141248
 
-@SebAaltonen @kenpex
+**@SebAaltonen** **@kenpex**
 
 Where else can someone learn Forth nowadays?
 
@@ -42,23 +42,23 @@ Would place Forth knowledge above C++ in an interview, shows an understanding of
 
 These are the people you want to help break tradition. They see the schlep, if you will.
 
-**3/** @kenpex
+**3/** **@kenpex** ^1651255723752579072
 
-@Lambda_Coder @SebAaltonen
+**@Lambda_Coder** **@SebAaltonen**
 
 I wouldn't. Forth today is hyper-niche, and even the programming model it teaches you about is. Lastly, the best way to learn forth is probably to make your own forth.
 
-**4/** @HostOfMeta
+**4/** **@HostOfMeta** ^1651257798708154368
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 What of the distinction between Forth the syntactic language and the semantic programming model?
 
 The way I see modern software, an insane amount of tooling and scaffolding is maintained to achieve what Forth and Lisp had emerging from their architecture. And usually not reusable
 
-**5/** @HostOfMeta
+**5/** **@HostOfMeta** ^1651258575749103620
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 The fact that the model is obscure should turn it into a superpower.
 
@@ -66,23 +66,23 @@ I'd agree for an existing company it would be a risk, but for a startup its how
 
 Not forth/lisp themselves, but adapting their models with modern hindsights.
 
-**6/** @kenpex
+**6/** **@kenpex** ^1651260967639212032
 
-@Lambda_Coder @SebAaltonen
+**@Lambda_Coder** **@SebAaltonen**
 
 I doubt it. I doubt that languages or paradigms make any difference in practice (never saw any study showing significant advantages). And the lisp paradigm is in my opinion, niche for reasonable reasons. In general, the lack of strong semantics is a liability, not a strength.
 
-**7/** @HostOfMeta
+**7/** **@HostOfMeta** ^1651263034470400001
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 What if there existed a way to get the live coding, programmable programming of Lisp/Forth, scale it to support AAA game engines, and keep most modern PLT developments in the process?
 
 I agree languages and paradigms are compile-time concerns and as such make the runtime complex.
 
-**8/** @HostOfMeta
+**8/** **@HostOfMeta** ^1651264420872437772
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 Its no different than a game engine moving from one scene to the next; a few layers of abstraction deeper.
 
@@ -90,36 +90,36 @@ Level designers would go insane having to reboot the editor between each change,
 
 I want this to change.
 
-**9/** @HostOfMeta
+**9/** **@HostOfMeta** ^1651264955033829377
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 I also appreciate how weird and niche this position is.
 
 It's one of these situations where the thing is already executing in my mind, but translating this to software and everyday terms is another story.
 
-**10/** @kenpex
+**10/** **@kenpex** ^1651453444274941952
 
-@Lambda_Coder @SebAaltonen
+**@Lambda_Coder** **@SebAaltonen**
 
 Live-coding is indeed (and provably so, there is science) a superpower, but does not have much to do with language semantics. It's tooling and "tradition". Lisps are usually VM-based, REPLs etc, but you can do that with C or whatever, and similarly, you can "offline" compile lisp
 
-**11/** @HostOfMeta
+**11/** **@HostOfMeta** ^1651572653302448128
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 I would say it's deeply connected to language design, in that doing it elsewhere is more complex and yields less power.
 Lisp has the most powerful REPL for this reason, but then it needs more semantic info to use it safely in a stateful simulation. Needs Erlang's supervision too.
 
-**12/** @HostOfMeta
+**12/** **@HostOfMeta** ^1651574497680535552
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 The runtime architecture I'm interested in keeps track of its systems, generates the wires between them, handles snapshots and replay logging from non-deterministic inputs, supervises and restores crashed systems and is aware of frame boundaries to know when live coding is safe.
 
-**13/** @HostOfMeta
+**13/** **@HostOfMeta** ^1651575451591090176
 
-@kenpex @SebAaltonen
+**@kenpex** **@SebAaltonen**
 
 Too often in Lisp I crash something at the REPL, or lose track of a connected socket, or whatever else happening which causes me to reboot the entire runtime tower, and I see every second waiting to get back to the previous state as wasted time where the mental context fades away
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-wadetb-i-find-the-context-hilarious-but-forth-as-asm.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-wadetb-i-find-the-context-hilarious-but-forth-as-asm.md
index c35024d..443730c 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-wadetb-i-find-the-context-hilarious-but-forth-as-asm.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-wadetb-i-find-the-context-hilarious-but-forth-as-asm.md
@@ -26,15 +26,15 @@ parent_post_id: "1650678968255913985"
 
 ## Branch
 
-**1/** @wadetb
+**1/** **@wadetb** ^1651056827839180800
 
-@kenpex
+**@kenpex**
 
 I find the context hilarious, but Forth as asm-level-yet-very-usable-mini-OS has been done, as the boot firmware for OLPC (http://laptop.org) for many years. Looks like it's currently open sourced as https://github.com/openbios/openbios.
 
-**2/** @kenpex
+**2/** **@kenpex** ^1651253961524142081
 
-@wadetb
+**@wadetb**
 
 Yes of course. Forth is a language that took me a while to grok (re:the why it makes sense) - but once I understood the context it totally does. @NOTimothyLottes experiments w/it are also fun.
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-27-JaceCear-the-what-if-were-in-an-apocalypse-part-is-very.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-27-JaceCear-the-what-if-were-in-an-apocalypse-part-is-very.md
index 591cbc6..cb31598 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-27-JaceCear-the-what-if-were-in-an-apocalypse-part-is-very.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-27-JaceCear-the-what-if-were-in-an-apocalypse-part-is-very.md
@@ -26,17 +26,17 @@ parent_post_id: "1650678968255913985"
 
 ## Branch
 
-**1/** @JaceCear
+**1/** **@JaceCear** ^1651579576089300992
 
-@kenpex
+**@kenpex**
 
 The "What if we're in an apocalypse?" part is very 'whatever' to me, but in general I find this and similar projects really cool!
 
 And it looks like the main dev creates it on a 75MHz Pentium, with 16MB of RAM, which is awesome! ^^
 
-**2/** @kenpex
+**2/** **@kenpex** ^1651636988267888641
 
-@JaceCear
+**@JaceCear**
 
 Of course, the grandfather of "cool OS - minus the crazy" is TempleOS
 
diff --git a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/index.md b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/index.md
index 29ca6ae..fb8c5a9 100644
--- a/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/index.md
+++ b/archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/index.md
@@ -25,32 +25,32 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @kenpex
+**1/** **@kenpex** ^1650678968255913985
 
 Nerds are crazy https://git.sr.ht/~vdupras/duskos
 
 Branches: [[archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-abductee_org-asimov-vibes-intensify]], [[archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-25-streleav-indeed-any-thoughts-on-how-agi-could-help-the]], [[archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ChristerEricson-i-was-curious-about-what-it-would-take-to]], [[archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-SebAaltonen-some-people-have-too-much-time-for-hobby-projects]], [[archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-26-ErikHaliewicz-this-is-actually-a-fantastic-project-though]], [[archive/threads/kenpex/2023-04-25-nerds-are-crazy-https-git-sr-ht-vdupras-duskos/2023-04-27-JaceCear-the-what-if-were-in-an-apocalypse-part-is-very]]
 
-**2/** @wadetb
+**2/** **@wadetb** ^1651056827839180800
 
-@kenpex
+**@kenpex**
 
 I find the context hilarious, but Forth as asm-level-yet-very-usable-mini-OS has been done, as the boot firmware for OLPC (http://laptop.org) for many years. Looks like it's currently open sourced as https://github.com/openbios/openbios.
 
-**3/** @kenpex
+**3/** **@kenpex** ^1651253961524142081
 
-@wadetb
+**@wadetb**
 
 Yes of course. Forth is a language that took me a while to grok (re:the why it makes sense) - but once I understood the context it totally does. @NOTimothyLottes experiments w/it are also fun.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1651268028795961344
 
-@kenpex @wadetb
+**@kenpex** **@wadetb**
 
 Can make a custom forth to binary in a few K. Bring up a runtime assembler in the language and do anything fast and simple from that point, load libraries, make system/dll C calls. 100,000x complexity reduction in compiler toolchain size.
 
-**5/** @wvo
+**5/** **@wvo** ^1651282559287042048
 
-@NOTimothyLottes @kenpex @wadetb
+**@NOTimothyLottes** **@kenpex** **@wadetb**
 
 A few K? Why not just 1K? https://strlen.com/false-language/
diff --git a/archive/threads/mmalex/2025-06-28-i-vibe-coded-something-horrendous-and-i-love-it-a/index.md b/archive/threads/mmalex/2025-06-28-i-vibe-coded-something-horrendous-and-i-love-it-a/index.md
index 35fd0db..44f7e61 100644
--- a/archive/threads/mmalex/2025-06-28-i-vibe-coded-something-horrendous-and-i-love-it-a/index.md
+++ b/archive/threads/mmalex/2025-06-28-i-vibe-coded-something-horrendous-and-i-love-it-a/index.md
@@ -25,24 +25,24 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @mmalex
+**1/** **@mmalex** ^1939051429060018590
 
 i vibe coded something horrendous and I love it: a python c preprocessor  that finds blocks like /* python <arbitrary python code> */ in a .c file, runs the python, and dumps the stdout after the comment, replacing any old block if needed. im using it to precompute tables...
 
-**2/** @seflless
+**2/** **@seflless** ^1939073216628068762
 
-@mmalex
+**@mmalex**
 
 There was a python tool for this remember as far back as 2000ish when working on a large c/c++ game codebase. Ah found it, it’s called Cog: https://cog.readthedocs.io/en/latest/
 
-**3/** @mmalex
+**3/** **@mmalex** ^1939097400183763189
 
-@seflless
+**@seflless**
 
 ah yes ! I knew it existed - it wasnt an original idea after all, but like a faint memory stirring in my brain - but couldn't find it. thanks for the link!
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1939170419958816855
 
-@mmalex @seflless
+**@mmalex** **@seflless**
 
 Many of my forth-like languages worked via nested runtime code gen, so it was possible to generate+run code to build either code or data, then repeat. The system would bootstrap its own assembler/etc that way.
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-AgileJebrim-the-answer-exists-its-called-ispc.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-AgileJebrim-the-answer-exists-its-called-ispc.md
index da97604..24f70f8 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-AgileJebrim-the-answer-exists-its-called-ispc.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-AgileJebrim-the-answer-exists-its-called-ispc.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @AgileJebrim
+**1/** **@AgileJebrim** ^1944947900104237129
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 The answer exists. It’s called ISPC.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-BigWhoopGames-reduced-instruction-sets-if-we-have-op-a-and-op-b.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-BigWhoopGames-reduced-instruction-sets-if-we-have-op-a-and-op-b.md
index 02d9ed6..19d1efe 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-BigWhoopGames-reduced-instruction-sets-if-we-have-op-a-and-op-b.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-BigWhoopGames-reduced-instruction-sets-if-we-have-op-a-and-op-b.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @BigWhoopGames
+**1/** **@BigWhoopGames** ^1945048842342219995
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Reduced instruction sets. If we have op A and op B but B can be expressed as a series of As, just get rid of it. If all the parallel cores need to be running the same op at the same time, just optimize for the least instructions possible but more of them in a row.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DanielJCollier-ispc.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DanielJCollier-ispc.md
index b217a5a..b53fd9e 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DanielJCollier-ispc.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DanielJCollier-ispc.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @DanielJCollier
+**1/** **@DanielJCollier** ^1945037474742591968
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 ISPC
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DeepknowledgeU-mojo-lang-has-simd-aware-data-types-and-makes-it.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DeepknowledgeU-mojo-lang-has-simd-aware-data-types-and-makes-it.md
index ab239fe..379ccbd 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DeepknowledgeU-mojo-lang-has-simd-aware-data-types-and-makes-it.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DeepknowledgeU-mojo-lang-has-simd-aware-data-types-and-makes-it.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @DeepknowledgeU
+**1/** **@DeepknowledgeU** ^1944996456974217322
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Mojo lang  has SIMD aware data types and makes it a first class citizen. Pretty interesting model
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Ed__dev-my-gamedev-head-just-wants-a-sort-of-game.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Ed__dev-my-gamedev-head-just-wants-a-sort-of-game.md
index 280453d..d71849a 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Ed__dev-my-gamedev-head-just-wants-a-sort-of-game.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Ed__dev-my-gamedev-head-just-wants-a-sort-of-game.md
@@ -26,7 +26,7 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @Ed__dev
+**1/** **@Ed__dev** ^1944930386984734925
 
 My gamedev head just wants a sort of game mechanic lego for conveying a simd operation frame. We have carts to give the operation rail and we'll have it vend us the result in the storage bin. All these bins are slices. Everything inside the rail could behave like a shader's frame where you're only allowed to-do simd ops...
 So far that I can tell if its in an iterator, the iterator is almost always going to be succeeded after this op occurs so it can be optionally incremented implicitly or manually.  
@@ -34,7 +34,7 @@ This may have been done already I haven't done that much studies on this.
 
 ![](https://pbs.twimg.com/media/Gv3H3-IWkAAmiVO?format=png&name=orig)
 
-**2/** @Ed__dev
+**2/** **@Ed__dev** ^1944933144714457233
 
 You could do more composition by having calls to procs, but it would be the async/await situation where now that proc must be a rail proc for the specific width. 
 All operations within the procs must end up being simd, but the slices from arbitrary pointers can come from any struct in memory.
@@ -45,13 +45,13 @@ All operations within the procs must end up being simd, but the slices from arbi
 
 ![](https://pbs.twimg.com/media/Gv3L4JqXAAA22Q4?format=png&name=orig)
 
-**4/** @Ed__dev
+**4/** **@Ed__dev** ^1944936495766294767
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 You could probably do mixin of different simd widths within one rail block but I don't know how that would start to get messy so maybe provide some sort of layout struct like the shaders to specify what the rail expects width wise for a set of bound vars.
 
-**5/** @Ed__dev
+**5/** **@Ed__dev** ^1944945740247392259
 
 The nuance is that I know I want to feed these things a very specific width for a range of ops during hot-paths in a pipeline of an program. Its annoying to deal with this width and striding it. Shaders deal with this concept for you to a great degree. These array data layouts for operating on this array data should all be specificable at comp-time so you just need a way to triage that to compositional definitions. Specifying them constantly for every single var's access to their elements is annoying and add complexity to parsing what's going on visually.
 
@@ -60,15 +60,15 @@ This would make the block scope's math data arrays look like shader math, becaus
 
 This is equivalent to what structs did for C on doing data offset math on single data instructions.
 
-**6/** @Ed__dev
+**6/** **@Ed__dev** ^1944947063931781184
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Figuring it out for simd will probably lead to systems langs being able to triage shader compilation and loading of those SPOs to the gpu in in the same lang syntax and you'd just have specific rules for compute, vertex, and frag shader railing blocks.
 
-**7/** @Ed__dev
+**7/** **@Ed__dev** ^1944997289308655624
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Last dumb example I'll muse about. Def would be fun to try prototyping something like this...
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JakeLegendXIII-i-have-hope-that-this-is-true-but-damn-have-we.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JakeLegendXIII-i-have-hope-that-this-is-true-but-damn-have-we.md
index b783d65..d856a04 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JakeLegendXIII-i-have-hope-that-this-is-true-but-damn-have-we.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JakeLegendXIII-i-have-hope-that-this-is-true-but-damn-have-we.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @JakeLegendXIII
+**1/** **@JakeLegendXIII** ^1944967041368129746
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I have hope that this is true. But damn have we tried and nobody has had a good answer so far. Hoping some of the AI distraction doesn’t take too much away from people still doing other computer science to make progress on actual programming.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JebsSteve0x1-ffmpeg-thinks-otherwise.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JebsSteve0x1-ffmpeg-thinks-otherwise.md
index fa8a658..ee2fad4 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JebsSteve0x1-ffmpeg-thinks-otherwise.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JebsSteve0x1-ffmpeg-thinks-otherwise.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @JebsSteve0x1
+**1/** **@JebsSteve0x1** ^1944937394127470633
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 FFmpeg thinks otherwise.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-SumErgoMonstro-have-you-ever-studied-apl-it-has-the-best-array.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-SumErgoMonstro-have-you-ever-studied-apl-it-has-the-best-array.md
index 055adc6..6a79abe 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-SumErgoMonstro-have-you-ever-studied-apl-it-has-the-best-array.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-SumErgoMonstro-have-you-ever-studied-apl-it-has-the-best-array.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @SumErgoMonstro
+**1/** **@SumErgoMonstro** ^1945143539224002588
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Have you ever studied APL?
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TGodfather1984-128-bit-seems-to-be-pretty-widespread-so-it-might.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TGodfather1984-128-bit-seems-to-be-pretty-widespread-so-it-might.md
index 98a47a3..02207f9 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TGodfather1984-128-bit-seems-to-be-pretty-widespread-so-it-might.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TGodfather1984-128-bit-seems-to-be-pretty-widespread-so-it-might.md
@@ -26,9 +26,9 @@ parent_post_id: "1944937375001666018"
 
 ## Branch
 
-**1/** @TGodfather1984
+**1/** **@TGodfather1984** ^1944994288305098754
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 128-bit seems to be pretty widespread, so it might be a good baseline? even in armv7 cores, not sure about risc-v and powerpc though. and then the compiler could just divide the number of iterations by 2 or 4, or am i missing something?
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TheBuzzSaw-c-makes-it-fairly-straightforward.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TheBuzzSaw-c-makes-it-fairly-straightforward.md
index 7ed78ea..a17401a 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TheBuzzSaw-c-makes-it-fairly-straightforward.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TheBuzzSaw-c-makes-it-fairly-straightforward.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @TheBuzzSaw
+**1/** **@TheBuzzSaw** ^1944927781512733078
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 C# makes it fairly straightforward.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-VPCOMPRESSB-intels-ispc.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-VPCOMPRESSB-intels-ispc.md
index 73bab7f..06d74c3 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-VPCOMPRESSB-intels-ispc.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-VPCOMPRESSB-intels-ispc.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @VPCOMPRESSB
+**1/** **@VPCOMPRESSB** ^1944933853707063570
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Intel's ISPC
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-WorldGhostC2C-llm-baked-into-gcc-whos-only-job-is-making-things.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-WorldGhostC2C-llm-baked-into-gcc-whos-only-job-is-making-things.md
index 0c1d72b..0a81f4c 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-WorldGhostC2C-llm-baked-into-gcc-whos-only-job-is-making-things.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-WorldGhostC2C-llm-baked-into-gcc-whos-only-job-is-making-things.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @WorldGhostC2C
+**1/** **@WorldGhostC2C** ^1944921404933120353
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Llm baked into gcc who’s only job is making things simd where possible. Sinple
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Zino2201_-perhaps-something-like-ispc-how-we-author-shaders.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Zino2201_-perhaps-something-like-ispc-how-we-author-shaders.md
index ff61547..ed600ab 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Zino2201_-perhaps-something-like-ispc-how-we-author-shaders.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Zino2201_-perhaps-something-like-ispc-how-we-author-shaders.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @Zino2201_
+**1/** **@Zino2201_** ^1945169506805952589
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Perhaps something like ISPC / how we author shaders in GPU could help ?
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-_Felipe-relational-model-columnar-data-sql-lands-itself.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-_Felipe-relational-model-columnar-data-sql-lands-itself.md
index 6213d8a..1e6d379 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-_Felipe-relational-model-columnar-data-sql-lands-itself.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-_Felipe-relational-model-columnar-data-sql-lands-itself.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @_Felipe
+**1/** **@_Felipe** ^1945156422716535136
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Relational model + columnar data. SQL lands itself very well to vectorization and scatter+gather algorithms. We need a general purpose language that can express SQL semantics in some places.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-__morse-languages-that-have-comptime-also-have-wonderful.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-__morse-languages-that-have-comptime-also-have-wonderful.md
index a333989..cb1d985 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-__morse-languages-that-have-comptime-also-have-wonderful.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-__morse-languages-that-have-comptime-also-have-wonderful.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @__morse
+**1/** **@__morse** ^1945235507954295160
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 languages that have comptime also have wonderful support for SIMD: mojo and zig
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-agmethod75-its-called-array-programming-fortran-has-been.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-agmethod75-its-called-array-programming-fortran-has-been.md
index 560bcf2..b710a5b 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-agmethod75-its-called-array-programming-fortran-has-been.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-agmethod75-its-called-array-programming-fortran-has-been.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @agmethod75
+**1/** **@agmethod75** ^1944929654340772147
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Its called array programming.  Fortran has been doing it since fortran90.  Odin and D have it.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-andrew_v10209-maybe-futhark-or-array-programming-theres-an.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-andrew_v10209-maybe-futhark-or-array-programming-theres-an.md
index 97f6f6c..8fc598f 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-andrew_v10209-maybe-futhark-or-array-programming-theres-an.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-andrew_v10209-maybe-futhark-or-array-programming-theres-an.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @andrew_v10209
+**1/** **@andrew_v10209** ^1944934680404389997
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Maybe Futhark, or array programming. There's an entire compiler that runs on the GPU written in Futhark (i.e. it does parsing, lexing, register allocation, etc on the GPU). It's called Pareas
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-another_sentry-https-github-com-higherorderco-bend.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-another_sentry-https-github-com-higherorderco-bend.md
index f71328a..e4a9b18 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-another_sentry-https-github-com-higherorderco-bend.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-another_sentry-https-github-com-higherorderco-bend.md
@@ -26,21 +26,21 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @another_sentry
+**1/** **@another_sentry** ^1944914198397624515
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 https://github.com/HigherOrderCO/Bend
 
-**2/** @nicbarkeragain
+**2/** **@nicbarkeragain** ^1944915365009744092
 
-@another_sentry
+**@another_sentry**
 
 I've been keeping an eye on this & the HVM work, there is some really interesting stuff happening there. My issue however is this doesn't feel like a general purpose language, more something that you would reach for if you already knew you had a massively parallel problem.
 
-**3/** @AgileJebrim
+**3/** **@AgileJebrim** ^1944948376086139203
 
-@nicbarkeragain @another_sentry
+**@nicbarkeragain** **@another_sentry**
 
 Not even. Their performance is atrocious and their recursive programming model doesn’t map well to GPUs.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-asdhuqiwuhdais-it-hasnt-been-stabilized-yet-but-rusts-portable.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-asdhuqiwuhdais-it-hasnt-been-stabilized-yet-but-rusts-portable.md
index 3599386..b1fa553 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-asdhuqiwuhdais-it-hasnt-been-stabilized-yet-but-rusts-portable.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-asdhuqiwuhdais-it-hasnt-been-stabilized-yet-but-rusts-portable.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @asdhuqiwuhdais
+**1/** **@asdhuqiwuhdais** ^1945222545709453526
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 It hasn't been stabilized yet but Rust's portable SIMD was pretty easy to work with https://doc.rust-lang.org/std/simd/index.html
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dezren39-more-arrays.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dezren39-more-arrays.md
index abc6d79..e683065 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dezren39-more-arrays.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dezren39-more-arrays.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @dezren39
+**1/** **@dezren39** ^1944982626667802713
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 more arrays
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dodobyte-openmp-does-good-enough-job-with-compiler-flags.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dodobyte-openmp-does-good-enough-job-with-compiler-flags.md
index 5cd6985..829f45f 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dodobyte-openmp-does-good-enough-job-with-compiler-flags.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dodobyte-openmp-does-good-enough-job-with-compiler-flags.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @dodobyte
+**1/** **@dodobyte** ^1945103550113054841
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 openmp does good enough job with compiler flags like march=avx2, i think the focus should be making compilers smarter, for the cases where parallelism is the primary concern one should use cuda
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etscrivner-i-think-ispc-more-or-less-solved-this-and-in-a-c.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etscrivner-i-think-ispc-more-or-less-solved-this-and-in-a-c.md
index fdc405c..612fa5f 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etscrivner-i-think-ispc-more-or-less-solved-this-and-in-a-c.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etscrivner-i-think-ispc-more-or-less-solved-this-and-in-a-c.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @etscrivner
+**1/** **@etscrivner** ^1944916196429848910
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I think ISPC more or less solved this and in a C-compatible way.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etzikun-might-be-an-oversimplification-but-i-think-the.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etzikun-might-be-an-oversimplification-but-i-think-the.md
index 5aeef0b..f6fa64c 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etzikun-might-be-an-oversimplification-but-i-think-the.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etzikun-might-be-an-oversimplification-but-i-think-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @etzikun
+**1/** **@etzikun** ^1944931271077249360
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Might be an oversimplification but I think the focus might need to be aimed more at grouping data efficiently. Thinking more with association rather than just individual variables. There’s only so much optimisation a compiler can force. It’s (partially) a memory management issue.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-examachine-possible.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-examachine-possible.md
index a3084ea..8dc6c28 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-examachine-possible.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-examachine-possible.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @examachine
+**1/** **@examachine** ^1944938026037338610
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Possible. :)
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-groby-so-fortran.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-groby-so-fortran.md
index acc5131..935005a 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-groby-so-fortran.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-groby-so-fortran.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @groby
+**1/** **@groby** ^1944979658778239333
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 So, FORTRAN?
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jon_roelofs-the-industry-is-trying-to-do-that-with-vector.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jon_roelofs-the-industry-is-trying-to-do-that-with-vector.md
index 85e67eb..2c02982 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jon_roelofs-the-industry-is-trying-to-do-that-with-vector.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jon_roelofs-the-industry-is-trying-to-do-that-with-vector.md
@@ -26,9 +26,9 @@ parent_post_id: "1944937375001666018"
 
 ## Branch
 
-**1/** @jon_roelofs
+**1/** **@jon_roelofs** ^1944944456056365486
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 the industry is trying to do that with vector-length-agnostic architectures, like SVE, RVV, and others.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jshurmer-i-agree.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jshurmer-i-agree.md
index 0bb2a57..b6027f0 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jshurmer-i-agree.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jshurmer-i-agree.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @jshurmer
+**1/** **@jshurmer** ^1944928429071053201
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I agree
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meglio-the-average-programmer-you-mentioned-uses-oop-and.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meglio-the-average-programmer-you-mentioned-uses-oop-and.md
index ca4d6f4..d819300 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meglio-the-average-programmer-you-mentioned-uses-oop-and.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meglio-the-average-programmer-you-mentioned-uses-oop-and.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @meglio
+**1/** **@meglio** ^1944957913279422515
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 The "average programmer" you mentioned uses OOP and other things that make their programs so slower and fatter that SIMD would make literally zero impact within that scale of inefficiency through bad programming practices. You are attacking the wrong problem.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meoyawn-mojo-has-a-first-class-simd-support-afaik-but-ive.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meoyawn-mojo-has-a-first-class-simd-support-afaik-but-ive.md
index 05b2955..7cbf169 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meoyawn-mojo-has-a-first-class-simd-support-afaik-but-ive.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meoyawn-mojo-has-a-first-class-simd-support-afaik-but-ive.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @meoyawn
+**1/** **@meoyawn** ^1945231466549363169
 
-@nicbarkeragain @Modular
+**@nicbarkeragain** **@Modular**
 
 Mojo has a first class SIMD support AFAIK but I've never used it https://docs.modular.com/mojo/stdlib/builtin/simd/SIMD#implemented-traits
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-quentinoeoeoe-i-agree-there-is-something-weird-with-simd.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-quentinoeoeoe-i-agree-there-is-something-weird-with-simd.md
index 16f2a47..b797068 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-quentinoeoeoe-i-agree-there-is-something-weird-with-simd.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-quentinoeoeoe-i-agree-there-is-something-weird-with-simd.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @quentinoeoeoe
+**1/** **@quentinoeoeoe** ^1944919638719987940
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I agree, there is something weird with SIMD accessibility today, looks like there is room for innovation
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-salonen-i-think-we-need-a-system-visualizer-where-devs.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-salonen-i-think-we-need-a-system-visualizer-where-devs.md
index faf0634..6fe236b 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-salonen-i-think-we-need-a-system-visualizer-where-devs.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-salonen-i-think-we-need-a-system-visualizer-where-devs.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @salonen
+**1/** **@salonen** ^1945116028540784694
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I think we need a system visualizer where devs can view their implementation running through the processor/gpus/memory/network.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sasuke___420-have-you-spent-time-writing-simd-algorithms-for.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sasuke___420-have-you-spent-time-writing-simd-algorithms-for.md
index 289571e..79adcce 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sasuke___420-have-you-spent-time-writing-simd-algorithms-for.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sasuke___420-have-you-spent-time-writing-simd-algorithms-for.md
@@ -26,33 +26,33 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @sasuke___420
+**1/** **@sasuke___420** ^1944916085217878130
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 have you spent time writing SIMD algorithms for general-purpose tasks? it does not seem possible to make this stuff accessible, because the set of available doodads and their costs influences your algorithm design
 
-**2/** @nicbarkeragain
+**2/** **@nicbarkeragain** ^1944921468489621892
 
-@sasuke___420
+**@sasuke___420**
 
 Yeah I have and I agree, it's clear that the way I've learned programming hasn't given me the correct "mental tools" to think about solving problems with a SIMD mindset. Maybe it's possible or maybe it isn't, but it feels like we don't have quite the right framing at the moment.
 
-**3/** @kellabyte
+**3/** **@kellabyte** ^1944925466600857981
 
-@nicbarkeragain @sasuke___420
+**@nicbarkeragain** **@sasuke___420**
 
 Data flow oriented programming instead of “OOP” where objects play roles and interact. Think like data and memory and layer your business rules on top of data structures that are sympathetic to the hardware.
 
-**4/** @sasuke___420
+**4/** **@sasuke___420** ^1944927873233502533
 
-@kellabyte @nicbarkeragain
+**@kellabyte** **@nicbarkeragain**
 
 yeah, a big thing in the proposed "do something like APL" solution is that they can have pretty complicated verbs that end up being implemented with operations that are normally exposed in libraries in normal languages
 
-**5/** @pelavarre
+**5/** **@pelavarre** ^1944929743717195989
 
-@sasuke___420 @kellabyte @nicbarkeragain
+**@sasuke___420** **@kellabyte** **@nicbarkeragain**
 
 I think
 
@@ -62,9 +62,9 @@ b ) Practically nobody codes it that way
 
 I wonder why not
 
-**6/** @sasuke___420
+**6/** **@sasuke___420** ^1944931502284005525
 
-@pelavarre @kellabyte @nicbarkeragain
+**@pelavarre** **@kellabyte** **@nicbarkeragain**
 
 it's an esoteric hobby. and solving general-ish problems like for regex engines instead of hand-coding specific parsers is like a lifetime of work. the guy whose lifetime of work it is, geoff langdale, is on here if you want to ask him
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-slendidev-have-you-looked-at-odins-simd.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-slendidev-have-you-looked-at-odins-simd.md
index 73945ae..6660b51 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-slendidev-have-you-looked-at-odins-simd.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-slendidev-have-you-looked-at-odins-simd.md
@@ -26,15 +26,15 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @slendidev
+**1/** **@slendidev** ^1944952001516716329
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 have you looked at Odin’s SIMD?
 
-**2/** @nicbarkeragain
+**2/** **@nicbarkeragain** ^1944953755537117588
 
-@xslendix
+**@xslendix**
 
 Yeah I really like the simplicity of the array programming in Odin, and there are a number of other languages that provide similar things. It could just be because my mindset is narrow, but that type of approach feels a bit specific and niche, I use it mostly for 3d math.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sorek_UK-whats-wrong-with-using-inline-asm.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sorek_UK-whats-wrong-with-using-inline-asm.md
index 97d8ac0..1902aeb 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sorek_UK-whats-wrong-with-using-inline-asm.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sorek_UK-whats-wrong-with-using-inline-asm.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @sorek_UK
+**1/** **@sorek_UK** ^1944943796006838648
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Whats wrong with using inline ASM?
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-splizard-just-enable-arithmetic-operations-on-fixed-sized.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-splizard-just-enable-arithmetic-operations-on-fixed-sized.md
index 4296703..54db865 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-splizard-just-enable-arithmetic-operations-on-fixed-sized.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-splizard-just-enable-arithmetic-operations-on-fixed-sized.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @splizard
+**1/** **@splizard** ^1945085884254105812
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Just enable arithmetic operations on fixed sized arrays and optimise this to use SIMD where possible
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-thejoephase-have-you-met-the-average-programmer.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-thejoephase-have-you-met-the-average-programmer.md
index 9020647..75d22ec 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-thejoephase-have-you-met-the-average-programmer.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-thejoephase-have-you-met-the-average-programmer.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @thejoephase
+**1/** **@thejoephase** ^1945065810763899008
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Have you met the average programmer?
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-theogcb405-thread.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-theogcb405-thread.md
index e47e825..a0880f5 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-theogcb405-thread.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-theogcb405-thread.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @theogcb405
+**1/** **@theogcb405** ^1945247807578759590
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 ![](https://pbs.twimg.com/media/Gv7okrWWUAAPlGF?format=jpg&name=orig)
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-2BitSalute-what-popped-into-my-head-is-languages-like-uiua.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-2BitSalute-what-popped-into-my-head-is-languages-like-uiua.md
index fa2367e..7acde8c 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-2BitSalute-what-popped-into-my-head-is-languages-like-uiua.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-2BitSalute-what-popped-into-my-head-is-languages-like-uiua.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @2BitSalute
+**1/** **@2BitSalute** ^1945487552011722857
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 What popped into my head is languages like Uiua
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-farre_x-but-is-it-really-that-hard-to-use-though-or-what.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-farre_x-but-is-it-really-that-hard-to-use-though-or-what.md
index 39cb3a6..d8fc55c 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-farre_x-but-is-it-really-that-hard-to-use-though-or-what.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-farre_x-but-is-it-really-that-hard-to-use-though-or-what.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @farre_x
+**1/** **@farre_x** ^1945597104895778866
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 But is it really that hard to use though? Or what scenario do you mean? If we are to make use of SIMD we will be doing operations on collections of numbers. That is fairly trivial with intrinsics
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-geofflangdale-hmmn-i-feel-most-of-the-pl-design-community-who.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-geofflangdale-hmmn-i-feel-most-of-the-pl-design-community-who.md
index ceda051..cb2982a 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-geofflangdale-hmmn-i-feel-most-of-the-pl-design-community-who.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-geofflangdale-hmmn-i-feel-most-of-the-pl-design-community-who.md
@@ -26,43 +26,43 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @geofflangdale
+**1/** **@geofflangdale** ^1945401263774162962
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Hmmn. I feel most of the PL design community - who have many folks I have the greatest admiration for, to be clear - is really fundamentally not that interested in the reality of the actual instructions on the machine.
 
 If the choice is to have SIMD ...
 
-**2/** @geofflangdale
+**2/** **@geofflangdale** ^1945401680868335902
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 programming smothered in a bureaucratic pile of type theory or some intrusive, hard-to-understand "magical autovec" system, my response to their help is, like the proverbial French merchants, "Laissez-nous faire".
 
 What I'd really like to see - a small but modest step - is a ...
 
-**3/** @geofflangdale
+**3/** **@geofflangdale** ^1945402059345551381
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 run-time that pads out the start and end of every region (stack, globals, heap)  - *not* every data item - with 63 bytes of padding so that any SIMD access can be done without the weird risk that we're right next to a unmapped page or some device with weird semantics ("on ...
 
-**4/** @joseph_h_garvin
+**4/** **@joseph_h_garvin** ^1945557778514215240
 
-@geofflangdale @nicbarkeragain
+**@geofflangdale** **@nicbarkeragain**
 
 I'm an aspiring PL+perf person that does care but I seem to be rare 😅 I think the situation is worse than this though...
 
-**5/** @joseph_h_garvin
+**5/** **@joseph_h_garvin** ^1945557912790655000
 
-@geofflangdale @nicbarkeragain
+**@geofflangdale** **@nicbarkeragain**
 
 Even if your allocator/linker/etc guarantee there's always an extra 63 zero bytes the C(++)/Rust lang semantics still allow the optimizer to launch missiles when you go out of bounds. That's UB, so now it can do whatever it wants instead. So you need lang semantics to change too.
 
-**6/** @geofflangdale
+**6/** **@geofflangdale** ^1945608389754863630
 
-@joseph_h_garvin @nicbarkeragain
+**@joseph_h_garvin** **@nicbarkeragain**
 
 Yes, I'd include this with the run-time changes. Personally, I think a good deal of UB (not all, of course) feels somewhat fatuous, but I don't really study the area closely enough to understand how much we could do without.
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-rtharston-ive-been-wondering-about-this-for-over-twenty.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-rtharston-ive-been-wondering-about-this-for-over-twenty.md
index 4287a82..f10650e 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-rtharston-ive-been-wondering-about-this-for-over-twenty.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-rtharston-ive-been-wondering-about-this-for-over-twenty.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @rtharston
+**1/** **@rtharston** ^1945604998022533294
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I’ve been wondering about this for over twenty years, but never found anything I felt was truly accessible.
 If I used SIMD more I’d probably try to come up with something to help.
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-themovercell-honestly-it-will-definitely-be-a-random-idea.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-themovercell-honestly-it-will-definitely-be-a-random-idea.md
index 8742d11..eb85daa 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-themovercell-honestly-it-will-definitely-be-a-random-idea.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-themovercell-honestly-it-will-definitely-be-a-random-idea.md
@@ -26,9 +26,9 @@ parent_post_id: "1944913662499516737"
 
 ## Branch
 
-**1/** @themovercell
+**1/** **@themovercell** ^1945386815537459355
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Honestly it will definitely be a random idea someone has at 3 am and everyone will just go "how did we not think about that earlier?" and then a revolution begins
 
diff --git a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/index.md b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/index.md
index 70bf273..55b533c 100644
--- a/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/index.md
+++ b/archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/index.md
@@ -25,17 +25,17 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @nicbarkeragain
+**1/** **@nicbarkeragain** ^1944913662499516737
 
 I can't help but have this feeling that we're missing something in programming language design that will make SIMD much easier for the average programmer to use. And that it will likely seem simple in hindsight.
 
 Branches: [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-another_sentry-https-github-com-higherorderco-bend]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sasuke___420-have-you-spent-time-writing-simd-algorithms-for]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etscrivner-i-think-ispc-more-or-less-solved-this-and-in-a-c]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-quentinoeoeoe-i-agree-there-is-something-weird-with-simd]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-WorldGhostC2C-llm-baked-into-gcc-whos-only-job-is-making-things]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-TheBuzzSaw-c-makes-it-fairly-straightforward]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-jshurmer-i-agree]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-agmethod75-its-called-array-programming-fortran-has-been]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Ed__dev-my-gamedev-head-just-wants-a-sort-of-game]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-etzikun-might-be-an-oversimplification-but-i-think-the]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-VPCOMPRESSB-intels-ispc]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-andrew_v10209-maybe-futhark-or-array-programming-theres-an]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JebsSteve0x1-ffmpeg-thinks-otherwise]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-examachine-possible]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-sorek_UK-whats-wrong-with-using-inline-asm]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-AgileJebrim-the-answer-exists-its-called-ispc]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-slendidev-have-you-looked-at-odins-simd]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meglio-the-average-programmer-you-mentioned-uses-oop-and]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-JakeLegendXIII-i-have-hope-that-this-is-true-but-damn-have-we]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-groby-so-fortran]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dezren39-more-arrays]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DeepknowledgeU-mojo-lang-has-simd-aware-data-types-and-makes-it]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-DanielJCollier-ispc]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-BigWhoopGames-reduced-instruction-sets-if-we-have-op-a-and-op-b]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-thejoephase-have-you-met-the-average-programmer]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-splizard-just-enable-arithmetic-operations-on-fixed-sized]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-dodobyte-openmp-does-good-enough-job-with-compiler-flags]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-salonen-i-think-we-need-a-system-visualizer-where-devs]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-SumErgoMonstro-have-you-ever-studied-apl-it-has-the-best-array]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-_Felipe-relational-model-columnar-data-sql-lands-itself]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-Zino2201_-perhaps-something-like-ispc-how-we-author-shaders]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-asdhuqiwuhdais-it-hasnt-been-stabilized-yet-but-rusts-portable]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-meoyawn-mojo-has-a-first-class-simd-support-afaik-but-ive]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-__morse-languages-that-have-comptime-also-have-wonderful]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-15-theogcb405-thread]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-themovercell-honestly-it-will-definitely-be-a-random-idea]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-geofflangdale-hmmn-i-feel-most-of-the-pl-design-community-who]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-2BitSalute-what-popped-into-my-head-is-languages-like-uiua]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-farre_x-but-is-it-really-that-hard-to-use-though-or-what]], [[archive/threads/nicbarkeragain/2025-07-15-i-cant-help-but-have-this-feeling-that-were/2025-07-16-rtharston-ive-been-wondering-about-this-for-over-twenty]]
 
-**2/** @nicbarkeragain
+**2/** **@nicbarkeragain** ^1944913664466948292
 
 It's easy to think of structured programming (i.e. text based, with conditionals like if / else, loops, local variables, etc) as a simple and obvious innovation over the top of assembly, but I suspect if you were programming in 1950 it might not have seemed so obvious.
 
-**3/** @nicbarkeragain
+**3/** **@nicbarkeragain** ^1944937375001666018
 
 Ironically it might take settling on a standard width among hardware vendors for us to be able to make reasonable headway there. I have no idea whether there are physical limitations to how wide we could go, or whether this would constitute a "pause" on hardware progress...
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-BurnZeZ-i-do-and-access-it-via-9p.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-BurnZeZ-i-do-and-access-it-via-9p.md
index e46b876..e7aa32a 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-BurnZeZ-i-do-and-access-it-via-9p.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-BurnZeZ-i-do-and-access-it-via-9p.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @BurnZeZ
+**1/** **@BurnZeZ** ^2084148778316034483
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I do and access it via 9p.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-DjMolehill-brb-adding-this-to-my-codebase.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-DjMolehill-brb-adding-this-to-my-codebase.md
index d33e60f..8848929 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-DjMolehill-brb-adding-this-to-my-codebase.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-DjMolehill-brb-adding-this-to-my-codebase.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @DjMolehill
+**1/** **@DjMolehill** ^2084151008817553509
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 brb adding this to my codebase
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-Leonardo_Temp-you-can-also-implicitly-pass-the-source-code.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-Leonardo_Temp-you-can-also-implicitly-pass-the-source-code.md
index c926b91..02062a9 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-Leonardo_Temp-you-can-also-implicitly-pass-the-source-code.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-Leonardo_Temp-you-can-also-implicitly-pass-the-source-code.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @Leonardo_Temp
+**1/** **@Leonardo_Temp** ^2084214550358876592
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 You can also implicitly pass the source code location from creation so there's no need for explicit labeling a lot of the time. Odin makes this easy with "loc := #caller_location"
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-MikeyBally-this-is-the-way.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-MikeyBally-this-is-the-way.md
index 4564879..730b663 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-MikeyBally-this-is-the-way.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-MikeyBally-this-is-the-way.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @MikeyBally
+**1/** **@MikeyBally** ^2084242087419969733
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 This is the way!
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RazorSharpFang-i-dont-suppose-you-could-demonstrate-this-with-a.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RazorSharpFang-i-dont-suppose-you-could-demonstrate-this-with-a.md
index 13be8ad..655a9ba 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RazorSharpFang-i-dont-suppose-you-could-demonstrate-this-with-a.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RazorSharpFang-i-dont-suppose-you-could-demonstrate-this-with-a.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @RazorSharpFang
+**1/** **@RazorSharpFang** ^2084147756646670657
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I don't suppose you could demonstrate this with a small code snippet/example that shows HOW one can label an allocation?
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RealOtisCrune-isnt-this-just-a-python-style-docstring-with.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RealOtisCrune-isnt-this-just-a-python-style-docstring-with.md
index ab2a14b..ec42d6c 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RealOtisCrune-isnt-this-just-a-python-style-docstring-with.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RealOtisCrune-isnt-this-just-a-python-style-docstring-with.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @RealOtisCrune
+**1/** **@RealOtisCrune** ^2084110760872128905
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Isn't this just a Python-style docstring with extra steps?
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-_can1357-https-learn-microsoft-com-en-us-windows-hardware.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-_can1357-https-learn-microsoft-com-en-us-windows-hardware.md
index 776bae1..b32dada 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-_can1357-https-learn-microsoft-com-en-us-windows-hardware.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-_can1357-https-learn-microsoft-com-en-us-windows-hardware.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @_can1357
+**1/** **@_can1357** ^2084128363652775945
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exallocatepool2 🤘
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-borrowck_novel-can-you-post-an-example-of-how-you-would.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-borrowck_novel-can-you-post-an-example-of-how-you-would.md
index 92fd8c6..0f6416b 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-borrowck_novel-can-you-post-an-example-of-how-you-would.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-borrowck_novel-can-you-post-an-example-of-how-you-would.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072932293386379"
 
 ## Branch
 
-**1/** @borrowck_novel
+**1/** **@borrowck_novel** ^2084191310303399995
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Can you post an example of how you would implement it?
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-exacoustics-iirc-sokol-gfx-does-this-its-really-nice-ive.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-exacoustics-iirc-sokol-gfx-does-this-its-really-nice-ive.md
index 2b02ba5..1ddfc39 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-exacoustics-iirc-sokol-gfx-does-this-its-really-nice-ive.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-exacoustics-iirc-sokol-gfx-does-this-its-really-nice-ive.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @exacoustics
+**1/** **@exacoustics** ^2084099272300253636
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 IIRC sokol_gfx does this. It’s really nice. I’ve copied the pattern in my own graphics API
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-joseph_h_garvin-when-ive-seen-this-they-usually-require-unique.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-joseph_h_garvin-when-ive-seen-this-they-usually-require-unique.md
index 40a3b70..5547167 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-joseph_h_garvin-when-ive-seen-this-they-usually-require-unique.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-joseph_h_garvin-when-ive-seen-this-they-usually-require-unique.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @joseph_h_garvin
+**1/** **@joseph_h_garvin** ^2084138515286081732
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 When I've seen this they usually require unique names and then you end up recapitulating the entire creation path in the string to make it unique but still readable, which I kinda hate. Do you not enforce uniqueness? Also a bunch of code to assemble those strings.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-onepopcorn-thats-actually-a-smart-idea-do-you-have-an.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-onepopcorn-thats-actually-a-smart-idea-do-you-have-an.md
index 2125914..bf200f0 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-onepopcorn-thats-actually-a-smart-idea-do-you-have-an.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-onepopcorn-thats-actually-a-smart-idea-do-you-have-an.md
@@ -26,15 +26,15 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @onepopcorn
+**1/** **@onepopcorn** ^2084163142041427988
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 That's actually a smart idea. Do you have an example of how you would implement that?
 
-**2/** @nicbarkeragain
+**2/** **@nicbarkeragain** ^2084852229291516401
 
-@onepopcorn
+**@onepopcorn**
 
 Here's an example I came across just now: https://x.com/nicbarkeragain/status/2084851804224004329?s=20
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-petey_fo_really-ya-tagging-allocations-and-frames-to-actual.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-petey_fo_really-ya-tagging-allocations-and-frames-to-actual.md
index cbb87e5..18f8be2 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-petey_fo_really-ya-tagging-allocations-and-frames-to-actual.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-petey_fo_really-ya-tagging-allocations-and-frames-to-actual.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @petey_fo_really
+**1/** **@petey_fo_really** ^2084134337105314188
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 ya tagging allocations, and frames to actual assets in-game is absolutely necessary for development once your game stops being a small thing
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Mallchad-i-accidentally-discovered-this-myself-it-just.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Mallchad-i-accidentally-discovered-this-myself-it-just.md
index c48767c..9e8495b 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Mallchad-i-accidentally-discovered-this-myself-it-just.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Mallchad-i-accidentally-discovered-this-myself-it-just.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @Mallchad
+**1/** **@Mallchad** ^2084546183922426362
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 I accidentally discovered this myself. It just makes everything so much easier, give every single thing a name and log errors instead of continuing silently.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Tomi_Tapio-function-draw-string-for-debug-in-my-games-3d.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Tomi_Tapio-function-draw-string-for-debug-in-my-games-3d.md
index 75fe12f..e1a1ffd 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Tomi_Tapio-function-draw-string-for-debug-in-my-games-3d.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Tomi_Tapio-function-draw-string-for-debug-in-my-games-3d.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @Tomi_Tapio
+**1/** **@Tomi_Tapio** ^2084605612764078535
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 function "draw string, for debug, in my game's 3d graphical space"
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-codeshaunted-webgpu-has-this-and-its-a-life-saver-for-debugging.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-codeshaunted-webgpu-has-this-and-its-a-life-saver-for-debugging.md
index 9eb57b6..dd04f06 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-codeshaunted-webgpu-has-this-and-its-a-life-saver-for-debugging.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-codeshaunted-webgpu-has-this-and-its-a-life-saver-for-debugging.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @codeshaunted
+**1/** **@codeshaunted** ^2084528811509719436
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 WebGPU has this and it’s a life saver for debugging
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-08-Drainyard-this-just-saved-me-from-hours-of-debugging.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-08-Drainyard-this-just-saved-me-from-hours-of-debugging.md
index 6d9dab0..fbc0eab 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-08-Drainyard-this-just-saved-me-from-hours-of-debugging.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-08-Drainyard-this-just-saved-me-from-hours-of-debugging.md
@@ -26,9 +26,9 @@ parent_post_id: "2084072929780998198"
 
 ## Branch
 
-**1/** @Drainyard
+**1/** **@Drainyard** ^2086199401907638656
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 This just saved me from hours of debugging.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/index.md b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/index.md
index 9491086..cc9ad5a 100644
--- a/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/index.md
+++ b/archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/index.md
@@ -25,13 +25,13 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @nicbarkeragain
+**1/** **@nicbarkeragain** ^2084072929780998198
 
 IMO basically every "object creation API" you have should take a string label that is for internal use only. You can ifdef them out in release, but it will save you so much grief when debugging. UI elements, mem allocations, input actions, just tag them all with a label / name.
 
 Branches: [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-exacoustics-iirc-sokol-gfx-does-this-its-really-nice-ive]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RealOtisCrune-isnt-this-just-a-python-style-docstring-with]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-_can1357-https-learn-microsoft-com-en-us-windows-hardware]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-petey_fo_really-ya-tagging-allocations-and-frames-to-actual]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-joseph_h_garvin-when-ive-seen-this-they-usually-require-unique]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-RazorSharpFang-i-dont-suppose-you-could-demonstrate-this-with-a]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-BurnZeZ-i-do-and-access-it-via-9p]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-DjMolehill-brb-adding-this-to-my-codebase]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-onepopcorn-thats-actually-a-smart-idea-do-you-have-an]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-Leonardo_Temp-you-can-also-implicitly-pass-the-source-code]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-03-MikeyBally-this-is-the-way]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-codeshaunted-webgpu-has-this-and-its-a-life-saver-for-debugging]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Mallchad-i-accidentally-discovered-this-myself-it-just]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-04-Tomi_Tapio-function-draw-string-for-debug-in-my-games-3d]], [[archive/threads/nicbarkeragain/2026-08-03-imo-basically-every-object-creation-api-you-have/2026-08-08-Drainyard-this-just-saved-me-from-hours-of-debugging]]
 
-**2/** @nicbarkeragain
+**2/** **@nicbarkeragain** ^2084072932293386379
 
 There's seriously nothing like going from "we have this memory leak every frame and don't know where tf it is" to "I paused the debugger and inspected the list of allocations, and there are 10,000 of them all labelled 'FormattedUnitName', so I grepped it in 5 seconds"
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-borrowck_novel-thanks-a-lot-for-the-example.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-borrowck_novel-thanks-a-lot-for-the-example.md
index c749c08..00293a7 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-borrowck_novel-thanks-a-lot-for-the-example.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-borrowck_novel-thanks-a-lot-for-the-example.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @borrowck_novel
+**1/** **@borrowck_novel** ^2084886942253007066
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Thanks a lot for the example
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-choco_dolphin7-1-got-into-the-habit-of-immediately-writing-free.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-choco_dolphin7-1-got-into-the-habit-of-immediately-writing-free.md
index 89188ad..a4d8199 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-choco_dolphin7-1-got-into-the-habit-of-immediately-writing-free.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-choco_dolphin7-1-got-into-the-habit-of-immediately-writing-free.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @choco_dolphin7
+**1/** **@choco_dolphin7** ^2084879873491779719
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 1. Got into the habit of immediately writing free()/close()/etc before anything else 2. Leaks are not that common or scary 3. If it was malloc'd memory, clang catches it for me before I even review + commit it 4. Too much hassle and clutter assigning unique strings to everything
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-datgame-ah-matching-strings-just-like-xml.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-datgame-ah-matching-strings-just-like-xml.md
index 10f2efb..b897bcd 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-datgame-ah-matching-strings-just-like-xml.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-datgame-ah-matching-strings-just-like-xml.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @datgame
+**1/** **@datgame** ^2084939273095073796
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Ah, matching strings, just like xml 🙃
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-eta9499-deferloop-is-super-useful-for-this.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-eta9499-deferloop-is-super-useful-for-this.md
index 1305d93..2b40351 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-eta9499-deferloop-is-super-useful-for-this.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-eta9499-deferloop-is-super-useful-for-this.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @eta9499
+**1/** **@eta9499** ^2085004503628071423
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 DeferLoop is super useful for this
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-hasen_95dx-this-particular-case-though-is-easily-solved-with.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-hasen_95dx-this-particular-case-though-is-easily-solved-with.md
index 5d71624..4c70a3e 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-hasen_95dx-this-particular-case-though-is-easily-solved-with.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-hasen_95dx-this-particular-case-though-is-easily-solved-with.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @hasen_95dx
+**1/** **@hasen_95dx** ^2084868526515634252
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 this particular case though is easily solved with `defer` or even `closures`
 
@@ -36,23 +36,23 @@ this particular case though is easily solved with `defer` or even `closures`
         // container is closed when this func exits
     })
 
-**2/** @nicbarkeragain
+**2/** **@nicbarkeragain** ^2084876136631419246
 
-@hasen_95dx
+**@hasen_95dx**
 
 Yes, I tend to use the "single iteration for loop" macro trick in C to do this exact thing with scope, but there are still a bunch of cases where you might want to have a direct API that you can use to call open / close:
 
 ![](https://pbs.twimg.com/media/HO73smTacAAYau2?format=jpg&name=orig)
 
-**3/** @nicbarkeragain
+**3/** **@nicbarkeragain** ^2084876247570813090
 
-@hasen_95dx
+**@hasen_95dx**
 
 I've also found explicit open / close to be very useful in rendering tree views / arbitrary recursive hierarchy etc.
 
-**4/** @hasen_95dx
+**4/** **@hasen_95dx** ^2084883855505604792
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Right. With the closure approach it would have to change.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-lionkimbro10x-i-love-everything-about-this-and-i-agree-its-fine.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-lionkimbro10x-i-love-everything-about-this-and-i-agree-its-fine.md
index 23896c5..5babee9 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-lionkimbro10x-i-love-everything-about-this-and-i-agree-its-fine.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-lionkimbro10x-i-love-everything-about-this-and-i-agree-its-fine.md
@@ -26,7 +26,7 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @lionkimbro10x
+**1/** **@lionkimbro10x** ^2084867619786785262
 
 I love everything about this.  And I agree, it's fine.  We should do more health-checking within programs, and yes, it can be optimized out.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-plasm_nl-thats-a-great-tip-i-always-used-comments-but-this.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-plasm_nl-thats-a-great-tip-i-always-used-comments-but-this.md
index d34ec93..c91dbc5 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-plasm_nl-thats-a-great-tip-i-always-used-comments-but-this.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-plasm_nl-thats-a-great-tip-i-always-used-comments-but-this.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @plasm_nl
+**1/** **@plasm_nl** ^2084924945960759547
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 That's a great tip. I always used comments, but this is better.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-rep_movsd-or-you-could-use-c-with-raii-and-not-have-to-tie.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-rep_movsd-or-you-could-use-c-with-raii-and-not-have-to-tie.md
index d500845..acd4bbc 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-rep_movsd-or-you-could-use-c-with-raii-and-not-have-to-tie.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-rep_movsd-or-you-could-use-c-with-raii-and-not-have-to-tie.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @rep_movsd
+**1/** **@rep_movsd** ^2084983215874592848
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Or you could use C++ with RAII and not have to tie yourself in knots
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-windless_mill-tangently-this-example-illustates-pretty-good-why.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-windless_mill-tangently-this-example-illustates-pretty-good-why.md
index 5b845bf..a79c42f 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-windless_mill-tangently-this-example-illustates-pretty-good-why.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-windless_mill-tangently-this-example-illustates-pretty-good-why.md
@@ -26,9 +26,9 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @windless_mill
+**1/** **@windless_mill** ^2085033979053260826
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 tangently, this example illustates pretty good why I like syntax with `end` keyword and optional name of closee better than just `{ ... }` especially {} when they also used for structure literals -- finding unbalanced scopes becomes such a hassle sometimes
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-06-real_philogy-rusts-ownership-raii-makes-such-patterns-really.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-06-real_philogy-rusts-ownership-raii-makes-such-patterns-really.md
index 30df54f..464ecc7 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-06-real_philogy-rusts-ownership-raii-makes-such-patterns-really.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-06-real_philogy-rusts-ownership-raii-makes-such-patterns-really.md
@@ -26,7 +26,7 @@ parent_post_id: "2084851804224004329"
 
 ## Branch
 
-**1/** @real_philogy
+**1/** **@real_philogy** ^2085401818083824080
 
 Rust's ownership + RAII makes such patterns really easy and nice to encode statically, no debug strings needed if the compiler guarantees you can't open another object at the same level if the previous one wasn't closed.
 
diff --git a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/index.md b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/index.md
index bf42f0a..e7d5528 100644
--- a/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/index.md
+++ b/archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @nicbarkeragain
+**1/** **@nicbarkeragain** ^2084851804224004329
 
 An example of this - a classic way to construct a tree in code is with push / pop style calls. Forgetting to call pop() or close() can be annoying to debug, and you can make this much easier just enforcing matching string tags on open / close. Also enforces readability:
 
@@ -33,8 +33,8 @@ An example of this - a classic way to construct a tree in code is with push / po
 
 Branches: [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-lionkimbro10x-i-love-everything-about-this-and-i-agree-its-fine]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-hasen_95dx-this-particular-case-though-is-easily-solved-with]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-choco_dolphin7-1-got-into-the-habit-of-immediately-writing-free]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-borrowck_novel-thanks-a-lot-for-the-example]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-plasm_nl-thats-a-great-tip-i-always-used-comments-but-this]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-datgame-ah-matching-strings-just-like-xml]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-rep_movsd-or-you-could-use-c-with-raii-and-not-have-to-tie]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-eta9499-deferloop-is-super-useful-for-this]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-05-windless_mill-tangently-this-example-illustates-pretty-good-why]], [[archive/threads/nicbarkeragain/2026-08-05-an-example-of-this-a-classic-way-to-construct-a/2026-08-06-real_philogy-rusts-ownership-raii-makes-such-patterns-really]]
 
-**2/** @exacoustics
+**2/** **@exacoustics** ^2084859876430536882
 
-@nicbarkeragain
+**@nicbarkeragain**
 
 Stealing this idea
diff --git a/archive/threads/onatt0/2025-04-30-holy-truthnuke-and-people-think-c-is-the-optimal-state-of/index.md b/archive/threads/onatt0/2025-04-30-holy-truthnuke-and-people-think-c-is-the-optimal-state-of/index.md
index 39d49af..a7a92fc 100644
--- a/archive/threads/onatt0/2025-04-30-holy-truthnuke-and-people-think-c-is-the-optimal-state-of/index.md
+++ b/archive/threads/onatt0/2025-04-30-holy-truthnuke-and-people-think-c-is-the-optimal-state-of/index.md
@@ -29,7 +29,7 @@ notes: "Hand-transcribed from screenshot. The original account is suspended and
 
 ## Branch
 
-**1/** @onatt0
+**1/** **@onatt0** ^1917656437473399108
 
 holy truthnuke - and people think C is the optimal state of possible runtimes when it's a very limited runtime to have state mixed call/data-stacks
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-SubstrataVr-example.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-SubstrataVr-example.md
index 38da542..082e806 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-SubstrataVr-example.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-SubstrataVr-example.md
@@ -26,9 +26,9 @@ parent_post_id: "1869409243251827152"
 
 ## Branch
 
-**1/** @SubstrataVr
+**1/** **@SubstrataVr** ^1869424048742232480
 
-@rfleury
+**@rfleury**
 
 example?
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-TriggerCoder-unroll.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-TriggerCoder-unroll.md
index 52fecac..b29651c 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-TriggerCoder-unroll.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-TriggerCoder-unroll.md
@@ -26,9 +26,9 @@ parent_post_id: "1869409243251827152"
 
 ## Branch
 
-**1/** @TriggerCoder
+**1/** **@TriggerCoder** ^1869417818250420400
 
-@rfleury @threadreaderapp
+**@rfleury** **@threadreaderapp**
 
 unroll
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-cairnc1-at-what-point-do-you-think-you-should-convert-a.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-cairnc1-at-what-point-do-you-think-you-should-convert-a.md
index 6c2ba25..4630f34 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-cairnc1-at-what-point-do-you-think-you-should-convert-a.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-cairnc1-at-what-point-do-you-think-you-should-convert-a.md
@@ -26,43 +26,43 @@ parent_post_id: "1869414867113009626"
 
 ## Branch
 
-**1/** @cairnc1
+**1/** **@cairnc1** ^1869448847807898074
 
-@rfleury
+**@rfleury**
 
 At what point do you think you should convert a switch statement to "behavior flags"? Suppose there are N entity types and K behaviors. There should be optimal values of N, K and number of shared behaviors. At least for the purpose of source code length.
 
-**2/** @rfleury
+**2/** **@rfleury** ^1869450526154494212
 
-@cairnc1
+**@cairnc1**
 
 The problem is that the definition of the problem changes. Assuming there are "entity types" at all is partly the problem. If there is only one entity type, but N possible features for each entity, then there are 2^N possibilities for each individual entity's features.
 
-**3/** @rfleury
+**3/** **@rfleury** ^1869450681347895562
 
-@cairnc1
+**@cairnc1**
 
 Personally I have found I only very rarely want the switch. I instead want a single type at the bottom, which expands out into these large 2^N spaces, so that a great deal is possible via small changes in data.
 
-**4/** @cairnc1
+**4/** **@cairnc1** ^1869454436504043725
 
-@rfleury
+**@rfleury**
 
 I prefer behavior flags in theory but I find myself often having very bespoke indecomposable behaviors that correspond 1:1 with a "object". Is it because I am too OOP brained? Fwiw I've only ever programmed in C. I guess it is still a win since sharing behaviors is still easier
 
-**5/** @rfleury
+**5/** **@rfleury** ^1869455668157280325
 
 Yeah, I think that is still preferable to "object types". It also makes it much lower friction to decompose them, if/when you see how that should happen. If it never happens, doesn't really matter. For heavier data payloads associated with those specific features, just store them out-of-band.
 
-**6/** @cairnc1
+**6/** **@cairnc1** ^1869458573530632619
 
-@rfleury
+**@rfleury**
 
 Btw organizing logic this way really makes me wish C had metagen built-in. 😔 I guess we still have X macros
 
-**7/** @rfleury
+**7/** **@rfleury** ^1869466426651938890
 
-@cairnc1
+**@cairnc1**
 
 Yeah, I get that, although once you have your own general-purpose codebase, it is not a big deal, because *you do* have metagen built in then :)
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-count_mascetti-maybe-you-already-wrote-this-somewhere-but-id-be.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-count_mascetti-maybe-you-already-wrote-this-somewhere-but-id-be.md
index 3641384..3c1a067 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-count_mascetti-maybe-you-already-wrote-this-somewhere-but-id-be.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-count_mascetti-maybe-you-already-wrote-this-somewhere-but-id-be.md
@@ -26,15 +26,15 @@ parent_post_id: "1869414867113009626"
 
 ## Branch
 
-**1/** @count_mascetti
+**1/** **@count_mascetti** ^1869425640103129200
 
-@rfleury
+**@rfleury**
 
 Maybe you already wrote this somewhere, but I'd be interested in seeing a practical example of your approach, even a basic one. It all sounds very appealing, but I'm struggling to come up with specific use cases.
 
-**2/** @rfleury
+**2/** **@rfleury** ^1869426286562816504
 
-@count_mascetti
+**@count_mascetti**
 
 https://www.rfleury.com/p/ui-part-3-the-widget-building-language
 https://www.rfleury.com/p/emergence-and-composition
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-pr0meteu5-any-concrete-example.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-pr0meteu5-any-concrete-example.md
index bcc99bd..65f3353 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-pr0meteu5-any-concrete-example.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-pr0meteu5-any-concrete-example.md
@@ -26,27 +26,27 @@ parent_post_id: "1869409243251827152"
 
 ## Branch
 
-**1/** @pr0meteu5
+**1/** **@pr0meteu5** ^1869438149832946012
 
-@rfleury
+**@rfleury**
 
 any concrete example?
 
-**2/** @rfleury
+**2/** **@rfleury** ^1869438674062164143
 
-@saddev24
+**@saddev24**
 
 - https://www.rfleury.com/p/ui-part-3-the-widget-building-language
 - https://www.rfleury.com/p/emergence-and-composition
 - https://www.rfleury.com/p/the-codepath-combinatoric-explosion
 
-**3/** @LazarTo42297588
+**3/** **@LazarTo42297588** ^1869778968221761675
 
-@rfleury @saddev24
+**@rfleury** **@saddev24**
 
 Let's say you're creating a generic table component, with different types of table columns. How will you design the cell render function so it handles all the different types of data that can be displayed: image, url, list, object, button.
 
-**4/** @rfleury
+**4/** **@rfleury** ^1869783150899204234
 
 The first thing I’d say is that this is not an architecture I even agree with. Any helpers for constructing a table should build *just the table*, with all UI & rendering capabilities being written by the user.
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-spacebat-this-reminds-me-of-games-and-simulations-where.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-spacebat-this-reminds-me-of-games-and-simulations-where.md
index 9f7daf2..46b6145 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-spacebat-this-reminds-me-of-games-and-simulations-where.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-spacebat-this-reminds-me-of-games-and-simulations-where.md
@@ -26,9 +26,9 @@ parent_post_id: "1869409243251827152"
 
 ## Branch
 
-**1/** @spacebat
+**1/** **@spacebat** ^1869488275423207781
 
-@rfleury
+**@rfleury**
 
 This reminds me of games and simulations, where entities have a set of attributes. That supports the use of entity component systems which gives each entity a key into various tables of related attributes, with subsystems for position/velocity, hit-points, buffs etc.
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-19-Walley_Alex1-i-completely-agree-i-am-interested-in-your.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-19-Walley_Alex1-i-completely-agree-i-am-interested-in-your.md
index 5c45813..0e7d878 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-19-Walley_Alex1-i-completely-agree-i-am-interested-in-your.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-19-Walley_Alex1-i-completely-agree-i-am-interested-in-your.md
@@ -26,15 +26,15 @@ parent_post_id: "1869409243251827152"
 
 ## Branch
 
-**1/** @Walley_Alex1
+**1/** **@Walley_Alex1** ^1869875982645244406
 
-@rfleury
+**@rfleury**
 
 I completely agree. I am interested in your thoughts on allowing these megastructure/product types to be used as part of a user API? One issue with product types: it is harder to see what a “valid” set of fields are. With a sum type, they are type checked
 
-**2/** @rfleury
+**2/** **@rfleury** ^1869879204361507032
 
-@Walley_Alex1
+**@Walley_Alex1**
 
 The idea is more that there *aren’t* invalid subsets of fields. All possibilities are on the table. This is actually more useful for usage code, because the underlying mechanisms are more flexible.
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-20-wetfsdffsdasd-interesting-projection-of-combinatorics-system.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-20-wetfsdffsdasd-interesting-projection-of-combinatorics-system.md
index 6a64d2d..9b70c08 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-20-wetfsdffsdasd-interesting-projection-of-combinatorics-system.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-20-wetfsdffsdasd-interesting-projection-of-combinatorics-system.md
@@ -26,9 +26,9 @@ parent_post_id: "1869409243251827152"
 
 ## Branch
 
-**1/** @wetfsdffsdasd
+**1/** **@wetfsdffsdasd** ^1870045591582933041
 
-@rfleury
+**@rfleury**
 
 interesting projection of combinatorics system into coding system. problem is, none of this yields always. an eg. is when you decouple the system into axbxcxd... such as the space of any of a,b,.. is small, you will be losing sanity and time. there are many other cases too
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2025-01-24-s0ulware-thank-you-for-this-thread-read-it-a-while-ago-but.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2025-01-24-s0ulware-thank-you-for-this-thread-read-it-a-while-ago-but.md
index ca564a0..d752296 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2025-01-24-s0ulware-thank-you-for-this-thread-read-it-a-while-ago-but.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2025-01-24-s0ulware-thank-you-for-this-thread-read-it-a-while-ago-but.md
@@ -26,15 +26,15 @@ parent_post_id: "1869409243251827152"
 
 ## Branch
 
-**1/** @s0ulware
+**1/** **@s0ulware** ^1882596282017186049
 
-@rfleury
+**@rfleury**
 
 thank you for this thread- read it a while ago, but now working on a game and something *clicked* when thinking about modeling data in this way (understanding the power of the 2^n benefit)
 
-**2/** @rfleury
+**2/** **@rfleury** ^1882596771396026486
 
-@s0ulware
+**@s0ulware**
 
 It’s seriously insane how useful it is, once you see it!
 
diff --git a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/index.md b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/index.md
index 866e1d8..a2b9294 100644
--- a/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/index.md
+++ b/archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/index.md
@@ -25,39 +25,39 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @rfleury
+**1/** **@rfleury** ^1869409243251827152
 
 One of the most powerful lessons I learned as a programmer was to use combinatoric spaces to my advantage, rather than allowing them to explode into—for example—handwritten source code. This required relaxing, for example, an obsession with static type checking.
 
 Branches: [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-TriggerCoder-unroll]], [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-SubstrataVr-example]], [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-pr0meteu5-any-concrete-example]], [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-18-spacebat-this-reminds-me-of-games-and-simulations-where]], [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-19-Walley_Alex1-i-completely-agree-i-am-interested-in-your]], [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2024-12-20-wetfsdffsdasd-interesting-projection-of-combinatorics-system]], [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a/2025-01-24-s0ulware-thank-you-for-this-thread-read-it-a-while-ago-but]]
 
-**2/** @rfleury
+**2/** **@rfleury** ^1869409245067882985
 
 Instead what I learned was to use static product types to form homogeneous building blocks for large combinatoric spaces, and to organize data transforms around forming those spaces. Choosing actual points in this space becomes a completely dynamic capability.
 
-**3/** @rfleury
+**3/** **@rfleury** ^1869410549592989761
 
 This is related to my comment the other day on sum types. The reason you won’t find many of them in my code is that I find that they leak combinatoric spaces into the source code itself, by forming one “axis” (1 of N types), which might be multiplied by another. That puts it in the path of non-temporal physical reality—physical code—which must either be handwritten or generated. This is either slow for the programmer, or for the computer.
 
-**4/** @rfleury
+**4/** **@rfleury** ^1869411240227016733
 
 Whereas if you keep the source code looser, with homogeneous types, you can allow defining points & transitioning between points in the combinatoric space to be much more natural & trivial of a computation. In practice this means you’ve turned an O(N*M*…) into an O(N+M+…), for either yourself or the compiler, or code generator (all three are good).
 
-**5/** @rfleury
+**5/** **@rfleury** ^1869413198081994912
 
 The fundamental reason for this is machine code, being representable by a transform from A -> B (where A and B are definitions of data formats, or types), must have a shape which expects/fits A as the input, and expects/fits B as the output. A|C -> B means you must have two paths: A -> B | C -> B. This suggests that, as the number of types grows, the number of codepaths must also grow. Or, put another way, the structure of types is reflected in the source code which uses those types.
 
-**6/** @rfleury
+**6/** **@rfleury** ^1869413521529966610
 
 You can often see this concretely in C - a discriminated `union` implies a `switch` (or some other branching mechanism on the tag). An array can imply a loop over the indices. A linked list can imply a loop over the links. And so on.
 
-**7/** @rfleury
+**7/** **@rfleury** ^1869414204496871475
 
 Thus, when someone attempts to take static type checking to the extreme, and maximally fit all potential data payloads into a format which only stores data which those payloads use (e.g. no unused fields in any case), they are not only exploding the number of types, they are also exploding the number of codepaths.
 
 When confronted with this reality, one impulse is to force compilers or other generators to iterate the combinatoric space manually; this is perhaps preferable to doing it by hand, but what's preferable over both options is to simply avoid the combinatoric space being present in this domain at all.
 
-**8/** @rfleury
+**8/** **@rfleury** ^1869414867113009626
 
 This makes distinctions in combinatoric spaces a very trivial data problem, rather than an arbitrarily difficult code problem. It makes the code small, yet the set of possible effects from the code large.
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-AnthonyPatch15-saw-a-casey-muratori-video-about-people-who-think.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-AnthonyPatch15-saw-a-casey-muratori-video-about-people-who-think.md
index d52e766..c39a4f5 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-AnthonyPatch15-saw-a-casey-muratori-video-about-people-who-think.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-AnthonyPatch15-saw-a-casey-muratori-video-about-people-who-think.md
@@ -26,35 +26,35 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @AnthonyPatch15
+**1/** **@AnthonyPatch15** ^1917436903994818849
 
-@rfleury
+**@rfleury**
 
 Saw a Casey Muratori video about people who think in single unit lifetimes vs group allocations etc yesterday.
 And while I actually agree with both of you, I am believe most of these modern C++ semantics / Rust tries to solve larger team problems.
 
-**2/** @rfleury
+**2/** **@rfleury** ^1917437304819572888
 
-@AnthonyPatch15
+**@AnthonyPatch15**
 
 There is no evidence to support the idea that these constructs are inherently necessary in larger teams.
 
-**3/** @AnthonyPatch15
+**3/** **@AnthonyPatch15** ^1917437823877075415
 
-@rfleury
+**@rfleury**
 
 No I don’t intend to try and prove it, they are by nature not. 
 But what tends to happen in most teams I’ve been part of is that they have some people who are super good and rigorous but also a lot of people who don’t really know what they’re doing - these help the second group.
 
-**4/** @survotreson
+**4/** **@survotreson** ^1917510046218346975
 
-@AnthonyPatch15 @rfleury
+**@AnthonyPatch15** **@rfleury**
 
 Then the people who don't know what they're doing maybe shouldn't participate and go train ? Kinda sounds like optimizing for the wrong thing here
 
-**5/** @AnthonyPatch15
+**5/** **@AnthonyPatch15** ^1917538690223767642
 
-@survotreson @rfleury
+**@survotreson** **@rfleury**
 
 In an ideal world yes, never been at a workplace that works like this.
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-DomWitczak-there-is-exactly-zero-pain-in-debugging-unique.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-DomWitczak-there-is-exactly-zero-pain-in-debugging-unique.md
index e98a520..a8b9968 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-DomWitczak-there-is-exactly-zero-pain-in-debugging-unique.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-DomWitczak-there-is-exactly-zero-pain-in-debugging-unique.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @DomWitczak
+**1/** **@DomWitczak** ^1917469208335507559
 
-@rfleury
+**@rfleury**
 
 There is exactly zero pain in debugging unique_ptr variables these days. Even with gdb.
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-KirillKiriche11-i-miss-the-point-you-are-trying-to-make.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-KirillKiriche11-i-miss-the-point-you-are-trying-to-make.md
index bc9237a..b8e32f0 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-KirillKiriche11-i-miss-the-point-you-are-trying-to-make.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-KirillKiriche11-i-miss-the-point-you-are-trying-to-make.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @KirillKiriche11
+**1/** **@KirillKiriche11** ^1917466585490678240
 
-@rfleury
+**@rfleury**
 
 I miss the point you are trying to make
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-MoveZig4-this-isnt-such-a-strong-argument-considering.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-MoveZig4-this-isnt-such-a-strong-argument-considering.md
index e23b6dd..bb42a37 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-MoveZig4-this-isnt-such-a-strong-argument-considering.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-MoveZig4-this-isnt-such-a-strong-argument-considering.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @MoveZig4
+**1/** **@MoveZig4** ^1917463363300610136
 
-@rfleury
+**@rfleury**
 
 This isn't such a strong argument considering there's a "leak" with the regular call to `new`. To my untrained eye under clang-19 the generated assembly for unique_ptr is a bit smaller/slimmer, with less stack usage - https://godbolt.org/z/sxejEsbe4 - can't turn on -O anything sadly
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Pps831-too-much-words-but-unique-ptr-is-really-zero-cost.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Pps831-too-much-words-but-unique-ptr-is-really-zero-cost.md
index 91a8530..87a6009 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Pps831-too-much-words-but-unique-ptr-is-really-zero-cost.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Pps831-too-much-words-but-unique-ptr-is-really-zero-cost.md
@@ -26,45 +26,45 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @Pps831
+**1/** **@Pps831** ^1917545684372447392
 
-@rfleury
+**@rfleury**
 
 Too much words, but unique_ptr is*really* zero cost. There is no way to go negative in cost there, no matter how much you wish for it 🤣
 
-**2/** @rfleury
+**2/** **@rfleury** ^1917562140229304416
 
-@Pps831
+**@Pps831**
 
 I recommend you learn to read
 
-**3/** @Pps831
+**3/** **@Pps831** ^1917585539068276751
 
-@rfleury
+**@rfleury**
 
 I’m ok. But you should at least try to validate if unique_par is zero cost or not. Also, in case you were really complaining about shared_ptr - try to cook something equivalent in c (not just “smart” ptr with ref count, but equivalent)
 
-**4/** @rfleury
+**4/** **@rfleury** ^1917585742181851605
 
-@Pps831
+**@Pps831**
 
 It isn’t zero cost.
 
-**5/** @Pps831
+**5/** **@Pps831** ^1917586343690899661
 
-@rfleury
+**@rfleury**
 
 Shared_ptr? Off course, it’s really heavy, but it has incredibly useful functionality.
 
-**6/** @rfleury
+**6/** **@rfleury** ^1917586838140903459
 
-@Pps831
+**@Pps831**
 
 No, both of them. Neither are useful compared to the alternatives.
 
-**7/** @Pps831
+**7/** **@Pps831** ^1917588371930767654
 
-@rfleury
+**@rfleury**
 
 If you “really” need the functionality - then it’s great. Most uses don’t really need shared_ptr. If you don’t use it along with “weak_ptr” then you don’t really need it. If you complain about all the allocations, it has solution for the problem: enable_shared_from_this
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Wouter_Bijlsma-generated-assembly-or-other-supposedly-better.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Wouter_Bijlsma-generated-assembly-or-other-supposedly-better.md
index e734c00..90d3652 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Wouter_Bijlsma-generated-assembly-or-other-supposedly-better.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Wouter_Bijlsma-generated-assembly-or-other-supposedly-better.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @Wouter_Bijlsma
+**1/** **@Wouter_Bijlsma** ^1917520025348436222
 
-@rfleury
+**@rfleury**
 
 Generated assembly or other supposedly better ‘hand-written’ options for memory management are IMO just distractions when talking about unique_ptr. The point of it is to signal and enforce ownership in an API, which can only be a good thing, no? Don’t understand the hate 🤨
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-anilcanglk12-i-bet-std-comitee-wrote-thousands-of-lines-for.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-anilcanglk12-i-bet-std-comitee-wrote-thousands-of-lines-for.md
index 987ccbc..44038cc 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-anilcanglk12-i-bet-std-comitee-wrote-thousands-of-lines-for.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-anilcanglk12-i-bet-std-comitee-wrote-thousands-of-lines-for.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @anilcanglk12
+**1/** **@anilcanglk12** ^1917498526285603216
 
-@rfleury
+**@rfleury**
 
 I bet std comitee wrote thousands of lines for this
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-eclectocrat-id-use-c-more-if-attribute-cleanup-was-standard.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-eclectocrat-id-use-c-more-if-attribute-cleanup-was-standard.md
index 773897e..b1f0f03 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-eclectocrat-id-use-c-more-if-attribute-cleanup-was-standard.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-eclectocrat-id-use-c-more-if-attribute-cleanup-was-standard.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @eclectocrat
+**1/** **@eclectocrat** ^1917612579972669856
 
-@rfleury
+**@rfleury**
 
 I'd use C more if attribute(__cleanup__) was standard and a little less cumbersome. C++ stack unwinding is and always has been it's killer feature.
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-mikejt4-my-experience-has-been-different-every-piece-of-c.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-mikejt4-my-experience-has-been-different-every-piece-of-c.md
index 1991201..8d5d405 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-mikejt4-my-experience-has-been-different-every-piece-of-c.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-mikejt4-my-experience-has-been-different-every-piece-of-c.md
@@ -26,26 +26,26 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @mikejt4
+**1/** **@mikejt4** ^1917515273680347506
 
 My experience has been different. Every piece of C code I used had weird memory leaks and page faults. 
 Good C++ with no naked pointers… huge codebase, dozens of developers - never one memory leaks. And performance was fantastic. Maybe not identical to hand-optimized C… but *far* easier to understand and maintain… especially for non god-like developers. We converted everything to C++, including our realtime embedded code. (Medical dev, so regulated, process driven…).
 
-**2/** @rfleury
+**2/** **@rfleury** ^1917566795256586508
 
-@mikejt4
+**@mikejt4**
 
 Many people have written C in very poor ways, but with the correct approach, it’s (a) simpler, (b) faster, (c) easier to maintain, (d) easier to read
 
-**3/** @dervish_candela
+**3/** **@dervish_candela** ^1917699967960953328
 
-@rfleury @mikejt4
+**@rfleury** **@mikejt4**
 
 if there is so little code written 'with the correct approach', perhaps 'the correct approach' is in fact anything but easier and simpler
 
-**4/** @rfleury
+**4/** **@rfleury** ^1917711908884697362
 
-@dervish_candela @mikejt4
+**@dervish_candela** **@mikejt4**
 
 I genuinely have no idea how you think that’s a coherent point—do you think fields simply do not advance?
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-shwadev78-also-people-will-say-this-garbage-and-then-show.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-shwadev78-also-people-will-say-this-garbage-and-then-show.md
index d1374e9..fcc9082 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-shwadev78-also-people-will-say-this-garbage-and-then-show.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-shwadev78-also-people-will-say-this-garbage-and-then-show.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @shwadev78
+**1/** **@shwadev78** ^1917447655128719815
 
-@rfleury
+**@rfleury**
 
 Also people will say this garbage and then show you the assembly in -O2. Debug build lives matter!
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-AbstrctMachnist-individual-malloc-free-is-a-common-c-practice-and.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-AbstrctMachnist-individual-malloc-free-is-a-common-c-practice-and.md
index 1c37eca..90716cc 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-AbstrctMachnist-individual-malloc-free-is-a-common-c-practice-and.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-AbstrctMachnist-individual-malloc-free-is-a-common-c-practice-and.md
@@ -26,49 +26,49 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @AbstrctMachnist
+**1/** **@AbstrctMachnist** ^1917754448178188666
 
-@rfleury
+**@rfleury**
 
 individual malloc/free is a common C practice and is the fair comparison; group allocations are not the norm in most programs especially in the hand-off ownership situations where unique_ptr would apply. In this light unique_ptr is strictly superior.
 
-**2/** @rfleury
+**2/** **@rfleury** ^1917776657131397142
 
-@AbstrctMachnist
+**@AbstrctMachnist**
 
 No, it isn’t the fair comparison, because that is not how sensible code is written.
 
-**3/** @AbstrctMachnist
+**3/** **@AbstrctMachnist** ^1917780558878249115
 
-@rfleury
+**@rfleury**
 
 Okay, well it's a like-vs-like comparison. If used as a straightforward replacement, unique_ptr is better. I concede it's not a replacement for a careful memory strategy.
 
-**4/** @rfleury
+**4/** **@rfleury** ^1917782019876217141
 
-@AbstrctMachnist
+**@AbstrctMachnist**
 
 But the equivalent code isn’t straightforward. It’s not *careful* to do something better. It’s both *easier and faster*. It is simply the superior way to not use them at all.
 
-**5/** @AbstrctMachnist
+**5/** **@AbstrctMachnist** ^1917786181099573679
 
-@rfleury
+**@rfleury**
 
 Looking at the RAD Debugger as an example (which is unfair, since you can't look at my code), the diligence of passing an allocator through every function, and being constantly mindful of which pool a given string is coming from, does not seem simple, though it is impressive.
 
-**6/** @rfleury
+**6/** **@rfleury** ^1917787214534390012
 
 It isn't through every function, though. And it is not accurate to say you are "constantly mindful" about it. Layers which allocate plan for & control those allocations through a variety of strategies. Most allocations are bucketed into arenas, so the allocation occurs and is forgotten. Anyone who is passed an allocation can use the allocation, they do not have to care about where it came from.
 
-**7/** @AbstrctMachnist
+**7/** **@AbstrctMachnist** ^1917790048071598171
 
-@rfleury
+**@rfleury**
 
 Alright, but surely this is more thought than probably even 95% of programs give to such things. Nor are most programs developed with such careful attention to layers and their individual memory strategies. And I don't think they should need to, by default.
 
-**8/** @rfleury
+**8/** **@rfleury** ^1917791946749403159
 
-@AbstrctMachnist
+**@AbstrctMachnist**
 
 *Someone* has to build those layers, is the point. The high level code doesn't have to think about anything. I agree that at those layers, nobody should be having to think about anything other than their problem.
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-RokCej-look-at-any-large-codebase-and-youll-see-a-bunch.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-RokCej-look-at-any-large-codebase-and-youll-see-a-bunch.md
index 40f8700..49d17d2 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-RokCej-look-at-any-large-codebase-and-youll-see-a-bunch.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-RokCej-look-at-any-large-codebase-and-youll-see-a-bunch.md
@@ -26,17 +26,17 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @RokCej
+**1/** **@RokCej** ^1918077301998129432
 
-@rfleury
+**@rfleury**
 
 Look at any large codebase and you'll see a bunch of new/delete calls. Replacing them with std::unique_ptr would make the code safer without adding any overhead, which was OP's point.
 
 Your argument pertains to a completely different topic and reeks of pretentiousness.
 
-**2/** @rfleury
+**2/** **@rfleury** ^1918078091433484469
 
-@RokCej
+**@RokCej**
 
 I simply cannot take you seriously
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-slendidev-do-you-have-any-example-of-this.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-slendidev-do-you-have-any-example-of-this.md
index 70d5cb7..11c8baa 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-slendidev-do-you-have-any-example-of-this.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-slendidev-do-you-have-any-example-of-this.md
@@ -26,69 +26,69 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @slendidev
+**1/** **@slendidev** ^1917745453656940712
 
-@rfleury
+**@rfleury**
 
 Do you have any example of this?
 
-**2/** @rfleury
+**2/** **@rfleury** ^1917746479185420605
 
-@xslendix
+**@xslendix**
 
 Example of what?
 
-**3/** @slendidev
+**3/** **@slendidev** ^1917748674907537414
 
-@rfleury
+**@rfleury**
 
 Of where stripping the smart pointers and other RAII stuff leads to simpler memory management (less allocations, less computation)
 
-**4/** @rfleury
+**4/** **@rfleury** ^1917749336869687610
 
-@xslendix
+**@xslendix**
 
 I have written several 100K LOC that is completely public that you can go look at and compare with other approaches
 
-**5/** @slendidev
+**5/** **@slendidev** ^1918322410652160032
 
-@rfleury
+**@rfleury**
 
 From looking at RADDbg, most of those allocations are avoided by using an arena. How is this any different from passing in an arena to a string for example instead of using the standard allocator?
 
-**6/** @rfleury
+**6/** **@rfleury** ^1918327964212887930
 
-@xslendix
+**@xslendix**
 
 It’s completely flipped from the usual RAII approach. Allocated things do not manage themselves. They don’t “know” about their allocator. Everything is just data organized into large buckets. As such, there are no destructors to insert, because there is no freeing to do.
 
-**7/** @slendidev
+**7/** **@slendidev** ^1918329072754491448
 
-@rfleury
+**@rfleury**
 
 You can just make the free method of the allocator be empty. If the arena is block based (growing arena) then you can also absolutely use that free method to re-use memory in previous blocks.
 
-**8/** @rfleury
+**8/** **@rfleury** ^1918329401093378456
 
-@xslendix
+**@xslendix**
 
 There’s no point.
 
-**9/** @slendidev
+**9/** **@slendidev** ^1918329782145802416
 
-@rfleury
+**@rfleury**
 
 Sure, but then you can still make that free method empty
 
-**10/** @rfleury
+**10/** **@rfleury** ^1918329939671334989
 
-@xslendix
+**@xslendix**
 
 Or you can just not do any of this ridiculous RAII nonsense at all.
 
-**11/** @slendidev
+**11/** **@slendidev** ^1918330778351804805
 
-@rfleury
+**@rfleury**
 
 At that point it’s just personal preference on wether you want your frees explicit or not in the code. Don’t think having an empty free method adds any overhead either since the compiler can just exclude the destructor entirely because of inlining
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-wmcoyne-well-said-zero-overhead-in-the-abstract-isnt-the.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-wmcoyne-well-said-zero-overhead-in-the-abstract-isnt-the.md
index efd1f4d..b58e23c 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-wmcoyne-well-said-zero-overhead-in-the-abstract-isnt-the.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-wmcoyne-well-said-zero-overhead-in-the-abstract-isnt-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1917431895786414425"
 
 ## Branch
 
-**1/** @wmcoyne
+**1/** **@wmcoyne** ^1917753799021646262
 
-@rfleury
+**@rfleury**
 
 Well said. Zero-overhead in the abstract isn't the same as zero-complexity in practice. Hand-coding forces you to confront design directly, not just inherit layers of generic indirection. Sometimes simpler really is better—especially when it matches your problem more precisely.
 
diff --git a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/index.md b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/index.md
index 651d371..10ebab5 100644
--- a/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/index.md
+++ b/archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @rfleury
+**1/** **@rfleury** ^1917431895786414425
 
 To the degree this is true, it’s only in a technical sense. When you actually force yourself to inline all of the extra nonsense that is implicitly happening in modern C++ codebases, it quickly becomes obvious that something is wrong, and it’s an enormously subpar solution.
 
@@ -37,40 +37,40 @@ Not to mention the fact that your compile times become way faster, all of your d
 
 Branches: [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-AnthonyPatch15-saw-a-casey-muratori-video-about-people-who-think]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-shwadev78-also-people-will-say-this-garbage-and-then-show]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-MoveZig4-this-isnt-such-a-strong-argument-considering]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-KirillKiriche11-i-miss-the-point-you-are-trying-to-make]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-DomWitczak-there-is-exactly-zero-pain-in-debugging-unique]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-anilcanglk12-i-bet-std-comitee-wrote-thousands-of-lines-for]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-mikejt4-my-experience-has-been-different-every-piece-of-c]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Wouter_Bijlsma-generated-assembly-or-other-supposedly-better]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-Pps831-too-much-words-but-unique-ptr-is-really-zero-cost]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-04-30-eclectocrat-id-use-c-more-if-attribute-cleanup-was-standard]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-slendidev-do-you-have-any-example-of-this]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-wmcoyne-well-said-zero-overhead-in-the-abstract-isnt-the]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-AbstrctMachnist-individual-malloc-free-is-a-common-c-practice-and]], [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a/2025-05-01-RokCej-look-at-any-large-codebase-and-youll-see-a-bunch]]
 
-**2/** @SubstrataVr
+**2/** **@SubstrataVr** ^1917436352578347222
 
-@rfleury
+**@rfleury**
 
 I think you may be thinking of shared_ptr, which does reference counting.  unique_ptr doesn't need to.
 
-**3/** @rfleury
+**3/** **@rfleury** ^1917436636163706994
 
-@SubstrataVr
+**@SubstrataVr**
 
 You’re right about the reference counts, my mistake. The other points still stand however.
 
-**4/** @static_assert_0
+**4/** **@static_assert_0** ^1917583100604813710
 
-@rfleury @SubstrataVr
+**@rfleury** **@SubstrataVr**
 
 In general maybe, but I don’t really see how any of this stands for unique_ptr - it literally is just a struct around a pointer with a deleted copy constructor to give you a compile error when you try to share it?
 
 Now the debugger argument that this adds extra noise is valid
 
-**5/** @rfleury
+**5/** **@rfleury** ^1917586421050925263
 
-@static_assert_0 @SubstrataVr
+**@static_assert_0** **@SubstrataVr**
 
 I wear certainly conflating the two (I do not use these features) but the argument stands, given that the places where you actually have “owned pointers” should be extremely small. This is seen as useful when you have 1000s of these. But you shouldn’t.
 
-**6/** @AbstrctMachnist
+**6/** **@AbstrctMachnist** ^1917756459321786491
 
-@rfleury @static_assert_0 @SubstrataVr
+**@rfleury** **@static_assert_0** **@SubstrataVr**
 
 I think this is a perspective difference between game developers, who have natural shared memory lifetimes in the form of frames, data batches, or update ticks, and general purpose developers where it's normal to have many operations in-flight with no common enclosing lifetime.
 
-**7/** @rfleury
+**7/** **@rfleury** ^1917776947574366253
 
-@AbstrctMachnist @static_assert_0 @SubstrataVr
+**@AbstrctMachnist** **@static_assert_0** **@SubstrataVr**
 
 This is not true. There are lifetimes all over the place in all fields. Everyone just lumps me into “game developers”, but I don’t even work on games professionally? How does your theory account for that? Do you think group lifetimes are somehow unique to games?
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-0x6e616461-i-like-using-lambdas-or-local-functions-to.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-0x6e616461-i-like-using-lambdas-or-local-functions-to.md
index 6ff43b1..936c718 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-0x6e616461-i-like-using-lambdas-or-local-functions-to.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-0x6e616461-i-like-using-lambdas-or-local-functions-to.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @0x6e616461
+**1/** **@0x6e616461** ^2061659934119354768
 
-@rfleury
+**@rfleury**
 
 I like using lambdas or local functions to extract some common logic and put it behind a good name without cluttering things up outside
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-AlexAegis-yes-a-similar-problem-comes-when-you-follow.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-AlexAegis-yes-a-similar-problem-comes-when-you-follow.md
index b32ded6..1b0f8fb 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-AlexAegis-yes-a-similar-problem-comes-when-you-follow.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-AlexAegis-yes-a-similar-problem-comes-when-you-follow.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @AlexAegis
+**1/** **@AlexAegis** ^2061831568537071703
 
-@rfleury
+**@rfleury**
 
 yes! A similar problem comes when you follow retarded bob martin-esque rules like not exceeding 6 lines per function. You can end up having a bunch of small functions mutating one common state that are now dependent on their call order. That’s not any better than a comment.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Arrghtv-i-completely-agree-adding-a-helper-function.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Arrghtv-i-completely-agree-adding-a-helper-function.md
index 509d948..347128b 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Arrghtv-i-completely-agree-adding-a-helper-function.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Arrghtv-i-completely-agree-adding-a-helper-function.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @Arrghtv
+**1/** **@Arrghtv** ^2061670156401611263
 
-@rfleury
+**@rfleury**
 
 I completely agree, adding a helper function rarely reduces complexity and often leads to a lot of argument bloat.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ChickenBurner2-oh-i-hate-helper-functions-especially-the-ones.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ChickenBurner2-oh-i-hate-helper-functions-especially-the-ones.md
index c51c8b7..0df0220 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ChickenBurner2-oh-i-hate-helper-functions-especially-the-ones.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ChickenBurner2-oh-i-hate-helper-functions-especially-the-ones.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @ChickenBurner2
+**1/** **@ChickenBurner2** ^2061723452571082945
 
-@rfleury
+**@rfleury**
 
 oh I hate helper functions, especially the ones that get used exactly once and serve no purpose but hiding code
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-JoelStransky-ive-come-to-refer-to-declarative-as-just-fucking.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-JoelStransky-ive-come-to-refer-to-declarative-as-just-fucking.md
index 0109dc5..7203df1 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-JoelStransky-ive-come-to-refer-to-declarative-as-just-fucking.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-JoelStransky-ive-come-to-refer-to-declarative-as-just-fucking.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @JoelStransky
+**1/** **@JoelStransky** ^2061851334278877273
 
-@rfleury
+**@rfleury**
 
 I've come to refer to declarative as "just fucking say it" coding.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Mallchad-ive-been-compressing-in-terms-of-section.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Mallchad-ive-been-compressing-in-terms-of-section.md
index b22d29e..1d5925e 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Mallchad-ive-been-compressing-in-terms-of-section.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Mallchad-ive-been-compressing-in-terms-of-section.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @Mallchad
+**1/** **@Mallchad** ^2061632296784941234
 
-@rfleury
+**@rfleury**
 
 I've been compressing in terms of "section functions" as opposed to helper functions. I find the concept of small functions teniously useful.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-MrModez-i-noticed-focusing-on-the-data-you-work-and-how.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-MrModez-i-noticed-focusing-on-the-data-you-work-and-how.md
index c100d50..e3e06e9 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-MrModez-i-noticed-focusing-on-the-data-you-work-and-how.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-MrModez-i-noticed-focusing-on-the-data-you-work-and-how.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @MrModez
+**1/** **@MrModez** ^2061700108933365773
 
-@rfleury
+**@rfleury**
 
 I noticed focusing on the data you work and how you work on it helps a lot
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Ravicale-ill-often-inline-every-helper-function-i-find.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Ravicale-ill-often-inline-every-helper-function-i-find.md
index 0b852fd..8595973 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Ravicale-ill-often-inline-every-helper-function-i-find.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Ravicale-ill-often-inline-every-helper-function-i-find.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @Ravicale
+**1/** **@Ravicale** ^2061912906921304345
 
-@rfleury
+**@rfleury**
 
 I'll often inline every 'helper function' I find while coding. This frequently lets me find more general patterns that can be more compactly expressed, and it also often results in me finding removable state that existed because of coupling between 'helpers'.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-SaladeTomate18-entry-point-you-mean-indirection.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-SaladeTomate18-entry-point-you-mean-indirection.md
index bb3b4b1..78dafe3 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-SaladeTomate18-entry-point-you-mean-indirection.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-SaladeTomate18-entry-point-you-mean-indirection.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @SaladeTomate18
+**1/** **@SaladeTomate18** ^2061680147627958466
 
-@rfleury
+**@rfleury**
 
 Entry point you mean indirection ?
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-alienorg-fewer-entry-points-fewer-surprises.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-alienorg-fewer-entry-points-fewer-surprises.md
index 9898fcf..d4fc6ff 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-alienorg-fewer-entry-points-fewer-surprises.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-alienorg-fewer-entry-points-fewer-surprises.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @alienorg
+**1/** **@alienorg** ^2061739363117973966
 
-@rfleury
+**@rfleury**
 
 fewer entry points = fewer surprises
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-anicic_filip-im-not-exactly-sure-what-do-you-mean-with-this.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-anicic_filip-im-not-exactly-sure-what-do-you-mean-with-this.md
index bf77039..4de4dd1 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-anicic_filip-im-not-exactly-sure-what-do-you-mean-with-this.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-anicic_filip-im-not-exactly-sure-what-do-you-mean-with-this.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @anicic_filip
+**1/** **@anicic_filip** ^2061769712824995927
 
-@rfleury
+**@rfleury**
 
 I'm not exactly sure what do you mean with this statement. Could you give a comparison example to solidify the statement with something we could analyse?
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-eron_wolf-i-like-giant-matching-functions-with-lots-of.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-eron_wolf-i-like-giant-matching-functions-with-lots-of.md
index 1a7c434..263fdec 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-eron_wolf-i-like-giant-matching-functions-with-lots-of.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-eron_wolf-i-like-giant-matching-functions-with-lots-of.md
@@ -26,13 +26,13 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @eron_wolf
+**1/** **@eron_wolf** ^2061625769684566075
 
-@rfleury
+**@rfleury**
 
 I like giant matching functions with lots of helper functions as closures with limited scope.  At least then you're kinda containing the mess.
 
-**2/** @rfleury
+**2/** **@rfleury** ^2061627148432216213
 
 That is definitely fair; I build as C (and I want to build with MSVC as well as the others, so I don't have all of the extensions), so I do not have local functions and certainly not closures, but I often find myself approximating similar patterns with command buffers. That said, I still find the statically linear flow preferable when possible.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-gcoum-only-way-to-compress-is-dsl-vv-everything-else-is.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-gcoum-only-way-to-compress-is-dsl-vv-everything-else-is.md
index e57a9a3..81a2adb 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-gcoum-only-way-to-compress-is-dsl-vv-everything-else-is.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-gcoum-only-way-to-compress-is-dsl-vv-everything-else-is.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @gcoum
+**1/** **@gcoum** ^2061640674576101837
 
-@rfleury
+**@rfleury**
 
 Only way to compress is dsl vv everything else is just the dsl with some extra boilerplate
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-guywald-100-agree-dry-can-be-extremely-overdone-llms-love.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-guywald-100-agree-dry-can-be-extremely-overdone-llms-love.md
index b7d5128..86cd133 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-guywald-100-agree-dry-can-be-extremely-overdone-llms-love.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-guywald-100-agree-dry-can-be-extremely-overdone-llms-love.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @guywald
+**1/** **@guywald** ^2061801368533315756
 
-@rfleury
+**@rfleury**
 
 100% agree, DRY can be extremely overdone. LLMs love doing this especially…
 There is also a huge price for cognitive complexity, for anyone, human or otherwise, that works on a codebase.
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jrjnorton-do-you-have-an-example-or-a-before-and-after-by.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jrjnorton-do-you-have-an-example-or-a-before-and-after-by.md
index 4b6d7d7..cea68df 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jrjnorton-do-you-have-an-example-or-a-before-and-after-by.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jrjnorton-do-you-have-an-example-or-a-before-and-after-by.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @jrjnorton
+**1/** **@jrjnorton** ^2061639688935317743
 
-@rfleury
+**@rfleury**
 
 Do you have an example or a before and after by chance?
 I don't find myself pulling out helper functions too often anymore so I'm having trouble thinking of what that looks like in practice
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jshurmer-very-well-said-it-would-be-useful-to-see-examples.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jshurmer-very-well-said-it-would-be-useful-to-see-examples.md
index 2c23362..2633a1c 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jshurmer-very-well-said-it-would-be-useful-to-see-examples.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jshurmer-very-well-said-it-would-be-useful-to-see-examples.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @jshurmer
+**1/** **@jshurmer** ^2061626322707734909
 
-@rfleury
+**@rfleury**
 
 Very well said. 
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-katanadash-my-mental-model-for-this-are-you-putting-the-mess.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-katanadash-my-mental-model-for-this-are-you-putting-the-mess.md
index 39b4f2d..cc6e813 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-katanadash-my-mental-model-for-this-are-you-putting-the-mess.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-katanadash-my-mental-model-for-this-are-you-putting-the-mess.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @katanadash
+**1/** **@katanadash** ^2061904729975001095
 
-@rfleury
+**@rfleury**
 
 My mental model for this: Are you putting the mess in a closet, or are you actually organizing the it?
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ndwork-a-function-explicitly-limits-the-variables-that.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ndwork-a-function-explicitly-limits-the-variables-that.md
index 11158bc..cc900e0 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ndwork-a-function-explicitly-limits-the-variables-that.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ndwork-a-function-explicitly-limits-the-variables-that.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @ndwork
+**1/** **@ndwork** ^2061896821023383829
 
-@rfleury
+**@rfleury**
 
 A function explicitly limits the variables that its code depends on.
 
@@ -36,15 +36,15 @@ For many functions, they can be independently tested. When possible, that also s
 
 These things make functions extremely useful.
 
-**2/** @rfleury
+**2/** **@rfleury** ^2061955393216200840
 
 No. By adding entry points which are independently tested (e.g. in a vacuum, removed from context), you are combinatorially increasing the number of possible test cases. It’s vastly easier to exercise one single codepath than several thousands.
 
 Second of all, sub-scopes also allow limiting exposed variables to other scopes. If a scope fairly far into a function depends on the entire set of exposed variables that came before, functions do not stop that, because you’d simply need to pass them all. There is way less boilerplate and way less complexity in the single codepath version.
 
-**3/** @ndwork
+**3/** **@ndwork** ^2062015909842350192
 
-@rfleury
+**@rfleury**
 
 I’m taking the fact that you didn’t tell me to delete my account as a huge mark of success.  :)
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-patrickgwsmith-i-like-this-as-it-maps-the-problem-with-input-on.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-patrickgwsmith-i-like-this-as-it-maps-the-problem-with-input-on.md
index b4ea568..90654e4 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-patrickgwsmith-i-like-this-as-it-maps-the-problem-with-input-on.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-patrickgwsmith-i-like-this-as-it-maps-the-problem-with-input-on.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @patrickgwsmith
+**1/** **@patrickgwsmith** ^2061690097158815943
 
-@rfleury
+**@rfleury**
 
 I like this as it maps the problem with input on one side and output on the other.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pbwinston-does-this-imply-if-you-took-an-external.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pbwinston-does-this-imply-if-you-took-an-external.md
index d01a1de..34438d2 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pbwinston-does-this-imply-if-you-took-an-external.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pbwinston-does-this-imply-if-you-took-an-external.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @pbwinston
+**1/** **@pbwinston** ^2061774820073734389
 
-@rfleury
+**@rfleury**
 
 Does this imply if you took an external dependency, like Linux or matrix library, and started folding that code into your own, instead of calling into it, your code would  improve?
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pegvvin-cant-tell-just-how-many-times-ive-pulled-out.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pegvvin-cant-tell-just-how-many-times-ive-pulled-out.md
index 21b39cb..177a9f2 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pegvvin-cant-tell-just-how-many-times-ive-pulled-out.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pegvvin-cant-tell-just-how-many-times-ive-pulled-out.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @pegvvin
+**1/** **@pegvvin** ^2061783632067633224
 
-@rfleury
+**@rfleury**
 
 Can't tell just how many times I've pulled out something into it's own function only to use it once. I was taught "clean code" incorrectly.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-polloimperial-i-got-a-mess-kind-of-working-fine-but-dirty-with.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-polloimperial-i-got-a-mess-kind-of-working-fine-but-dirty-with.md
index 53690b6..2cf6973 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-polloimperial-i-got-a-mess-kind-of-working-fine-but-dirty-with.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-polloimperial-i-got-a-mess-kind-of-working-fine-but-dirty-with.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @polloimperial
+**1/** **@polloimperial** ^2061632717666623787
 
-@rfleury
+**@rfleury**
 
 I got a mess (kind of working fine but dirty) with c# extensions.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-sipubot-db.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-sipubot-db.md
index dc98233..b07a86b 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-sipubot-db.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-sipubot-db.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @sipubot
+**1/** **@sipubot** ^2061782202275524654
 
-@rfleury
+**@rfleury**
 
 db 설계에 앞서 모든데이터를 파일 입출력 으로 해서 최소 부하를 해보는것도 도움이됨
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-vf42-never-thought-of-helper-f-ns-as-code-compression.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-vf42-never-thought-of-helper-f-ns-as-code-compression.md
index 37c8cd3..7e87b47 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-vf42-never-thought-of-helper-f-ns-as-code-compression.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-vf42-never-thought-of-helper-f-ns-as-code-compression.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @vf42
+**1/** **@vf42** ^2061694115520164235
 
-@rfleury
+**@rfleury**
 
 Never thought of helper f-ns as code compression, you still have all the same stuff elsewhere. Not to say it's useless.
 For the compression exercise ypu mention, I like to add a twist "...and make it easier to understand", which unlocks a whole new level to it.
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-wizplum-what-about-polymorphism-and-inheritance.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-wizplum-what-about-polymorphism-and-inheritance.md
index 83e22be..83b0f45 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-wizplum-what-about-polymorphism-and-inheritance.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-wizplum-what-about-polymorphism-and-inheritance.md
@@ -26,35 +26,35 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @wizplum
+**1/** **@wizplum** ^2061622209383379247
 
-@rfleury
+**@rfleury**
 
 What about polymorphism and inheritance?
 
-**2/** @rfleury
+**2/** **@rfleury** ^2061622448395800693
 
-@wizplum
+**@wizplum**
 
 Largely useless and terrible
 
-**3/** @SaladeTomate18
+**3/** **@SaladeTomate18** ^2061680038076961252
 
-@rfleury @wizplum
+**@rfleury** **@wizplum**
 
 You still need callback for buttons OnClick.
 
 I assume that's why you said largely (99%) and not always (100%)
 
-**4/** @rfleury
+**4/** **@rfleury** ^2061974675253850514
 
-@SaladeTomate18 @wizplum
+**@SaladeTomate18** **@wizplum**
 
 No, you don’t. You shouldn’t even have that concept. It’s not a good design.
 
-**5/** @SaladeTomate18
+**5/** **@SaladeTomate18** ^2061977183749357731
 
-@rfleury @wizplum
+**@rfleury** **@wizplum**
 
 How would you handle it ?
 
@@ -62,17 +62,17 @@ It is totally not my domain so I am just repeating basic patterns I've seen in m
 
 Thinking about it on the spot all I see is using IDs on buttons and a big switch.
 
-**6/** @rfleury
+**6/** **@rfleury** ^2061981087572832590
 
-@SaladeTomate18 @wizplum
+**@SaladeTomate18** **@wizplum**
 
 Check this out
 
 https://youtu.be/Z1qyvQsjK5Y
 
-**7/** @SaladeTomate18
+**7/** **@SaladeTomate18** ^2062024788810309926
 
-@rfleury @wizplum
+**@rfleury** **@wizplum**
 
 Already watched it years ago 😅
 
@@ -80,9 +80,9 @@ I thought we were talking specifically retained UI. Not Immediate ones.
 
 I do have some friends that worked on AAA with IM UI and they told me performance was not good compared to retained mode (could be just bad code ofc)
 
-**8/** @rfleury
+**8/** **@rfleury** ^2062029958340563373
 
-@SaladeTomate18 @wizplum
+**@SaladeTomate18** **@wizplum**
 
 Even with retained mode you do not need callbacks. But no, your friends are incorrect. There is nothing in principle about IM UI that makes it less performant than RM. In many cases it’s quite the opposite.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-0paperpal-will-love-to-read-a-long-article-on-this.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-0paperpal-will-love-to-read-a-long-article-on-this.md
index 7afa032..05a0291 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-0paperpal-will-love-to-read-a-long-article-on-this.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-0paperpal-will-love-to-read-a-long-article-on-this.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @0paperpal
+**1/** **@0paperpal** ^2062097820493193622
 
-@rfleury
+**@rfleury**
 
 will love to read a long article on this
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-alecodex-can-you-share-an-open-source-project-that-follows.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-alecodex-can-you-share-an-open-source-project-that-follows.md
index 7cd2395..7b374a9 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-alecodex-can-you-share-an-open-source-project-that-follows.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-alecodex-can-you-share-an-open-source-project-that-follows.md
@@ -26,15 +26,15 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @alecodex
+**1/** **@alecodex** ^2062309622510170465
 
-@rfleury
+**@rfleury**
 
 Can you share an open source project that follows this strategy? As someone deeply entrenched in the web and java world, I am finding it hard to wrap my head around.
 
-**2/** @rfleury
+**2/** **@rfleury** ^2062314977915294078
 
-@alecodex
+**@alecodex**
 
 https://github.com/EpicGamesExt/raddebugger
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-javiercbk-rad-debugger-is-easy-to-read-for-such-a-complex.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-javiercbk-rad-debugger-is-easy-to-read-for-such-a-complex.md
index 7ca8f07..6b047a6 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-javiercbk-rad-debugger-is-easy-to-read-for-such-a-complex.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-javiercbk-rad-debugger-is-easy-to-read-for-such-a-complex.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @javiercbk
+**1/** **@javiercbk** ^2061970388205146329
 
-@rfleury
+**@rfleury**
 
 rad debugger is easy to read for such a complex project, I'm experimenting with the same long proc and noticed that when I add something I'm not constrained to early abstractions, I can connect dots much easier. Yet  I have to resist years of brain programming for programming
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-jeremdak-i-like-a-big-ass-on-my-functions.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-jeremdak-i-like-a-big-ass-on-my-functions.md
index 45b7cf7..c11c3fe 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-jeremdak-i-like-a-big-ass-on-my-functions.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-jeremdak-i-like-a-big-ass-on-my-functions.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @jeremdak
+**1/** **@jeremdak** ^2061966313636131122
 
-@rfleury
+**@rfleury**
 
 I like a big ass on my functions.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-p_mbanugo-interesting-i-was-just-reviewing-code-and.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-p_mbanugo-interesting-i-was-just-reviewing-code-and.md
index e8a2a38..b8c8886 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-p_mbanugo-interesting-i-was-just-reviewing-code-and.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-p_mbanugo-interesting-i-was-just-reviewing-code-and.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @p_mbanugo
+**1/** **@p_mbanugo** ^2062293339030843846
 
-@rfleury
+**@rfleury**
 
 Interesting! I was just reviewing code and thinking of solution when I read this tweet and realised "table + removing enum" solved it better than expecting the helper function to be used correctly.
 
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-partnano-do-you-have-a-code-example-of-how-you-would.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-partnano-do-you-have-a-code-example-of-how-you-would.md
index 3672dd9..a399332 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-partnano-do-you-have-a-code-example-of-how-you-would.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-partnano-do-you-have-a-code-example-of-how-you-would.md
@@ -26,9 +26,9 @@ parent_post_id: "2061619837877780961"
 
 ## Branch
 
-**1/** @partnano
+**1/** **@partnano** ^2062209120782966979
 
-@rfleury
+**@rfleury**
 
 Do you have a code example of how you would compress / simplify something?
 I think I agree, and really need to be more mindful in my next coding session about it, but there's nothing specific coming to my mind, reading your post 😅
diff --git a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/index.md b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/index.md
index 9bbb672..b446f7a 100644
--- a/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/index.md
+++ b/archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @rfleury
+**1/** **@rfleury** ^2061619837877780961
 
 The first way people usually learn code compression is by pulling common things out into helper functions, but in my view the complexity of adding a new entry point is often overlooked, and things quickly turn into a mess.
 
@@ -33,6 +33,6 @@ It’s a useful exercise to try compressing code without helper functions, and i
 
 Branches: [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-wizplum-what-about-polymorphism-and-inheritance]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-eron_wolf-i-like-giant-matching-functions-with-lots-of]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jshurmer-very-well-said-it-would-be-useful-to-see-examples]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Mallchad-ive-been-compressing-in-terms-of-section]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-polloimperial-i-got-a-mess-kind-of-working-fine-but-dirty-with]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-jrjnorton-do-you-have-an-example-or-a-before-and-after-by]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-gcoum-only-way-to-compress-is-dsl-vv-everything-else-is]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-0x6e616461-i-like-using-lambdas-or-local-functions-to]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Arrghtv-i-completely-agree-adding-a-helper-function]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-SaladeTomate18-entry-point-you-mean-indirection]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-patrickgwsmith-i-like-this-as-it-maps-the-problem-with-input-on]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-vf42-never-thought-of-helper-f-ns-as-code-compression]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-MrModez-i-noticed-focusing-on-the-data-you-work-and-how]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ChickenBurner2-oh-i-hate-helper-functions-especially-the-ones]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-alienorg-fewer-entry-points-fewer-surprises]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-anicic_filip-im-not-exactly-sure-what-do-you-mean-with-this]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pbwinston-does-this-imply-if-you-took-an-external]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-sipubot-db]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-pegvvin-cant-tell-just-how-many-times-ive-pulled-out]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-guywald-100-agree-dry-can-be-extremely-overdone-llms-love]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-AlexAegis-yes-a-similar-problem-comes-when-you-follow]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-JoelStransky-ive-come-to-refer-to-declarative-as-just-fucking]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-ndwork-a-function-explicitly-limits-the-variables-that]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-katanadash-my-mental-model-for-this-are-you-putting-the-mess]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-02-Ravicale-ill-often-inline-every-helper-function-i-find]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-jeremdak-i-like-a-big-ass-on-my-functions]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-javiercbk-rad-debugger-is-easy-to-read-for-such-a-complex]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-0paperpal-will-love-to-read-a-long-article-on-this]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-partnano-do-you-have-a-code-example-of-how-you-would]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-p_mbanugo-interesting-i-was-just-reviewing-code-and]], [[archive/threads/rfleury/2026-06-02-the-first-way-people-usually-learn-code/2026-06-03-alecodex-can-you-share-an-open-source-project-that-follows]]
 
-**2/** @rfleury
+**2/** **@rfleury** ^2061621706834501685
 
 (It also naturally organizes work by computational requirements rather than abstract similarity, which simplifies code but also puts you in a much better position to make performance considerations)
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-JaceCear-if-you-got-a-concrete-example-of-this-it-might-be.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-JaceCear-if-you-got-a-concrete-example-of-this-it-might-be.md
index f6e4466..cbab284 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-JaceCear-if-you-got-a-concrete-example-of-this-it-might-be.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-JaceCear-if-you-got-a-concrete-example-of-this-it-might-be.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @JaceCear
+**1/** **@JaceCear** ^2085790906993541499
 
-@rfleury
+**@rfleury**
 
 If you got a concrete example of this, it might be worth making a video out of that, just saying! 😋
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-adam_bobowski-overall-ive-noticed-that-inlining-is-just-amazing.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-adam_bobowski-overall-ive-noticed-that-inlining-is-just-amazing.md
index 9b0d1cb..4ba98fe 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-adam_bobowski-overall-ive-noticed-that-inlining-is-just-amazing.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-adam_bobowski-overall-ive-noticed-that-inlining-is-just-amazing.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @adam_bobowski
+**1/** **@adam_bobowski** ^2085799786717049322
 
-@rfleury
+**@rfleury**
 
 Overall I’ve noticed that inlining is just amazing at surfacing issues with what the actual „abstraction” is - kind of that if I carve the function too early I’ll obfuscate the fact that maybe the actual function (behaviour) bends to that function rather than the other way around
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-borrowck_novel-assuming-o3-if-you-compare-the-assembly-output.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-borrowck_novel-assuming-o3-if-you-compare-the-assembly-output.md
index 6001c34..4559f39 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-borrowck_novel-assuming-o3-if-you-compare-the-assembly-output.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-borrowck_novel-assuming-o3-if-you-compare-the-assembly-output.md
@@ -26,21 +26,21 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @borrowck_novel
+**1/** **@borrowck_novel** ^2085804992540143894
 
-@rfleury
+**@rfleury**
 
 Assuming -O3, if you compare the assembly output before and after the exercise, do you see any meaningful difference?
 
-**2/** @rfleury
+**2/** **@rfleury** ^2085809430130803034
 
-@ZH1YGD
+**@ZH1YGD**
 
 Yes, absolutely
 
-**3/** @borrowck_novel
+**3/** **@borrowck_novel** ^2085812641507807328
 
-@rfleury
+**@rfleury**
 
 Thanks a ton. Then it is worth the time to do my own test. Cheers
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-calvinalkan-do-you-have-a-favorite-example-from-raddbg-to.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-calvinalkan-do-you-have-a-favorite-example-from-raddbg-to.md
index ae58624..6da8276 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-calvinalkan-do-you-have-a-favorite-example-from-raddbg-to.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-calvinalkan-do-you-have-a-favorite-example-from-raddbg-to.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @calvinalkan
+**1/** **@calvinalkan** ^2085812408988180668
 
-@rfleury
+**@rfleury**
 
 Do you have a favorite example from raddbg to look at?
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-davidvaughn006-this-seems-like-such-good-advice-and-hard-to.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-davidvaughn006-this-seems-like-such-good-advice-and-hard-to.md
index 656d2ed..0b92a3d 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-davidvaughn006-this-seems-like-such-good-advice-and-hard-to.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-davidvaughn006-this-seems-like-such-good-advice-and-hard-to.md
@@ -26,13 +26,13 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @davidvaughn006
+**1/** **@davidvaughn006** ^2085797125221179877
 
-@rfleury
+**@rfleury**
 
 This seems like such good advice and hard to visualize without having practiced a couple of times. Are there any good programming problems that would lend themselves to this kind of organizational refactoring?
 
-**2/** @rfleury
+**2/** **@rfleury** ^2085798544817135767
 
 It is pretty much any time you are dealing with code without regards for this. When someone isn't thinking about this, they will generate lots of redundant layers of helper functions or abstractions, and if you do a clean-up pass over it, you'll find that like 90% of it is nonsense.
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-jsuarez-this-is-the-first-thing-i-do-in-every-big-refactor.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-jsuarez-this-is-the-first-thing-i-do-in-every-big-refactor.md
index 6957dc2..79706a5 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-jsuarez-this-is-the-first-thing-i-do-in-every-big-refactor.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-jsuarez-this-is-the-first-thing-i-do-in-every-big-refactor.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @jsuarez
+**1/** **@jsuarez** ^2085822235907162194
 
-@rfleury
+**@rfleury**
 
 This is the first thing I do in every big refactor
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-sandovin34721-btw-this-sounds-like-a-nice-feature-for-a.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-sandovin34721-btw-this-sounds-like-a-nice-feature-for-a.md
index 4910464..e78c029 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-sandovin34721-btw-this-sounds-like-a-nice-feature-for-a.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-sandovin34721-btw-this-sounds-like-a-nice-feature-for-a.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @sandovin34721
+**1/** **@sandovin34721** ^2085804624213098970
 
-@rfleury
+**@rfleury**
 
 btw this sounds like a nice feature for a debugger
 like 'peek definition' in Visual Studio 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-tralamazza-couldnt-resist.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-tralamazza-couldnt-resist.md
index 139a3b8..b2c2d0a 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-tralamazza-couldnt-resist.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-tralamazza-couldnt-resist.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @tralamazza
+**1/** **@tralamazza** ^2085794821310906608
 
-@rfleury
+**@rfleury**
 
 couldn't resist
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-zygohistoprepro-i-did-this-process-to-linearise-the-mutually.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-zygohistoprepro-i-did-this-process-to-linearise-the-mutually.md
index 4896f23..a1e10f3 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-zygohistoprepro-i-did-this-process-to-linearise-the-mutually.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-zygohistoprepro-i-did-this-process-to-linearise-the-mutually.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @zygohistoprepro
+**1/** **@zygohistoprepro** ^2085814140040266159
 
-@rfleury
+**@rfleury**
 
 I did this process to linearise the mutually recursive eval loop of a language - also found a very nice opportunistic TCO due to it.
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-TylerCLaprade-john-carmack-wrote-about-this-http-number-none.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-TylerCLaprade-john-carmack-wrote-about-this-http-number-none.md
index 1b8324a..cc6135c 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-TylerCLaprade-john-carmack-wrote-about-this-http-number-none.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-TylerCLaprade-john-carmack-wrote-about-this-http-number-none.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @TylerCLaprade
+**1/** **@TylerCLaprade** ^2085913835706159301
 
-@rfleury
+**@rfleury**
 
 John Carmack wrote about this: http://number-none.com/blow/john_carmack_on_inlined_code.html
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-patrickgwsmith-some-people-will-say-that-a-good-abstraction-lets.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-patrickgwsmith-some-people-will-say-that-a-good-abstraction-lets.md
index f79a870..f4def90 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-patrickgwsmith-some-people-will-say-that-a-good-abstraction-lets.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-patrickgwsmith-some-people-will-say-that-a-good-abstraction-lets.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @patrickgwsmith
+**1/** **@patrickgwsmith** ^2085887028353441943
 
-@rfleury
+**@rfleury**
 
 Some people will say that a good abstraction lets you understand the loops underneath, and some will say that a good abstraction means you don’t have to understand the loops underneath.
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-rep_movsd-the-fundamental-property-of-abstraction-is-to.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-rep_movsd-the-fundamental-property-of-abstraction-is-to.md
index 2f8f686..a56c13b 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-rep_movsd-the-fundamental-property-of-abstraction-is-to.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-rep_movsd-the-fundamental-property-of-abstraction-is-to.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @rep_movsd
+**1/** **@rep_movsd** ^2085955766578823628
 
-@rfleury
+**@rfleury**
 
 The fundamental property of abstraction is to avoid repetition.
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-09-dvygh-makes-me-wonder-why-we-dont-have-a-tool-do-we-to.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-09-dvygh-makes-me-wonder-why-we-dont-have-a-tool-do-we-to.md
index 7c77a1e..ac81f13 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-09-dvygh-makes-me-wonder-why-we-dont-have-a-tool-do-we-to.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-09-dvygh-makes-me-wonder-why-we-dont-have-a-tool-do-we-to.md
@@ -26,9 +26,9 @@ parent_post_id: "2085786822387609939"
 
 ## Branch
 
-**1/** @dvygh
+**1/** **@dvygh** ^2086445668743168442
 
-@rfleury
+**@rfleury**
 
 makes me wonder why we don't have a tool (do we?) to visualize inlining like that (without actually doing it). maybe stop inlining at certain library call boundaries. not only to evaluate quality, but also to understand what the hell a function is doing.
 
diff --git a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/index.md b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/index.md
index fb2b634..bcda9b6 100644
--- a/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/index.md
+++ b/archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/index.md
@@ -25,14 +25,14 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @rfleury
+**1/** **@rfleury** ^2085786822387609939
 
 A good way to evaluate one axis of quality of an abstraction is to inline every function call, and see how much duplicate work you can either deduplicate or turn into a loop (rather than several independent function calls). This also restructures the code such that you can consider work as batches of identically shaped work, rather than either (a) being in shallow callstack code and dealing with a list of abstract, opaque function calls, or (b) being in deep callstack code and not understanding the context you're being called within.
 
 Branches: [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-JaceCear-if-you-got-a-concrete-example-of-this-it-might-be]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-tralamazza-couldnt-resist]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-davidvaughn006-this-seems-like-such-good-advice-and-hard-to]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-adam_bobowski-overall-ive-noticed-that-inlining-is-just-amazing]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-sandovin34721-btw-this-sounds-like-a-nice-feature-for-a]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-borrowck_novel-assuming-o3-if-you-compare-the-assembly-output]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-calvinalkan-do-you-have-a-favorite-example-from-raddbg-to]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-zygohistoprepro-i-did-this-process-to-linearise-the-mutually]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-07-jsuarez-this-is-the-first-thing-i-do-in-every-big-refactor]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-patrickgwsmith-some-people-will-say-that-a-good-abstraction-lets]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-TylerCLaprade-john-carmack-wrote-about-this-http-number-none]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-08-rep_movsd-the-fundamental-property-of-abstraction-is-to]], [[archive/threads/rfleury/2026-08-07-a-good-way-to-evaluate-one-axis-of-quality-of-an/2026-08-09-dvygh-makes-me-wonder-why-we-dont-have-a-tool-do-we-to]]
 
-**2/** @niftynathanj
+**2/** **@niftynathanj** ^2085788944814277107
 
-@rfleury
+**@rfleury**
 
 distance from main sequence
diff --git a/archive/threads/rianflo/2022-11-29-the-road-to-16-bit-floats-gpu-is-paved-with-our/index.md b/archive/threads/rianflo/2022-11-29-the-road-to-16-bit-floats-gpu-is-paved-with-our/index.md
index 5b750f5..82e80c0 100644
--- a/archive/threads/rianflo/2022-11-29-the-road-to-16-bit-floats-gpu-is-paved-with-our/index.md
+++ b/archive/threads/rianflo/2022-11-29-the-road-to-16-bit-floats-gpu-is-paved-with-our/index.md
@@ -25,46 +25,46 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @rianflo
+**1/** **@rianflo** ^1597661267845865474
 
 "The road to 16-bit floats GPU is paved with our blood"
 :-/
 
 https://www.yosoygames.com.ar/wp/2022/01/the-road-to-16-bit-floats-gpu-is-paved-with-our-blood/
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1597717009369735169
 
-@rianflo
+**@rianflo**
 
 Explicit packed 16-bit works on AMD Vulkan Vega and up. I typically get up to 30% improvement on ALU bound stuff. Lots of occupancy wins. I don't use {HLSL, RenderDoc, Reflection, RADV, or VS/PS}. All constants are packed and aliased as UINT, so no coversion overheads.
 
-**3/** @rianflo
+**3/** **@rianflo** ^1597718146663690240
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Oh I know the benefits. Just no simple clear way to write it in GLSL for vulkan.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^1597718560511385600
 
-@rianflo
+**@rianflo**
 
 Sure there is. CAS/FSR1/etc all shipped with fantastic GLSL versions using 16-bit packed math (I wrote those), all which at the time got fantastic code generation using AMD's drivers.
 
-**5/** @rianflo
+**5/** **@rianflo** ^1597720097753542656
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 What GLSL extension did you use?
 
-**6/** @rianflo
+**6/** **@rianflo** ^1597720454000541696
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 Oh wait, you're saying you wrote the fp16 math manually?
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1597798161665253376
 
-@rianflo
+**@rianflo**
 
 Explicit packed 16-bit code. FSR1 example: https://github.com/GPUOpen-Effects/FidelityFX-FSR/blob/master/ffx-fsr/ffx_fsr1.h - There are different 'F' (32-bit) and 'H' and 'Hx2' (packed 16-bit) functions.
 
diff --git a/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md
index dd1958c..b0a95f9 100644
--- a/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md
+++ b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not.md
@@ -26,21 +26,21 @@ parent_post_id: "2001106069238563204"
 
 ## Branch
 
-**1/** @rianflo
+**1/** **@rianflo** ^2001144169536884919
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 question is how much overhead. of course even not knowing how it was implemented, its obviously complex. but i’d take a bit of overhead in favor of writing a “program” top down on the gpu.
 
-**2/** @rianflo
+**2/** **@rianflo** ^2001145112932262354
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 you already know we’re on the same page wrt to rendering stuff differently, but it would be fun to show a proof of concept for rendering trad stuff this way, even just to proof a point. like load and render any gltf. :-)
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2001165107649216550
 
-@rianflo
+**@rianflo**
 
 I just need to get off the R&D train at some point and actually ship something :)
 
diff --git a/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md
index f194ff9..a3b2b45 100644
--- a/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md
+++ b/archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/index.md
@@ -25,58 +25,58 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @rianflo
+**1/** **@rianflo** ^2001080321802977727
 
 Significant amount of bloat dropped :-) 🎉🥳🎈
 
 I’d move it all to the GPU though. A single kernel that launches your pipeline steps per frame or per whatever. Pretty sure NV can do it. AMD I have no deep knowledge. @NOTimothyLottes ?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^2001106069238563204
 
-@rianflo
+**@rianflo**
 
 From my perspective being compute-only for graphics, few reasons to launch kernels because I'd always use a fixed amount of VGPRs. The larger problem is compilers that cannot keep up with the large program sizes (in compile time or register allocation).
 
 Branches: [[archive/threads/rianflo/2025-12-17-significant-amount-of-bloat-dropped/2025-12-17-rianflo-question-is-how-much-overhead-of-course-even-not]]
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^2001107058356088988
 
-@rianflo
+**@rianflo**
 
 Huge amount of pitfalls with compute-side dynamic dispatch of work (NV had it back when I worked there BTW), from long latency chains, to overheads tracking work completion, preemption, state restore, etc. It's not the golden answer people think it is. It is a slow path.
 
-**4/** @NOTimothyLottes
+**4/** **@NOTimothyLottes** ^2001107424523030580
 
-@rianflo
+**@rianflo**
 
 There are however a bunch of things we could trivially do GPU side that are currently CPU side, like computing best tiling modes for images, computing image {size, alignment, etc}, building descriptors, etc. Lots of other driver stuff could be done on the GPU for sure.
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^2001107937784127907
 
-@rianflo
+**@rianflo**
 
 My plan for 2026 is actually to build my open source AMD SteamOS/Linux driver for a future compute-graphics API, and it will be doing some radical stuff since I'm also doing shader binary code generation too :) Hopefully you all get live examples.
 
-**6/** @bkaradzic
+**6/** **@bkaradzic** ^2001125773508534778
 
-@NOTimothyLottes @rianflo
+**@NOTimothyLottes** **@rianflo**
 
 Can't wait! This compute-graphics API is something like compute + meshlets + fragment shaders only graphics API?
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^2001138916145991850
 
-@bkaradzic @rianflo
+**@bkaradzic** **@rianflo**
 
 Compute as in only compute shader dispatches, no fixed function graphics (no fragment/etc). And graphics via pure compute.
 
-**8/** @Nicolas_Lopez_
+**8/** **@Nicolas_Lopez_** ^2001323805197975947
 
-@NOTimothyLottes @bkaradzic @rianflo
+**@NOTimothyLottes** **@bkaradzic** **@rianflo**
 
 Considering how much we already software rasterize, we are not so far from it :)
 
-**9/** @rianflo
+**9/** **@rianflo** ^2001326067873886604
 
-@Nicolas_Lopez_ @NOTimothyLottes @bkaradzic
+**@Nicolas_Lopez_** **@NOTimothyLottes** **@bkaradzic**
 
 yeah but then someone insists on a couple of large triangles and wants to access the rasterizer hw again, which is supposedly too small of die area to be even worth ripping it out.
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-NOTimothyLottes-yeah-its-a-common-problem-thin-wrapper-interfaces.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-NOTimothyLottes-yeah-its-a-common-problem-thin-wrapper-interfaces.md
index 0007362..7b94e93 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-NOTimothyLottes-yeah-its-a-common-problem-thin-wrapper-interfaces.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-NOTimothyLottes-yeah-its-a-common-problem-thin-wrapper-interfaces.md
@@ -26,132 +26,132 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @NOTimothyLottes
+**1/** **@NOTimothyLottes** ^1890421311962239323
 
-@simplex_fx @SebAaltonen
+**@simplex_fx** **@SebAaltonen**
 
 Yeah it's a common problem, thin wrapper interfaces reduced to the worst platform's caps then called at high frequency ... it's the recipe for poor software engineering
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1890422944716763239
 
-@simplex_fx @SebAaltonen
+**@simplex_fx** **@SebAaltonen**
 
 Arguments like: we cannot do bindless at the engine interface level because our Intel iGPU binding limits are too low, etc. Just another sign the engine interface failed when all platforms are crippled for the LCD, better if only the LCD platforms are crippled
 
-**3/** @NOTimothyLottes
+**3/** **@NOTimothyLottes** ^1890427027657752809
 
-@simplex_fx @SebAaltonen
+**@simplex_fx** **@SebAaltonen**
 
 My interfaces are like @simplex_fx perhaps, I only do either extremely high-level, or extremely low-level. So my graphics API is just this below ...
 
 ![](https://pbs.twimg.com/media/GjwlQgIXMAAu8Va?format=png&name=orig)
 
-**4/** @simplex_fx
+**4/** **@simplex_fx** ^1890613479293284461
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 what is the mark-unmark thing?
 
-**5/** @NOTimothyLottes
+**5/** **@NOTimothyLottes** ^1890756769980240213
 
-@simplex_fx @SebAaltonen
+**@simplex_fx** **@SebAaltonen**
 
 It is a 1:1 map to VkEvents. Mark:set signal after all prior launched dispatches have completed, unmark:clear signal,  wait: wait for signal
 
-**6/** @simplex_fx
+**6/** **@simplex_fx** ^1890760769383403767
 
-@NOTimothyLottes @SebAaltonen
+**@NOTimothyLottes** **@SebAaltonen**
 
 Do you have plans to publish your render?
 
 Seems like some super nice and lightweight stuff.
 
-**7/** @NOTimothyLottes
+**7/** **@NOTimothyLottes** ^1890783426615107971
 
-@simplex_fx @SebAaltonen
+**@simplex_fx** **@SebAaltonen**
 
 The game/rendering side of my current project is too wild/game-specific to be of general usage, but the shell of the engine without the content, that I might release at some point into open source as an example
 
-**8/** @AgileJebrim
+**8/** **@AgileJebrim** ^1890783620056432948
 
-@NOTimothyLottes @simplex_fx @SebAaltonen
+**@NOTimothyLottes** **@simplex_fx** **@SebAaltonen**
 
 What’s the game?
 
-**9/** @NOTimothyLottes
+**9/** **@NOTimothyLottes** ^1890788321904791729
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 Across many years of working for IHVs and ISVs, I've been doing my own side project personal R&D prototypes geared towards solving all the key systems of a game I'd like to actually put into production some day
 
-**10/** @AgileJebrim
+**10/** **@AgileJebrim** ^1890788635936530843
 
-@NOTimothyLottes @simplex_fx @SebAaltonen
+**@NOTimothyLottes** **@simplex_fx** **@SebAaltonen**
 
 A combat flight sim MMO?
 
-**11/** @NOTimothyLottes
+**11/** **@NOTimothyLottes** ^1890793967840563311
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 Probably split it up into two: a single player vs world (low scope), then use that to fund what I really want to do which involves multi-player (high scope).
 
-**12/** @NOTimothyLottes
+**12/** **@NOTimothyLottes** ^1890796685552435645
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 FPS-like (more like 3D Descent [DOS], instead of fixed planar), trying to break ground more in world-scope simulation/thinking/destruction but not just thin on-planet-surface stuff, more like full planetoid interior [BLAME! style, an out-of-control world-building machine]
 
-**13/** @NOTimothyLottes
+**13/** **@NOTimothyLottes** ^1890799613814165537
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 Rewinding time, there have been some interesting milestones in PC gaming
 (1.) Command HQ (and similar) - Modem connected real-time multi-player world scale battle simulation with fog of war ...
 
 ![](https://pbs.twimg.com/media/Gj133GjXAAEjf7m?format=png&name=orig)
 
-**14/** @NOTimothyLottes
+**14/** **@NOTimothyLottes** ^1890801354295161076
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 (2.) Starflight https://www.filfre.net/2014/10/starflight/ - procedural universe generation, but with persistent interaction, they actually saved game state back to the floppy disk ... might say today "No Man's Sky" is like a modern version of that procedural universe generation
 
 ![](https://pbs.twimg.com/media/Gj15ToNWMAI5q9d?format=png&name=orig)
 
-**15/** @NOTimothyLottes
+**15/** **@NOTimothyLottes** ^1890802521565753686
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 Forwarding in time a lot
 (3.) Teardown - expanding the lego-style chunky voxel engine with fully dynamic destruction, while still maintaining a high quality render
 
 ![](https://pbs.twimg.com/media/Gj16icuW4AArsmT?format=jpg&name=orig)
 
-**16/** @NOTimothyLottes
+**16/** **@NOTimothyLottes** ^1890803744951898483
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 But there are a lot of barriers that feel like speed-of-sound barriers (possible) vs speed-of-light (impossible) with PC game tech, examples
 (1.) Voxel games - they stay mostly chunky (you have games like Voxile pushing this a little, with in-voxel details)
 
 ![](https://pbs.twimg.com/media/Gj17wiCXEAAyyfh?format=jpg&name=orig)
 
-**17/** @NOTimothyLottes
+**17/** **@NOTimothyLottes** ^1890805290347491714
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 (2.) Physical simulation. NV PhyX had some absolutely amazing demos of destruction, but not really anything that went all in on massive destruction BECAUSE the game is still on the CPU, and the GPU is limited to just graphics ... seems like still a massive opportunity
 
-**18/** @NOTimothyLottes
+**18/** **@NOTimothyLottes** ^1890805726139785464
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 (3.) And the biggest one IMO: many do procedural generation and stop there. But it is the MIX of procedural rules and simulation that actually generates interesting behavior and content, that is very under-explored
 
-**19/** @NOTimothyLottes
+**19/** **@NOTimothyLottes** ^1890807173917093907
 
-@AgileJebrim @simplex_fx @SebAaltonen
+**@AgileJebrim** **@simplex_fx** **@SebAaltonen**
 
 So the inflection point IMO was GPUs getting fast enough compute where triangle rendering wasn't required, and then getting large enough memory, where one could devote it to {high/low frequency simulation,persistence,etc} instead of "textures"
 
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-SebAaltonen-i-briefly-discussed-this-topic-in-my-siggraph.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-SebAaltonen-i-briefly-discussed-this-topic-in-my-siggraph.md
index e8254ad..26f3014 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-SebAaltonen-i-briefly-discussed-this-topic-in-my-siggraph.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-SebAaltonen-i-briefly-discussed-this-topic-in-my-siggraph.md
@@ -26,41 +26,41 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @SebAaltonen
+**1/** **@SebAaltonen** ^1890383966600888652
 
-@simplex_fx @NOTimothyLottes
+**@simplex_fx** **@NOTimothyLottes**
 
 I briefly discussed this topic in my SIGGRAPH 2022 talk.  The problem is that if you write a completely custom renderer for each platform, you have LOTS of platform specific code, which is super hard to maintain when your requirements change. 5x work for refactor is not fun.
 
-**2/** @SebAaltonen
+**2/** **@SebAaltonen** ^1890384155315249394
 
-@simplex_fx @NOTimothyLottes
+**@simplex_fx** **@NOTimothyLottes**
 
 Also with good design, you can almost 1:1 wrap Vulkan/Metal/DX12 under the same thin wrapper, so you don't end up wasting performance in a wrapper. Now you can write your low level rendering code once.
 
-**3/** @SebAaltonen
+**3/** **@SebAaltonen** ^1890384463625875663
 
-@simplex_fx @NOTimothyLottes
+**@simplex_fx** **@NOTimothyLottes**
 
 Good design == use placement heaps everywhere, use argument buffers (also in Metal) so that your memory management and binding model is identical. This way you don't need to send any data though the API wrapper. Write data directly to GPU memory, then call the wrapper to draw.
 
-**4/** @SebAaltonen
+**4/** **@SebAaltonen** ^1890384839938895966
 
-@simplex_fx @NOTimothyLottes
+**@simplex_fx** **@NOTimothyLottes**
 
 Also separating CPU->GPU data upload completely from drawing allows you to upload data at change frequency instead of draw frequency. Many big engines are slow as they upload data per draw call. That's bad design. Couples upload/draw tightly together. Must pay for both.
 
-**5/** @yuusakumenka
+**5/** **@yuusakumenka** ^1890523901886660651
 
-@SebAaltonen @simplex_fx @NOTimothyLottes
+**@SebAaltonen** **@simplex_fx** **@NOTimothyLottes**
 
 I've seen advised to use graphics queue (supporting transfer) for cpu write once gpu draw once data (immediate data recreated every frame).
 Then use separate data upload for data that suffers less frequent update (like per-instance scene data of a level editor).
 Is it bad advice?
 
-**6/** @yetmania
+**6/** **@yetmania** ^1890567591438983201
 
-@SebAaltonen @simplex_fx @NOTimothyLottes
+**@SebAaltonen** **@simplex_fx** **@NOTimothyLottes**
 
 Would this work for mobile phones?
 I thought that keeping the scene resident on the GPU relies on indirect draws with a count buffer (filled by a GPU culling computer shader) and bindless resources.
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-count_mascetti-every-time-i-abstract-at-a-higher-level-i-end-up.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-count_mascetti-every-time-i-abstract-at-a-higher-level-i-end-up.md
index 1dbe018..8e21b2a 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-count_mascetti-every-time-i-abstract-at-a-higher-level-i-end-up.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-count_mascetti-every-time-i-abstract-at-a-higher-level-i-end-up.md
@@ -26,9 +26,9 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @count_mascetti
+**1/** **@count_mascetti** ^1890351256641712490
 
-@simplex_fx @SebAaltonen @NOTimothyLottes
+**@simplex_fx** **@SebAaltonen** **@NOTimothyLottes**
 
 Every time I abstract at a higher-level I end up precluding some use-case that I didn't anticipate, perhaps because I'm still learning and lack the whole picture. I find it very hard to write high-level graphics abstractions that are performant and flexible enough.
 
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-matiasgoldberg-you-can-do-whatever-you-want-the-api-just-because.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-matiasgoldberg-you-can-do-whatever-you-want-the-api-just-because.md
index 1c02f71..1bcb56f 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-matiasgoldberg-you-can-do-whatever-you-want-the-api-just-because.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-matiasgoldberg-you-can-do-whatever-you-want-the-api-just-because.md
@@ -26,9 +26,9 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @matiasgoldberg
+**1/** **@matiasgoldberg** ^1890396648662073353
 
-@simplex_fx @SebAaltonen @NOTimothyLottes
+**@simplex_fx** **@SebAaltonen** **@NOTimothyLottes**
 
 You can do whatever you want the API. Just because you can read from a GPU buffer you just wrote doesn't mean you should.
 
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-RyDawgE256-i-dont-disagree-but-the-reason-is-that-99-of.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-RyDawgE256-i-dont-disagree-but-the-reason-is-that-99-of.md
index 539a081..6689134 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-RyDawgE256-i-dont-disagree-but-the-reason-is-that-99-of.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-RyDawgE256-i-dont-disagree-but-the-reason-is-that-99-of.md
@@ -26,9 +26,9 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @RyDawgE256
+**1/** **@RyDawgE256** ^1890554187336872420
 
-@simplex_fx @SebAaltonen @NOTimothyLottes
+**@simplex_fx** **@SebAaltonen** **@NOTimothyLottes**
 
 I don't disagree...  but the reason is that 99% of programmers don't gaf about the specifics of their renderer... which is a shame... but an unambiguous fact nonetheless
 
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-matthewcraig42-usually-the-key-benefit-is-two-fold-making-the.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-matthewcraig42-usually-the-key-benefit-is-two-fold-making-the.md
index 35e74b8..dff16ed 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-matthewcraig42-usually-the-key-benefit-is-two-fold-making-the.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-matthewcraig42-usually-the-key-benefit-is-two-fold-making-the.md
@@ -26,7 +26,7 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @matthewcraig42
+**1/** **@matthewcraig42** ^1890635763819446764
 
 Usually the key benefit is two fold, making the code truly cross platform and decoupling user level code from a specific rendering api/backend. Without that if you change the underlying render API it will break all your user level code, and adding additional render backends is also challenging.
 
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-pagedeux-the-render-pipeline-is-basically-a-full-piece-of.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-pagedeux-the-render-pipeline-is-basically-a-full-piece-of.md
index 82f0ae7..e8b3f17 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-pagedeux-the-render-pipeline-is-basically-a-full-piece-of.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-pagedeux-the-render-pipeline-is-basically-a-full-piece-of.md
@@ -26,9 +26,9 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @pagedeux
+**1/** **@pagedeux** ^1890719137904709668
 
-@simplex_fx @SebAaltonen @NOTimothyLottes
+**@simplex_fx** **@SebAaltonen** **@NOTimothyLottes**
 
 the render pipeline is basically a full piece of software trapped in inside of another software
 
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-vanderschnarzen-i-have-exactly-that-my-abstraction-is-basically.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-vanderschnarzen-i-have-exactly-that-my-abstraction-is-basically.md
index 0995d75..a1ccc2f 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-vanderschnarzen-i-have-exactly-that-my-abstraction-is-basically.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-vanderschnarzen-i-have-exactly-that-my-abstraction-is-basically.md
@@ -26,9 +26,9 @@ parent_post_id: "1890348863287943363"
 
 ## Branch
 
-**1/** @vanderschnarzen
+**1/** **@vanderschnarzen** ^1890804090046689518
 
-@simplex_fx @SebAaltonen @NOTimothyLottes
+**@simplex_fx** **@SebAaltonen** **@NOTimothyLottes**
 
 I have exactly that. My abstraction is basically just mesh and material. If you abstract on a low level you usually have to go with the smallest common denom- which prevents you from really taking advantage of a specific api. Opinions might differ, but that's just my two cents...
 
diff --git a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/index.md b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/index.md
index bd2a4c3..8cb7abb 100644
--- a/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/index.md
+++ b/archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @simplex_fx
+**1/** **@simplex_fx** ^1890348863287943363
 
 Hey, gpu guys like @SebAaltonen @NOTimothyLottes why do rendering guys usually wrap 3d apis at low level in engines, creating some generic mid-low level API?
 
@@ -35,8 +35,8 @@ Unless you go with some super generic game engine (bad idea on it's own anyway),
 
 Branches: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-count_mascetti-every-time-i-abstract-at-a-higher-level-i-end-up]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-SebAaltonen-i-briefly-discussed-this-topic-in-my-siggraph]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-matiasgoldberg-you-can-do-whatever-you-want-the-api-just-because]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-NOTimothyLottes-yeah-its-a-common-problem-thin-wrapper-interfaces]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-RyDawgE256-i-dont-disagree-but-the-reason-is-that-99-of]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-matthewcraig42-usually-the-key-benefit-is-two-fold-making-the]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-pagedeux-the-render-pipeline-is-basically-a-full-piece-of]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-vanderschnarzen-i-have-exactly-that-my-abstraction-is-basically]]
 
-**2/** @songohab
+**2/** **@songohab** ^1890350151862018290
 
-@simplex_fx @SebAaltonen @NOTimothyLottes
+**@simplex_fx** **@SebAaltonen** **@NOTimothyLottes**
 
 Exactly the question I was asking myself lol. Always felt like 3D apis SHOULD be specific. But I’m just a noob
diff --git a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md
index 76ceb8a..b0d65fc 100644
--- a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md
+++ b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-Cheezaight-if-this-is-not-timothy-lottes-then-who-is-it.md
@@ -26,9 +26,9 @@ parent_post_id: "1990462184170926463"
 
 ## Branch
 
-**1/** @Cheezaight
+**1/** **@Cheezaight** ^1990482324635725950
 
-@valigo @NOTimothyLottes
+**@valigo** **@NOTimothyLottes**
 
 If this is not Timothy Lottes then who is it?
 
diff --git a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md
index d00bf66..8e5ecbf 100644
--- a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md
+++ b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/2025-11-17-mrsteyk1-his-style-goes-a-bit-beyond-that-judging-by-the.md
@@ -26,15 +26,15 @@ parent_post_id: "1990462184170926463"
 
 ## Branch
 
-**1/** @mrsteyk1
+**1/** **@mrsteyk1** ^1990467157357150599
 
-@valigo
+**@valigo**
 
 His style goes a bit beyond that, judging by the defines used it’s similar to some form of literate programming but with C preprocessor. And the whole RAM thing iirc was for when he was hot reloading C, he said he later switched to GPU and it’s not exactly required anymore?
 
-**2/** @NOTimothyLottes
+**2/** **@NOTimothyLottes** ^1990502146979344767
 
-@mrsteyk1 @valigo
+**@mrsteyk1** **@valigo**
 
 Oh I still use the RAM global struct and pointer even without using CPU side hot reload.
 
diff --git a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md
index e3324fe..4f0b2f6 100644
--- a/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md
+++ b/archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @valigo
+**1/** **@valigo** ^1990460012385522118
 
 People who say "C is modern-day assembly" usually way undershoot it. This guy actually writes C like it's asm:
 - No types - uints everywhere until a cast to actual type on access.
@@ -35,7 +35,7 @@ Is this how all GPU programmers write C?
 ![](https://pbs.twimg.com/media/G5-G1WZXoAIm5WW?format=jpg&name=orig)
 ![](https://pbs.twimg.com/media/G5-HR8yXoAEae5Z?format=jpg&name=orig)
 
-**2/** @valigo
+**2/** **@valigo** ^1990462184170926463
 
 This is @NOTimothyLottes btw, with his "Fixing C" talk, it's very cool. I really like mixing up shader code and regular C code in the same file and just ifdefind it out depending on which compiler you runt it through: https://www.youtube.com/watch?v=RrL7121MOeA
 
diff --git a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-Ron172892111531-wouldnt-this-make-working-with-arrays-more.md b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-Ron172892111531-wouldnt-this-make-working-with-arrays-more.md
index 44b2d32..8e111ec 100644
--- a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-Ron172892111531-wouldnt-this-make-working-with-arrays-more.md
+++ b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-Ron172892111531-wouldnt-this-make-working-with-arrays-more.md
@@ -26,21 +26,21 @@ parent_post_id: "1990506460531601538"
 
 ## Branch
 
-**1/** @Ron172892111531
+**1/** **@Ron172892111531** ^1990816225815875661
 
-@valigo
+**@valigo**
 
 Wouldn't this make working with arrays more difficult? Array[1] would have to be Array[sizeof(data)] etc
 
-**2/** @valigo
+**2/** **@valigo** ^1990816587268452795
 
-@Ron172892111531
+**@Ron172892111531**
 
 As I said somewhere else, it makes sense sizeof pointer math to be the default. I was just saying that it's confusing because "+1" is not actually "plus one"
 
-**3/** @Ron172892111531
+**3/** **@Ron172892111531** ^1990919087174672673
 
-@valigo
+**@valigo**
 
 Ptr+1. It's not plus one byte (or int addition), it's plus one object. I think it's only confusing when people assume pointers are just fancy integers. They're meant to work with arrays, and they do flawlessly as long as one remembers that they are an extension of the array
 
diff --git a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-TheBonkMaykr-it-is-confusing-if-you-arent-used-to-it-that-is.md b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-TheBonkMaykr-it-is-confusing-if-you-arent-used-to-it-that-is.md
index 0a8ef69..80d5961 100644
--- a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-TheBonkMaykr-it-is-confusing-if-you-arent-used-to-it-that-is.md
+++ b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-TheBonkMaykr-it-is-confusing-if-you-arent-used-to-it-that-is.md
@@ -26,7 +26,7 @@ parent_post_id: "1990506460531601538"
 
 ## Branch
 
-**1/** @TheBonkMaykr
+**1/** **@TheBonkMaykr** ^1990800281248936078
 
 It is confusing if you aren't used to it, that is true. But if you care about portability, letting the C compiler decide what the size of a pointer is, and how to handle pointer arithmetic, is better long-term.
 
diff --git a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-attamayte1-pointer-arithmetic-based-on-type-sizes-makes.md b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-attamayte1-pointer-arithmetic-based-on-type-sizes-makes.md
index 498b67b..2c60fc7 100644
--- a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-attamayte1-pointer-arithmetic-based-on-type-sizes-makes.md
+++ b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-attamayte1-pointer-arithmetic-based-on-type-sizes-makes.md
@@ -26,17 +26,17 @@ parent_post_id: "1990506460531601538"
 
 ## Branch
 
-**1/** @attamayte1
+**1/** **@attamayte1** ^1990701881744896485
 
-@valigo
+**@valigo**
 
 Pointer arithmetic based on type sizes makes sense when considering aligned load/store memory operations.
 
 I’d argue that even today, with relaxed rules, we commonly use typed arrays and calculate offsets in bytes only when working with generic buffers, like binary data blobs.
 
-**2/** @valigo
+**2/** **@valigo** ^1990702455730929959
 
-@attamayte1
+**@attamayte1**
 
 Yeah it makes sense for it to be the default. It's still confusing :)
 
diff --git a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-furiouswhopper-for-real-im-parsing-through-a-binary-array-and.md b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-furiouswhopper-for-real-im-parsing-through-a-binary-array-and.md
index 67b88f7..7d97e64 100644
--- a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-furiouswhopper-for-real-im-parsing-through-a-binary-array-and.md
+++ b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-furiouswhopper-for-real-im-parsing-through-a-binary-array-and.md
@@ -26,9 +26,9 @@ parent_post_id: "1990506460531601538"
 
 ## Branch
 
-**1/** @furiouswhopper
+**1/** **@furiouswhopper** ^1990793698985324939
 
-@valigo
+**@valigo**
 
 For real I'm parsing through a binary array and trying to say "the next byte is a uint8_t, the next two bytes are a uint16_t" and the most elegant way to do it is mind-numbingly ugly pointer bullshit.
 
diff --git a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-mrsteyk1-i-had-the-displeasure-of-being-exposed-to-hex.md b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-mrsteyk1-i-had-the-displeasure-of-being-exposed-to-hex.md
index 97fa8cb..e90d6ef 100644
--- a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-mrsteyk1-i-had-the-displeasure-of-being-exposed-to-hex.md
+++ b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-mrsteyk1-i-had-the-displeasure-of-being-exposed-to-hex.md
@@ -26,9 +26,9 @@ parent_post_id: "1990506460531601538"
 
 ## Branch
 
-**1/** @mrsteyk1
+**1/** **@mrsteyk1** ^1990655861749133343
 
-@valigo
+**@valigo**
 
 I had the displeasure of being exposed to Hex-Ray’s decompiler for years so I have gotten used to it, but it is annoying ye…
 
diff --git a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-25-levs57-interestingly-if-you-try-to-write-rust-in-this.md b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-25-levs57-interestingly-if-you-try-to-write-rust-in-this.md
index 0ab5c92..9be0dc5 100644
--- a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-25-levs57-interestingly-if-you-try-to-write-rust-in-this.md
+++ b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-25-levs57-interestingly-if-you-try-to-write-rust-in-this.md
@@ -26,9 +26,9 @@ parent_post_id: "1990506460531601538"
 
 ## Branch
 
-**1/** @levs57
+**1/** **@levs57** ^1993312449379127742
 
-@valigo
+**@valigo**
 
 Interestingly, if you try to write Rust in this way, pointer provenance will cause misoptimizations that break everything.
 
diff --git a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/index.md b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/index.md
index 3d9fced..96ff94f 100644
--- a/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/index.md
+++ b/archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/index.md
@@ -25,28 +25,28 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @valigo
+**1/** **@valigo** ^1990506460531601538
 
 When it comes to pointers, "just use 64 bit integer" is way more intuitive to me. I still remember how confusing it was that "pointer + 1" actually means "+ size_of(type_we_point_to)" when I learned all this stuff. It still kinda messes me up not gonna lie.
 
 Branches: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-mrsteyk1-i-had-the-displeasure-of-being-exposed-to-hex]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-attamayte1-pointer-arithmetic-based-on-type-sizes-makes]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-furiouswhopper-for-real-im-parsing-through-a-binary-array-and]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-TheBonkMaykr-it-is-confusing-if-you-arent-used-to-it-that-is]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-Ron172892111531-wouldnt-this-make-working-with-arrays-more]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-25-levs57-interestingly-if-you-try-to-write-rust-in-this]]
 
-**2/** @onelivesleft
+**2/** **@onelivesleft** ^1990525482295832860
 
-@valigo
+**@valigo**
 
 Distinct syntax for pointer arithmetic would be good. i.e. 
 ptr += 1; // ptr = ptr + 1;
 ptr ++= 1; // ptr = ptr + 1 * size_of(type_of(ptr));
 
-**3/** @valigo
+**3/** **@valigo** ^1990525680065577199
 
-@onelivesleft
+**@onelivesleft**
 
 Not sure I agree with specific sign choice but I kinda dig the concept
 
-**4/** @onelivesleft
+**4/** **@onelivesleft** ^1990526589470482553
 
-@valigo
+**@valigo**
 
 Well, you know, only applicable for languages that don't have a ++ :P
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-DanielcHooper-nice-when-you-combine-this-with-all-the-other.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-DanielcHooper-nice-when-you-combine-this-with-all-the-other.md
index 1987b56..385f56e 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-DanielcHooper-nice-when-you-combine-this-with-all-the-other.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-DanielcHooper-nice-when-you-combine-this-with-all-the-other.md
@@ -26,15 +26,15 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @DanielcHooper
+**1/** **@DanielcHooper** ^1749857446179299815
 
-@vkrajacic
+**@vkrajacic**
 
 Nice - when you combine this with all the other tricks (arenas, stretchy buffers, strings with length, etc), C is a really nice language to use!
 
-**2/** @vkrajacic
+**2/** **@vkrajacic** ^1749894222130397489
 
-@DanielcHooper
+**@DanielcHooper**
 
 Yes, C can almost feel like an entirely different language once you develop your own base technical layer.
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-MrJayLC-neat.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-MrJayLC-neat.md
index 04a8e71..ea4c5c7 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-MrJayLC-neat.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-MrJayLC-neat.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @MrJayLC
+**1/** **@MrJayLC** ^1749843481822900718
 
-@vkrajacic
+**@vkrajacic**
 
 Neat!
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-i-love-this.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-i-love-this.md
index 24506d7..dff0d4b 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-i-love-this.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-i-love-this.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @alurmanc
+**1/** **@alurmanc** ^1749842429367185567
 
-@vkrajacic
+**@vkrajacic**
 
 I love this!
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-shouldnt-it-be-transformarguments-parameters-are.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-shouldnt-it-be-transformarguments-parameters-are.md
index ed4cbfa..3d2411f 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-shouldnt-it-be-transformarguments-parameters-are.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-shouldnt-it-be-transformarguments-parameters-are.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @alurmanc
+**1/** **@alurmanc** ^1749843270354538761
 
-@vkrajacic
+**@vkrajacic**
 
 Shouldn't it be TransformArguments?
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-endu06-how-does-default-work-do-variable-args-bypass.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-endu06-how-does-default-work-do-variable-args-bypass.md
index 150693c..7e136e5 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-endu06-how-does-default-work-do-variable-args-bypass.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-endu06-how-does-default-work-do-variable-args-bypass.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @endu06
+**1/** **@endu06** ^1749930915566961088
 
-@vkrajacic
+**@vkrajacic**
 
 How does default work? Do variable args bypass duplicate designator in initializer?
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-luis_reyes_x-very-cool-designated-initializers-is-one-thing-i.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-luis_reyes_x-very-cool-designated-initializers-is-one-thing-i.md
index 155bc3b..f982e18 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-luis_reyes_x-very-cool-designated-initializers-is-one-thing-i.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-luis_reyes_x-very-cool-designated-initializers-is-one-thing-i.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @luis_reyes_x
+**1/** **@luis_reyes_x** ^1749940314951893348
 
-@vkrajacic
+**@vkrajacic**
 
 Very cool! Designated initializers is one thing I wish c++ had. C also lets you do a similar thing with arrays to initialize certain elements
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-24-falco_girgis-the-only-problem-here-is-that-you-cannot-do-this.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-24-falco_girgis-the-only-problem-here-is-that-you-cannot-do-this.md
index 3644558..205dbb3 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-24-falco_girgis-the-only-problem-here-is-that-you-cannot-do-this.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-24-falco_girgis-the-only-problem-here-is-that-you-cannot-do-this.md
@@ -26,18 +26,18 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @falco_girgis
+**1/** **@falco_girgis** ^1750088968681750741
 
 The only problem here is that you cannot do this in a header file that is going to be included within a C++ source file... However, what you can do is macro out the compound literal and provide a C++20 temporary object initializer with slightly different syntax if __cplusplus is defined..
 
-**2/** @vkrajacic
+**2/** **@vkrajacic** ^1750226315876122748
 
-@falco_girgis
+**@falco_girgis**
 
 Yeah, I haven't tested that because my codebase is purely C nowadays.
 I'm not concerned about compatibility with C++. I understand that this is not always a choice, especially when working with a codebase you didn't start.
 
-**3/** @falco_girgis
+**3/** **@falco_girgis** ^1750239118867546281
 
 Tbh, I've never encountered a scenario with supporting C++ where you couldn't still pull all the tricks like this with modern C, if you are willing to invest in the infrastructure... That includes using _Generic() switches, which aren't supported in C++... I have a macro layer which you use to declare each type and its associated call which will compile to a _Generic statement in C or... a to C++20 anonymous generic lambda doing a series of compile-time conditionals on the generic type argument and mapping it to the appropriate logic based on its type... Yeah, it's a shitshow, but you write it once and it just works. lol. https://github.com/gyrovorbis/libgimbal/blob/79722a270d2a80651d08eb0158e803c9e4a2de6e/lib/api/gimbal/utils/gimbal_scanner.h#L366
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-JLakness-c-functor-method.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-JLakness-c-functor-method.md
index 6bcf250..abb9083 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-JLakness-c-functor-method.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-JLakness-c-functor-method.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @JLakness
+**1/** **@JLakness** ^1955779942689726670
 
-@vkrajacic
+**@vkrajacic**
 
 C++ functor method
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-YehorAvramenko-this-one-is-amazing-to-be-honest.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-YehorAvramenko-this-one-is-amazing-to-be-honest.md
index 2b0831c..e50207c 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-YehorAvramenko-this-one-is-amazing-to-be-honest.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-YehorAvramenko-this-one-is-amazing-to-be-honest.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @YehorAvramenko
+**1/** **@YehorAvramenko** ^1955676990754934991
 
-@vkrajacic
+**@vkrajacic**
 
 this one is amazing to be honest
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-gretzky00-havent-gotten-to-this-place-i-gotta-keep-pushing.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-gretzky00-havent-gotten-to-this-place-i-gotta-keep-pushing.md
index e0b9a27..3d6f51a 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-gretzky00-havent-gotten-to-this-place-i-gotta-keep-pushing.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-gretzky00-havent-gotten-to-this-place-i-gotta-keep-pushing.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @gretzky00
+**1/** **@gretzky00** ^1955713762163409316
 
-@vkrajacic
+**@vkrajacic**
 
 Haven't gotten to this place, I gotta keep pushing forward till I get gigachad levels like you
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-heyitsvaishnav-this-is-soo-good-i-did-it-in-typescript-as-well.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-heyitsvaishnav-this-is-soo-good-i-did-it-in-typescript-as-well.md
index dac5299..557f79f 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-heyitsvaishnav-this-is-soo-good-i-did-it-in-typescript-as-well.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-heyitsvaishnav-this-is-soo-good-i-did-it-in-typescript-as-well.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @heyitsvaishnav
+**1/** **@heyitsvaishnav** ^1955715131293491311
 
-@vkrajacic
+**@vkrajacic**
 
 This is soo good, I did it in Typescript as well and my life is easier now........
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-peach2k2-really-cool-but-this-doesnt-mean-c-is-a-good-or.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-peach2k2-really-cool-but-this-doesnt-mean-c-is-a-good-or.md
index 6a37fcb..0c59c9c 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-peach2k2-really-cool-but-this-doesnt-mean-c-is-a-good-or.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-peach2k2-really-cool-but-this-doesnt-mean-c-is-a-good-or.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @peach2k2
+**1/** **@peach2k2** ^1955706381077496306
 
-@vkrajacic
+**@vkrajacic**
 
 really cool, but this doesn't mean c is a good or nice language in modern standards.
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-EskilSteenberg-am-i-the-only-one-who-thinks-this-is-terrible-its.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-EskilSteenberg-am-i-the-only-one-who-thinks-this-is-terrible-its.md
index df65615..d6d010f 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-EskilSteenberg-am-i-the-only-one-who-thinks-this-is-terrible-its.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-EskilSteenberg-am-i-the-only-one-who-thinks-this-is-terrible-its.md
@@ -26,21 +26,21 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @EskilSteenberg
+**1/** **@EskilSteenberg** ^1955882027997069711
 
-@vkrajacic @CaptainKraft
+**@vkrajacic** **@CaptainKraft**
 
 Am i the only one who thinks this is terrible? Its incredibly confusing to read and you cant see what parameters you miss, the header file is a lot more complex to read too. You lose the WYIWYG nature of C. If you want this kind of ”clever” syntax why not use C++?
 
-**2/** @vkrajacic
+**2/** **@vkrajacic** ^1955891241201127767
 
 It might be confusing the first time you encounter it, because it's not used often in C codebases. But that's true for a lot of things in C, since you often have to invent better solutions (like strings or memory arenas).
 As I said, I use this sparingly, but where it is used, it has always provided a better API. Ideally, I strive for ZII, so I don’t need a way of setting default values and can use a designated initializers to override when needed. That’s the best case scenario, and most of my base layer functions work like that.
 This will not work with C++, as far as I know, because they messed up designated initializers. There are probably other ways to do it there, but I don’t want C++.
 
-**3/** @EskilSteenberg
+**3/** **@EskilSteenberg** ^1955902981704180163
 
-@vkrajacic @CaptainKraft
+**@vkrajacic** **@CaptainKraft**
 
 I think its confusing every time you see it. If i read:
 
@@ -50,7 +50,7 @@ The code does not communicate, what this function can do or if I'm missing a par
 
 You also have to read all parameters in the function with one more level of indirection and thats slow.
 
-**4/** @vkrajacic
+**4/** **@vkrajacic** ^1955906904330297594
 
 I don’t see how this is different from:
 void PushTransform(Rect rect, TransformParams params);
@@ -65,9 +65,9 @@ The first one just calls the Ex version with some reasonable defaults.
 
 This works fine in most cases, but if you have a lot of arguments, you either have to make many such function permutations or force the caller to pass in all arguments, even the ones they don’t care about.
 
-**5/** @EskilSteenberg
+**5/** **@EskilSteenberg** ^1955943723918921910
 
-@vkrajacic @CaptainKraft
+**@vkrajacic** **@CaptainKraft**
 
 I don't like:
 
@@ -75,7 +75,7 @@ void func(StructOfInputs params);
 
 You are hiding the input, and you are forcing a memory layout. I don't even like small structs like Dim2, and Rect because they force the caller to adopt the structures of the callee. Don't force me to live in your world.
 
-**6/** @vkrajacic
+**6/** **@vkrajacic** ^1955966202896920993
 
 There’s no hiding of any kind, it’s a public POD struct.
 
@@ -88,54 +88,54 @@ RectCreate(f32 minX, f32 minY, f32 maxX, f32 maxY);
 
 Yes, it enforces memory layout, but that’s kind of the point of structs, bundling data that gets used together. And vectors are a prime example of that, especially in games and renderers, because they act as primitives and are ubiquitous throughout the code.
 
-**7/** @vkrajacic
+**7/** **@vkrajacic** ^1955966771141230709
 
-@EskilSteenberg @CaptainKraft
+**@EskilSteenberg** **@CaptainKraft**
 
 Another example in my codebase would be length based strings. I’ve built the whole API on top of those. I don’t want to go around passing char *value, int length. The point of that abstraction is that I don’t have to do that.
 
-**8/** @nicbarkeragain
+**8/** **@nicbarkeragain** ^1956132278159192430
 
-@vkrajacic @EskilSteenberg @CaptainKraft
+**@vkrajacic** **@EskilSteenberg** **@CaptainKraft**
 
 I don't think I could ever go back to writing C with naked arrays / strings. It's such a small cost to pass length (and capacity) around, it's so simple and makes C feel like a different language.
 
-**9/** @daniel_collin
+**9/** **@daniel_collin** ^1956288958100324653
 
-@nicbarkeragain @vkrajacic @EskilSteenberg @CaptainKraft
+**@nicbarkeragain** **@vkrajacic** **@EskilSteenberg** **@CaptainKraft**
 
 Yeah, I'm building a whole new C codebase and I'm having a String type for sure. Makes things just nicer.
 
-**10/** @NotAttained
+**10/** **@NotAttained** ^1956025229047693468
 
-@EskilSteenberg @vkrajacic @CaptainKraft
+**@EskilSteenberg** **@vkrajacic** **@CaptainKraft**
 
 What is the alternative though if it’s a big struct, do you just manually type out the parameters each time, even if they are largely the same?
 
-**11/** @EskilSteenberg
+**11/** **@EskilSteenberg** ^1956035840863252846
 
-@NotAttained @vkrajacic @CaptainKraft
+**@NotAttained** **@vkrajacic** **@CaptainKraft**
 
 YES! Having to declare a variable of the struct an then assigning every member is far more cumbersome and error prone.
 
-**12/** @vkrajacic
+**12/** **@vkrajacic** ^1956083523120492831
 
 It is if you're typing them all out. But the whole point of the post was about when you DON'T want to do that.
 Ideally, you'd have them zero initialized or set with some default arguments, and then just override the ones you want, via designated initializer syntax.
 At that point, it becomes less cumbersome and less error prone, because the defaults are already set up for you. You don’t have to write them again.
 If you have lots of parameters, it's almost always the case that you don't need to set each one at the call site. If you only have a few, then a struct is unnecessary.
 
-**13/** @vkrajacic
+**13/** **@vkrajacic** ^1956084512217338077
 
-@EskilSteenberg @NotAttained @CaptainKraft
+**@EskilSteenberg** **@NotAttained** **@CaptainKraft**
 
 For instance, old win APIs often take a long list of parameters. In many cases, you only need a couple of options and pass 0 to everything else, e.g. NtQueryDirectoryFile.
 
 ![](https://pbs.twimg.com/media/GyVoVhQWcAUqchq?format=png&name=orig)
 
-**14/** @Karyuutensei
+**14/** **@Karyuutensei** ^1956124826558468255
 
-@vkrajacic @EskilSteenberg @NotAttained @CaptainKraft
+**@vkrajacic** **@EskilSteenberg** **@NotAttained** **@CaptainKraft**
 
 To be honest, function parameters get confusing beyond 2-3. Named parameters are much better.
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-FrawaMudi-honestly-i-dont-know-what-i-am-looking-at-anymore.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-FrawaMudi-honestly-i-dont-know-what-i-am-looking-at-anymore.md
index 2025112..9070e1e 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-FrawaMudi-honestly-i-dont-know-what-i-am-looking-at-anymore.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-FrawaMudi-honestly-i-dont-know-what-i-am-looking-at-anymore.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @FrawaMudi
+**1/** **@FrawaMudi** ^1955896975330582796
 
-@vkrajacic
+**@vkrajacic**
 
 Honestly I don't know what I am looking at anymore
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-emh203-bravo.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-emh203-bravo.md
index 1a7bb36..a224ed8 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-emh203-bravo.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-emh203-bravo.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @emh203
+**1/** **@emh203** ^1955793903548031362
 
-@vkrajacic
+**@vkrajacic**
 
 Bravo!
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-etozheya42-lets-go-10k-likes.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-etozheya42-lets-go-10k-likes.md
index 6e74523..c9a9cbe 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-etozheya42-lets-go-10k-likes.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-etozheya42-lets-go-10k-likes.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @etozheya42
+**1/** **@etozheya42** ^1955797197108236796
 
-@vkrajacic
+**@vkrajacic**
 
 Let's go 10k likes.
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-quantized_state-instantly-rewriting-everything.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-quantized_state-instantly-rewriting-everything.md
index 70da6d8..ce69779 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-quantized_state-instantly-rewriting-everything.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-quantized_state-instantly-rewriting-everything.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @quantized_state
+**1/** **@quantized_state** ^1955925511575888092
 
-@vkrajacic
+**@vkrajacic**
 
 instantly rewriting everything
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-siddhantCodes-this-is-so-cool.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-siddhantCodes-this-is-so-cool.md
index aa51046..545af27 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-siddhantCodes-this-is-so-cool.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-siddhantCodes-this-is-so-cool.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @siddhantCodes
+**1/** **@siddhantCodes** ^1955847027704627626
 
-@vkrajacic
+**@vkrajacic**
 
 This is so cool!
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-15-k00lagin-i-may-be-just-one-like-but-together-we-build-the.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-15-k00lagin-i-may-be-just-one-like-but-together-we-build-the.md
index b1ae9bb..b18bbca 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-15-k00lagin-i-may-be-just-one-like-but-together-we-build-the.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-15-k00lagin-i-may-be-just-one-like-but-together-we-build-the.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @k00lagin
+**1/** **@k00lagin** ^1956460989324710205
 
-@vkrajacic
+**@vkrajacic**
 
 I may be just one like, but together we build the whole 10k.
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-12-29-CarloIlCugino-thank-you.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-12-29-CarloIlCugino-thank-you.md
index d4ccd8a..a7c1928 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-12-29-CarloIlCugino-thank-you.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-12-29-CarloIlCugino-thank-you.md
@@ -26,9 +26,9 @@ parent_post_id: "1749816169736073295"
 
 ## Branch
 
-**1/** @CarloIlCugino
+**1/** **@CarloIlCugino** ^2005479710604894610
 
-@vkrajacic
+**@vkrajacic**
 
 thank you!
 
diff --git a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/index.md b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/index.md
index bbd22b3..f55246d 100644
--- a/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/index.md
+++ b/archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/index.md
@@ -25,7 +25,7 @@ in_reply_to: ""
 
 ## Thread
 
-**1/** @vkrajacic
+**1/** **@vkrajacic** ^1749816169736073295
 
 C macro approach to using optional / default / named function params, using struct designated initializers.
 Mandatory values are passed first as standard function params (rect in the example).
@@ -35,8 +35,8 @@ Especially useful when a zero value can be made a valid value.
 
 Branches: [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-i-love-this]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-alurmanc-shouldnt-it-be-transformarguments-parameters-are]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-MrJayLC-neat]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-DanielcHooper-nice-when-you-combine-this-with-all-the-other]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-endu06-how-does-default-work-do-variable-args-bypass]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-23-luis_reyes_x-very-cool-designated-initializers-is-one-thing-i]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2024-01-24-falco_girgis-the-only-problem-here-is-that-you-cannot-do-this]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-YehorAvramenko-this-one-is-amazing-to-be-honest]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-peach2k2-really-cool-but-this-doesnt-mean-c-is-a-good-or]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-gretzky00-havent-gotten-to-this-place-i-gotta-keep-pushing]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-heyitsvaishnav-this-is-soo-good-i-did-it-in-typescript-as-well]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-13-JLakness-c-functor-method]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-emh203-bravo]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-etozheya42-lets-go-10k-likes]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-siddhantCodes-this-is-so-cool]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-EskilSteenberg-am-i-the-only-one-who-thinks-this-is-terrible-its]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-FrawaMudi-honestly-i-dont-know-what-i-am-looking-at-anymore]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-14-quantized_state-instantly-rewriting-everything]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-08-15-k00lagin-i-may-be-just-one-like-but-together-we-build-the]], [[archive/threads/vkrajacic/2024-01-23-c-macro-approach-to-using-optional-default-named/2025-12-29-CarloIlCugino-thank-you]]
 
-**2/** @pATjako
+**2/** **@pATjako** ^1749816924685672759
 
-@vkrajacic
+**@vkrajacic**
 
 I started experimenting with that in my imgui as well, it is kinda neat, also you can make the same code work for C & C++ (with some limitation in argument ordering)
diff --git a/archive/threads/winning_tactic/2026-06-07-i-see/index.md b/archive/threads/winning_tactic/2026-06-07-i-see/index.md
index bbe229b..aead28d 100644
--- a/archive/threads/winning_tactic/2026-06-07-i-see/index.md
+++ b/archive/threads/winning_tactic/2026-06-07-i-see/index.md
@@ -27,8 +27,8 @@ in_reply_to: "2063730754861822129"
 
 ## Thread
 
-**1/** @winning_tactic
+**1/** **@winning_tactic** ^2063733456144597200
 
-@NOTimothyLottes
+**@NOTimothyLottes**
 
 I see!
diff --git a/notes/How threads are organized.md b/notes/How threads are organized.md
index 455d7f2..a0f8555 100644
--- a/notes/How threads are organized.md	
+++ b/notes/How threads are organized.md	
@@ -47,3 +47,9 @@ Pictures on the site are the original host URLs. Working copies live outside wha
 ## Reading
 
 Start at [[archive/threads/index|Threads]], pick a handle, then a date. The spine is the essay. Branch files are the conversation around it.
+
+On the site: click an image to enlarge it (Esc or click to close). Use **Wide** to grow the reading column.
+
+To point a note at one reply, wikilink the block id on that post:
+
+`[[archive/threads/SebAaltonen/2025-03-08-stupid-hardware-question-why-does-amd-use-several/2025-03-08-NOTimothyLottes-actually-this-is-a-super-important-question-imo#^1898440015182729598]]`
diff --git a/publish/quartz-patches/apply.py b/publish/quartz-patches/apply.py
index 5182f40..031a080 100644
--- a/publish/quartz-patches/apply.py
+++ b/publish/quartz-patches/apply.py
@@ -78,6 +78,10 @@ BASE_RE: re.Pattern[str] = re.compile(
 TITLE_LINK: re.Pattern[str] = re.compile(
     r'(<h2[^>]*class="page-title"><a\s+href=")[^"]*(">)'
 )
+SCRIPT_TAG: str = (
+    '<script src="/static/threadwell-reader.js" defer></script>'
+)
+BODY_CLOSE: re.Pattern[str] = re.compile(r"</body>", re.IGNORECASE)
 
 
 # --- SPA click-handler patch ----------------------------------------------
@@ -200,6 +204,9 @@ def rewrite_html(path: Path) -> str | None:
         if out2 != out:
             out = out2
             actions.append("title")
+    if SCRIPT_TAG not in out and BODY_CLOSE.search(out):
+        out = BODY_CLOSE.sub(SCRIPT_TAG + "\n</body>", out, count=1)
+        actions.append("script")
 
     if out != text:
         path.write_text(out, encoding="utf-8")
diff --git a/publish/quartz.custom.scss b/publish/quartz.custom.scss
index 43b3279..e3b3ba6 100644
--- a/publish/quartz.custom.scss
+++ b/publish/quartz.custom.scss
@@ -2,9 +2,60 @@
 
 .page > #quartz-body {
   @media all and ($desktop) {
-    grid-template-columns: 420px auto 280px;
+    grid-template-columns: 260px minmax(0, 1fr) 220px;
   }
   @media all and ($tablet) {
-    grid-template-columns: 420px auto;
+    grid-template-columns: 260px minmax(0, 1fr);
   }
 }
+
+body.threadwell-wide .page > #quartz-body {
+  @media all and ($desktop) {
+    grid-template-columns: 0 minmax(0, 1fr) 0;
+  }
+  @media all and ($tablet) {
+    grid-template-columns: 0 minmax(0, 1fr);
+  }
+}
+
+body.threadwell-wide .page > #quartz-body > .left,
+body.threadwell-wide .page > #quartz-body > .right {
+  display: none;
+}
+
+article img {
+  cursor: zoom-in;
+  max-width: 100%;
+  height: auto;
+}
+
+.threadwell-wide-btn {
+  position: fixed;
+  right: 1rem;
+  bottom: 1rem;
+  z-index: 40;
+  padding: 0.4rem 0.7rem;
+  border: 1px solid var(--gray);
+  border-radius: 6px;
+  background: var(--light);
+  color: var(--dark);
+  cursor: pointer;
+}
+
+.threadwell-zoom {
+  position: fixed;
+  inset: 0;
+  z-index: 80;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  background: rgba(0, 0, 0, 0.88);
+  cursor: zoom-out;
+}
+
+.threadwell-zoom img {
+  max-width: 96vw;
+  max-height: 96vh;
+  object-fit: contain;
+  cursor: zoom-out;
+}
diff --git a/publish/setup.ps1 b/publish/setup.ps1
index 9b497df..926501d 100644
--- a/publish/setup.ps1
+++ b/publish/setup.ps1
@@ -8,6 +8,11 @@ if (-not (Test-Path -LiteralPath (Join-Path $site ".git"))) {
 
 Copy-Item -LiteralPath $config -Destination (Join-Path $site "quartz.config.yaml") -Force
 Copy-Item -LiteralPath (Join-Path $PSScriptRoot "quartz.custom.scss") -Destination (Join-Path $site "quartz\styles\custom.scss") -Force
+$static = Join-Path $site "quartz\static"
+if (-not (Test-Path -LiteralPath $static)) {
+  New-Item -ItemType Directory -Path $static | Out-Null
+}
+Copy-Item -LiteralPath (Join-Path $PSScriptRoot "threadwell-reader.js") -Destination (Join-Path $static "threadwell-reader.js") -Force
 Set-Location -LiteralPath $site
 npm ci
 npx quartz plugin install --from-config
diff --git a/publish/threadwell-reader.js b/publish/threadwell-reader.js
new file mode 100644
index 0000000..29f6b64
--- /dev/null
+++ b/publish/threadwell-reader.js
@@ -0,0 +1,86 @@
+(() => {
+  const WIDE_KEY = "threadwell-wide";
+
+  function articleRoot() {
+    return document.querySelector("article");
+  }
+
+  function setWide(on) {
+    document.body.classList.toggle("threadwell-wide", on);
+    try {
+      localStorage.setItem(WIDE_KEY, on ? "1" : "0");
+    } catch (_err) {
+      /* ignore */
+    }
+    const btn = document.getElementById("threadwell-wide");
+    if (btn) {
+      btn.setAttribute("aria-pressed", on ? "true" : "false");
+      btn.textContent = on ? "Narrow" : "Wide";
+    }
+  }
+
+  function addWideButton() {
+    if (document.getElementById("threadwell-wide")) {
+      return;
+    }
+    const btn = document.createElement("button");
+    btn.id = "threadwell-wide";
+    btn.type = "button";
+    btn.className = "threadwell-wide-btn";
+    btn.textContent = "Wide";
+    btn.addEventListener("click", () => {
+      setWide(!document.body.classList.contains("threadwell-wide"));
+    });
+    document.body.appendChild(btn);
+    try {
+      if (localStorage.getItem(WIDE_KEY) === "1") {
+        setWide(true);
+      }
+    } catch (_err) {
+      /* ignore */
+    }
+  }
+
+  function closeZoom() {
+    const overlay = document.getElementById("threadwell-zoom");
+    if (overlay) {
+      overlay.remove();
+    }
+  }
+
+  function openZoom(src) {
+    closeZoom();
+    const overlay = document.createElement("div");
+    overlay.id = "threadwell-zoom";
+    overlay.className = "threadwell-zoom";
+    const img = document.createElement("img");
+    img.src = src;
+    img.alt = "";
+    overlay.appendChild(img);
+    overlay.addEventListener("click", closeZoom);
+    document.body.appendChild(overlay);
+  }
+
+  function onArticleClick(event) {
+    const target = event.target;
+    if (!(target instanceof HTMLImageElement)) {
+      return;
+    }
+    if (!articleRoot() || !articleRoot().contains(target)) {
+      return;
+    }
+    if (target.closest("#threadwell-zoom")) {
+      return;
+    }
+    event.preventDefault();
+    openZoom(target.currentSrc || target.src);
+  }
+
+  document.addEventListener("keydown", (event) => {
+    if (event.key === "Escape") {
+      closeZoom();
+    }
+  });
+  document.addEventListener("click", onArticleClick);
+  addWideButton();
+})();
diff --git a/scripts/twitter/emit_archive.py b/scripts/twitter/emit_archive.py
index 1c1287b..1ca94f5 100644
--- a/scripts/twitter/emit_archive.py
+++ b/scripts/twitter/emit_archive.py
@@ -796,7 +796,7 @@ def emit_all(
 
 
 _NUMBER_LINE: re.Pattern[str] = re.compile(
-    r"^(\*\*(\d+)/\*\*)(?: +@([A-Za-z0-9_]+))?[ \t]*$",
+    r"^(\*\*(\d+)/\*\*)(?: +(?:\*\*)?@([A-Za-z0-9_]+)(?:\*\*)?)?(?: +\^([A-Za-z0-9_]+))?[ \t]*$",
     re.MULTILINE,
 )
 
@@ -858,6 +858,20 @@ def _frontmatter_handle(text: str) -> str:
     return ""
 
 
+def _frontmatter_post_id(text: str) -> str:
+    """Return the note-root ``post_id:`` value, or empty."""
+    in_front = False
+    for line in text.splitlines():
+        if line.strip() == "---":
+            if in_front:
+                return ""
+            in_front = True
+            continue
+        if in_front and line.startswith("post_id:"):
+            return line.split(":", 1)[1].strip().strip("\"'")
+    return ""
+
+
 def _body_match_keys(body: str) -> set[str]:
     """Keys used to pair a note body with ``post.text`` before or after mention split."""
     mentions, rest = split_leading_mentions(body)
@@ -935,12 +949,15 @@ def patch_note_text(text: str, posts: tuple) -> tuple[str, str, str]:
         body = _extract_post_body(text[match.end():end])
         post = match_post_for_body(body, posts, used)
         handle = ""
+        post_id = ""
         if post is not None:
             handle = str(post.handle or "")
+            post_id = str(post.post_id or "")
             if handle:
                 used.add(post.post_id)
         if not handle and index == 0 and root_handle:
             handle = root_handle
+            post_id = _frontmatter_post_id(text)
         region = text[match.end():end]
         if not handle:
             unmatched.append(f"**{number}/**")
@@ -948,7 +965,9 @@ def patch_note_text(text: str, posts: tuple) -> tuple[str, str, str]:
             pieces.append(region)
             last = end
             continue
-        new_line = f"**{number}/** @{handle}"
+        new_line = f"**{number}/** **@{handle}**"
+        if post_id:
+            new_line += f" ^{post_id}"
         if new_line != match.group(0).rstrip():
             changed = True
         formatted = format_post_text(body)
diff --git a/scripts/twitter/render.py b/scripts/twitter/render.py
index ec33b9e..fcd8f92 100644
--- a/scripts/twitter/render.py
+++ b/scripts/twitter/render.py
@@ -102,7 +102,7 @@ def _source_block(post: PostData) -> str:
 
 
 _LEADING_MENTIONS: re.Pattern[str] = re.compile(
-    r"^((?:@[A-Za-z0-9_]+(?:[ \t]+@[A-Za-z0-9_]+)*)[ \t]*)(.*)$",
+    r"^((?:(?:\*\*)?@[A-Za-z0-9_]+(?:\*\*)?(?:[ \t]+(?:\*\*)?@[A-Za-z0-9_]+(?:\*\*)?)*)[ \t]*)(.*)$",
     re.DOTALL,
 )
 
@@ -113,21 +113,34 @@ def split_leading_mentions(text: str) -> tuple[str, str]:
     match = _LEADING_MENTIONS.match(raw)
     if match is None:
         return "", raw
-    mentions = " ".join(match.group(1).split())
+    mentions = " ".join(
+        part.strip("*") for part in match.group(1).split() if part.strip("*")
+    )
     rest = match.group(2).lstrip(" \t")
     if rest.startswith("\n"):
         rest = rest.lstrip("\n")
     return mentions, rest
 
 
+def format_mention_line(mentions: str) -> str:
+    """Bold each leading reply handle."""
+    handles = [
+        part.strip("*")
+        for part in mentions.split()
+        if part.strip("*").startswith("@")
+    ]
+    return " ".join(f"**{handle}**" for handle in handles)
+
+
 def format_post_text(text: str) -> str:
-    """Put leading reply mentions on their own line, then the tweet body."""
+    """Put leading reply mentions on their own bold line, then the tweet body."""
     mentions, rest = split_leading_mentions(text)
     if not mentions:
         return text
+    line = format_mention_line(mentions)
     if not rest:
-        return mentions
-    return f"{mentions}\n\n{rest}"
+        return line
+    return f"{line}\n\n{rest}"
 
 
 def _post_block(
@@ -136,10 +149,11 @@ def _post_block(
     media_by_post: dict[str, tuple[str, ...]] | None,
     branch_links: list[str] | None = None,
 ) -> str:
-    """Render one post body (``**N/** @handle`` + text + media + branch links)."""
+    """Render one post: number, bold speaker, block id, mentions, text, media."""
     if not post.handle:
         raise ValueError(f"empty handle on post {post.post_id}")
-    parts = [f"**{n}/** @{post.handle}", "", format_post_text(post.text)]
+    head = f"**{n}/** **@{post.handle}** ^{post.post_id}"
+    parts = [head, "", format_post_text(post.text)]
     media = (media_by_post or {}).get(post.post_id) or ()
     if media:
         parts.append("")
diff --git a/scripts/twitter/tests/test_reply_attribution.py b/scripts/twitter/tests/test_reply_attribution.py
index 4c6739f..009e912 100644
--- a/scripts/twitter/tests/test_reply_attribution.py
+++ b/scripts/twitter/tests/test_reply_attribution.py
@@ -43,7 +43,9 @@ class PostBlockAttributionTests(unittest.TestCase):
             post("1898440015182729598", "SebAaltonen", "WG_RR_EN", "1"),
             None,
         )
-        self.assertTrue(block.startswith("**19/** @SebAaltonen\n"))
+        self.assertTrue(
+            block.startswith("**19/** **@SebAaltonen** ^1898440015182729598\n")
+        )
         self.assertIn("WG_RR_EN", block)
 
     def test_empty_handle_raises(self) -> None:
@@ -61,12 +63,19 @@ class PostBlockAttributionTests(unittest.TestCase):
             ),
             None,
         )
-        self.assertIn("**19/** @SebAaltonen\n\n@NOTimothyLottes\n\nI said WG_RR_EN", block)
+        self.assertIn(
+            "**19/** **@SebAaltonen** ^1898440015182729598\n\n"
+            "**@NOTimothyLottes**\n\nI said WG_RR_EN",
+            block,
+        )
 
     def test_format_post_text_is_idempotent(self) -> None:
         original = "@AgileJebrim @SebAaltonen The higher the occupancy"
         once = format_post_text(original)
-        self.assertEqual(once, "@AgileJebrim @SebAaltonen\n\nThe higher the occupancy")
+        self.assertEqual(
+            once,
+            "**@AgileJebrim** **@SebAaltonen**\n\nThe higher the occupancy",
+        )
         self.assertEqual(format_post_text(once), once)
         self.assertEqual(split_leading_mentions("holy truthnuke")[0], "")
 
@@ -83,9 +92,9 @@ class RenderAttributionTests(unittest.TestCase):
             source_url="https://x.com/rianflo/status/1",
         )
         text = render_spine(thread, ["1", "2", "3"], [], {}, "2026-08-25")
-        self.assertIn("**1/** @rianflo", text)
-        self.assertIn("**2/** @NOTimothyLottes", text)
-        self.assertIn("**3/** @rianflo", text)
+        self.assertIn("**1/** **@rianflo** ^1", text)
+        self.assertIn("**2/** **@NOTimothyLottes** ^2", text)
+        self.assertIn("**3/** **@rianflo** ^3", text)
 
     def test_mixed_branch_labels_seb_and_jebrim(self) -> None:
         thread = ThreadData(
@@ -120,12 +129,15 @@ class RenderAttributionTests(unittest.TestCase):
             "SebAaltonen",
             "2026-08-25",
         )
-        self.assertIn("**1/** @NOTimothyLottes", text)
-        self.assertIn("**2/** @SebAaltonen", text)
-        self.assertIn("**3/** @AgileJebrim", text)
+        self.assertIn("**1/** **@NOTimothyLottes** ^1898352640825651644", text)
+        self.assertIn("**2/** **@SebAaltonen** ^1898440015182729598", text)
+        self.assertIn("**3/** **@AgileJebrim** ^1898385745892495810", text)
         for line in text.splitlines():
-            if line.startswith("**") and "/**" in line:
-                self.assertRegex(line, r"^\*\*\d+/\*\* @[A-Za-z0-9_]+$")
+            if "/**" in line and line.startswith("**"):
+                self.assertRegex(
+                    line,
+                    r"^\*\*\d+/\*\* \*\*@[A-Za-z0-9_]+\*\* \^[A-Za-z0-9_]+$",
+                )
 
 
 class RelabelPatchTests(unittest.TestCase):
@@ -229,11 +241,11 @@ class RelabelPatchTests(unittest.TestCase):
                 b'{"schema_version": 2, "root_post_id": "root", "items": []}\n'
             ))
             branch = (notes / "branch.md").read_text(encoding="utf-8")
-            self.assertIn("**19/** @SebAaltonen", branch)
-            self.assertIn("**33/** @AgileJebrim", branch)
+            self.assertIn("**19/** **@SebAaltonen** ^1898440015182729598", branch)
+            self.assertIn("**33/** **@AgileJebrim** ^1898385745892495810", branch)
             self.assertIn("1. **Onat Turkcuoglu** (@onatt0) - Apr 30", branch)
             index = (notes / "index.md").read_text(encoding="utf-8")
-            self.assertIn("**1/** @SebAaltonen", index)
+            self.assertIn("**1/** **@SebAaltonen** ^root", index)
             self.assertIn("  - vulkan", index)
             self.assertIn("draft: false", index)
 
@@ -241,17 +253,18 @@ class RelabelPatchTests(unittest.TestCase):
         with TemporaryDirectory() as raw:
             vault, _asset, notes = self._vault(raw)
             (notes / "index.md").write_text(
-                "---\ndraft: false\n---\n\n**1/** @SebAaltonen\n\n"
+                "---\ndraft: false\n---\n\n"
+                "**1/** **@SebAaltonen** ^root\n\n"
                 "Stupid hardware question\n",
                 encoding="utf-8",
                 newline="\n",
             )
             (notes / "branch.md").write_text(
                 "---\ndraft: false\n---\n\n"
-                "**19/** @SebAaltonen\n\n"
-                "@NOTimothyLottes\n\n"
+                "**19/** **@SebAaltonen** ^1898440015182729598\n\n"
+                "**@NOTimothyLottes**\n\n"
                 "I said WG_RR_EN\n\n"
-                "**33/** @AgileJebrim\n\n"
+                "**33/** **@AgileJebrim** ^1898385745892495810\n\n"
                 "On the flip side, it appears that using 128\n",
                 encoding="utf-8",
                 newline="\n",
@@ -280,7 +293,8 @@ class RelabelPatchTests(unittest.TestCase):
         new, state, reason = patch_note_text(text, posts)
         self.assertEqual(state, "rewrite")
         self.assertEqual(reason, "")
-        self.assertIn("@NOTimothyLottes\n\nI said WG_RR_EN", new)
+        self.assertIn("**@NOTimothyLottes**\n\nI said WG_RR_EN", new)
+        self.assertIn("**19/** **@SebAaltonen** ^1898440015182729598", new)
         again, state2, _reason = patch_note_text(new, posts)
         self.assertEqual(state2, "noop")
         self.assertEqual(again, new)
@@ -296,8 +310,8 @@ class RelabelPatchTests(unittest.TestCase):
         new, state, reason = patch_note_text(text, posts)
         self.assertEqual(state, "rewrite")
         self.assertEqual(reason, "")
-        self.assertIn("**30/** @simplex_fx", new)
-        self.assertIn("**31/** @simplex_fx", new)
+        self.assertIn("**30/** **@simplex_fx** ^1", new)
+        self.assertIn("**31/** **@simplex_fx** ^2", new)
 
     def test_empty_handle_is_conflict(self) -> None:
         with TemporaryDirectory() as raw: