ed
c3a9978d03
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).
2.0 KiB
title, author, handle, post_url, post_id, timestamp, post_count, reply_count, repost_count, like_count, view_count
| title | author | handle | post_url | post_id | timestamp | post_count | reply_count | repost_count | like_count | view_count |
|---|---|---|---|---|---|---|---|---|---|---|
| Linux by default doesn't allow any increase in scheduling priority. Users need t | NOTimothyLottes | @NOTimothyLottes | https://x.com/NOTimothyLottes/status/2072135292115427728 | 2072135292115427728 | 2026-07-01 01:48:46 | 6 | 1 | 0 | 3 | 381 |
@NOTimothyLottes — Linux by default doesn't allow any increase in scheduling priority. Users need t
Post 1 (2026-07-01 01:45:40)
Working on the portable thread scheduling priority interface. Windows is a bit nicer by default, one can increase the scheduling priority without admin and there is a AvSetMmThreadCharacteristics() / AvSetMmThreadPriority() hack for "Pro Audio" scheduling needs.
Post 2 (2026-07-01 01:48:46) — reply to Post 1
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.
Post 3 (2026-07-01 01:51:56) — reply to Post 2
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.
Post 4 (2026-07-01 02:36:48) — reply to Post 3
Linux priority workarounds (a.) Use getrlimit() to get {soft,hard} limits (b.) Use setrlimit() to set 'soft=hard' limit (c.) Then set priority or nice based on new soft limit
Post 5 (2026-07-01 02:38:20) — reply to Post 4
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.
Post 6 (2026-07-01 02:46:03) — reply to Post 5
Also while on setrlimit, I also bump up the RLIMIT_MEMLOCK to it's maximum just in case before the mlockall().
