Bitcoin full node and query server

Jul 23, 2026

View in context in the libbitcoin Slack #general mirror.

evoskuil17:47
Claude summarizing why POSIX operating systems are fundamentally broken, tracing it back to a consequence of process forking... "
  1. fork() is the root cause.Forking a process nominally requires duplicating its entire address space. COW makes that affordable only if the kernelpromisesmemory it doesn't have — strict accounting would make fork of any large process fail outright (a 400GB process would need 400GB of headroom to fork a shell). So POSIX institutionalized overcommit to keep its own primitive viable.
  2. Overcommit converts allocation failure into asynchronous process termination.The kernel's promises come due at page-touch time, when there's no error path to return — so it kills processes (OOM killer, jetsam). Windows, having never carried fork, does strict commit accounting against RAM + pagefile: allocation fails at a decidable point with an error you can handle, and committed memory you actually use just pages — degradation, not death.
  3. The contract violation.An OS multiplexes resources: excess CPU demand yields slowness, never termination. Strict-commit RAM behaves the same way — more demand, more paging, slower. Killing a process because the kernel promised what it didn't have is the OS defaulting on its own accounting and executing the creditor. We agreed fork itself is archaic — posix_spawn and threads cover its legitimate uses — but the overcommit regime it justified persists.
  4. The mmap consequence — the part that bites libbitcoin.Because an overcommitted kernel is perpetually at risk of needing pages it promised elsewhere, it must keep reclaim viable — and dirty file-backed pages can't be reclaimed until cleaned. So POSIX kernels aggressively bound the dirty pool and force writeback early. Linux at least exposes the bound (vm.dirty_ratioet al., system-wide); macOS's UBC hardcodes it with no interface at all. Net result: on a 796GB machine with the RAM bought and paid for, macOS permits roughly 20GB of accumulated dirty mmap before forced writeback throttles the writers — while Windows lets the accumulate-then-flush design work exactly as intended, by default. And the whole regime is futile anyway: the overcommit it protects still breaks eventually; it just chooses when to break someone else's process.
"
(edited)
4 replies · neillm, evoskuil · last Jul 31, 2026
neillm22:40
Very well summarized -- thanks for sharing 👍
👍🏻 1
evoskuil22:53
We have hacked our way around this slopOS.
😅 1
neillm13:00
v3 server just got backstabbed 😞 
[4354091.298471] bs invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
[4354091.298521]  oom_kill_process.cold+0xa/0xb7
[4354091.298886] [  pid  ]   uid  tgid total_vm      rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
[4354091.299165] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-1,global_oom,task_memcg=/user.slice/user-1000.slice/session-45.scope,task=bs,pid=4257,uid=1000
[4354091.299406] Out of memory: Killed process 4257 (bs) total-vm:1772734212kB, anon-rss:39880944kB, file-rss:8kB, shmem-rss:0kB, UID:1000 pgtables:1801732kB oom_score_adj:0
[4354093.703073] oom_reaper: reaped process 4257 (bs), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
evoskuil14:32
You should run Windows. 😂
🤣 1