docs(twitter): add 27 new NOTimothyLottes threads (Jul 2026 Linux dev bringup)

Processed 38 URLs from the user's list. 1 was already in the corpus
(2072194202851549432). 9 were duplicates within the new batch (same
post IDs at different anchor URLs); removed those. This commit
contains the 27 unique new threads.

Content spans the Jul 2026 era and is mostly Lottes's Linux
development environment bringup work:
- 1674757854471806977: 'Nothing Oriented Programming' (NOP) philosophy
- 1990260050485797063: reversed projection matrices
- 2030722033286328426: STP conspiracy theory
- 2058166883044516181: 'crap-o-grammers' C++ bloat-ware critique
- 2060191401883619479: relevant timestamp article
- 2060730425929080874: CPU clock code (TSC)
- 2061123768429211767: no-debugger-debug + mmap log pre-history
- 2061416116694442141: Windows thread priority
- 2061933917137932437: mmap'd page file
- 2061937134756380682: Windows HIGHEST_PRIORITY_CLASS
- 2062031187023982879: back running 640x480 on VGA CRTs
- 2064858927829745887: on Linux now (SteamOS)
- 2065804972378243476: nanorc done + iPhone font issue
- 2065832746757341482: cross compilation up
- 2065872197147578751: @axelgneiting bypassing libc
- 2066184005632786736: Linux mlockall
- 2070337342854832468: why not pselect/ppoll/epoll_pwait2
- 2070734717825986566: deterrant to ALSA = parsing through snd_pcm_open
- 2071415096304193820: aplay to actually play a wave file
- 2071706805114216559: 'ALSA hell month continues'
- 2071937360288235902: Linux thread priority code
- 2072135292115427728: Linux doesn't allow priority increase by default
- 2072445315370590266: 'Wine workarounds - I could just detect'
- 2072506103401754653: snd_pcm_sw_params for ALSA
- 2072804183992922296: starting on WDM/KS audio for WIN32
- 2073096069529907441: re-trying WASAPI
- 2073110092447203466: CPP_(obj) for mmdeviceapi

Cleanup: removed 9 duplicate dirs (same posts at different anchor URLs),
script temp files, and the '1857803914604618029' which was already a
duplicate of '1857820858162753661' (mmap log canonical).

docs/twitter/2060730425929080874/thread.md

@@ -0,0 +1,41 @@
+---
+title: "Renovating CPU clock code. I'm assuming x86-64 TSC is always >= 1 GHz so that co"
+author: "NOTimothyLottes"
+handle: "@NOTimothyLottes"
+post_url: "https://x.com/NOTimothyLottes/status/2060730425929080874"
+post_id: "2060730425929080874"
+timestamp: "2026-05-30 14:29:54"
+post_count: 6
+reply_count: 3
+repost_count: 0
+like_count: 40
+view_count: 4744
+---
+
+# @NOTimothyLottes — Renovating CPU clock code. I'm assuming x86-64 TSC is always >= 1 GHz so that co
+
+## Post 1 (2026-05-30 14:29:54)
+
+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.
+
+![Media 1](./media/2060730425929080874_1.png)
+
+## Post 2 (2026-05-30 15:16:24) — reply to Post 1
+
+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
+
+## Post 3 (2026-05-30 15:59:17) — reply to Post 2
+
+https://gist.github.com/pmttavara/6f06fc5c7679c07375483b06bb77430c - A great reference for getting TSC scaling multipliers on Linux and Windows
+
+## Post 4 (2026-05-31 00:46:04) — reply to Post 1
+
+@NOTimothyLottes If you do the multiply in uint128_t and then right-shift by 64 places, the compiler should do the right thing.
+
+## Post 5 (2026-05-31 01:37:00) — reply to Post 4
+
+@FUZxxl “Should” is exactly why I prefer the actual instruction instrinsics or just inline asm (which is what I use on C CPU land)
+
+## Post 6 (2026-05-31 08:23:19) — reply to Post 5
+
+@NOTimothyLottes Have fun with a solution that the compiler optimises worse and that is not portable.