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).
2026-08-01 15:49:22 -04:00
parent 8c93fba658
commit c3a9978d03
108 changed files with 4212 additions and 0 deletions
@@ -0,0 +1,63 @@
+---
+title: "https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related re"
+author: "NOTimothyLottes"
+handle: "@NOTimothyLottes"
+post_url: "https://x.com/NOTimothyLottes/status/2060191401883619479"
+post_id: "2060191401883619479"
+timestamp: "2026-05-29 02:48:01"
+post_count: 12
+reply_count: 1
+repost_count: 0
+like_count: 5
+view_count: 242
+---
+
+# @NOTimothyLottes — https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related re
+
+## Post 1 (2026-05-29 02:28:17)
+
+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.
+
+## Post 2 (2026-05-29 02:39:47) — reply to Post 1
+
+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).
+
+## Post 3 (2026-05-29 02:43:22) — reply to Post 2
+
+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?
+
+## Post 4 (2026-05-29 02:48:01) — reply to Post 3
+
+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
+
+## Post 5 (2026-05-29 02:52:57) — reply to Post 4
+
+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 ...
+
+## Post 6 (2026-05-29 02:55:54) — reply to Post 5
+
+... 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.
+
+## Post 7 (2026-05-29 03:02:52) — reply to Post 6
+
+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.
+
+## Post 8 (2026-05-29 03:05:57) — reply to Post 7
+
+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
+
+## Post 9 (2026-05-29 03:09:32) — reply to Post 8
+
+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.
+
+## Post 10 (2026-05-29 03:10:49) — reply to Post 9
+
+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.
+
+## Post 11 (2026-05-29 03:14:46) — reply to Post 10
+
+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
+
+## Post 12 (2026-05-29 03:19:53) — reply to Post 11
+
+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