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).
This commit is contained in:
ed
2026-08-01 15:49:22 -04:00
parent 8c93fba658
commit c3a9978d03
108 changed files with 4212 additions and 0 deletions
Binary file not shown.

After

Width:  |  Height:  |  Size: 6.0 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 925 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 KiB

@@ -0,0 +1,49 @@
---
title: "Linux by default doesn't allow any increase in scheduling priority. Users need t"
author: "NOTimothyLottes"
handle: "@NOTimothyLottes"
post_url: "https://x.com/NOTimothyLottes/status/2072135292115427728"
post_id: "2072135292115427728"
timestamp: "2026-07-01 01:48:46"
post_count: 6
reply_count: 1
repost_count: 0
like_count: 3
view_count: 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.
![Media 1](./media/2072135292115427728_1.png)
## 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
![Media 1](./media/2072147378480566273_1.png)
![Media 2](./media/2072147378480566273_2.png)
## 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().
![Media 1](./media/2072149707107787035_1.png)
@@ -0,0 +1,109 @@
{
"root_post_id": "2072135292115427728",
"posts": [
{
"post_id": "2072134509089144888",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "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.",
"timestamp": "2026-07-01 01:45:40",
"media_urls": [],
"reply_to_id": null,
"quote_of_id": null,
"metrics": {
"reply_count": 2,
"repost_count": 1,
"like_count": 9,
"view_count": 1131
}
},
{
"post_id": "2072135292115427728",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "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.",
"timestamp": "2026-07-01 01:48:46",
"media_urls": [
"https://pbs.twimg.com/media/HMGz-64W4AABeaH?format=png&name=orig"
],
"reply_to_id": "2072134509089144888",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 3,
"view_count": 381
}
},
{
"post_id": "2072136089070961073",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "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.",
"timestamp": "2026-07-01 01:51:56",
"media_urls": [],
"reply_to_id": "2072135292115427728",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 3,
"view_count": 298
}
},
{
"post_id": "2072147378480566273",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "Linux priority workarounds\n(a.) Use getrlimit() to get {soft,hard} limits\n(b.) Use setrlimit() to set 'soft=hard' limit\n(c.) Then set priority or nice based on new soft limit",
"timestamp": "2026-07-01 02:36:48",
"media_urls": [
"https://pbs.twimg.com/media/HMG-UCRXIAEKbdj?format=png&name=orig",
"https://pbs.twimg.com/media/HMG-zRxWwAAWtI4?format=png&name=orig"
],
"reply_to_id": "2072136089070961073",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 3,
"view_count": 78
}
},
{
"post_id": "2072147765157638479",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "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.",
"timestamp": "2026-07-01 02:38:20",
"media_urls": [],
"reply_to_id": "2072147378480566273",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 2,
"view_count": 318
}
},
{
"post_id": "2072149707107787035",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "Also while on setrlimit, I also bump up the RLIMIT_MEMLOCK to it's maximum just in case before the mlockall().",
"timestamp": "2026-07-01 02:46:03",
"media_urls": [
"https://pbs.twimg.com/media/HMHBGTPXwAA_axg?format=png&name=orig"
],
"reply_to_id": "2072147765157638479",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 307
}
}
],
"source_url": "https://x.com/NOTimothyLottes/status/2072135292115427728"
}