Bitcoin full node and query server
Jul 30, 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...
"
- 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.
- 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.
- 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.
- 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)