Fork/exec limitations are back on the table
A post on moving beyond fork() and exec() generated a substantive thread about the fundamental limitations of Unix process creation. The discussion covers why fork() is hard to replace despite its well-known problems, with commenters touching on memory layout, environment inheritance, and the shell ecosystem's deep dependence on the model. A rejected kernel patch from Chen was discussed as a case study in how niche the use cases need to be before the Linux kernel maintainers will consider changes.
This connects to a broader theme in the technical threads today: people are revisiting foundational computing assumptions. The Win16 memory management post is another example, as is the speculative KV coding paper on compressing attention caches. There is an appetite for going back to first principles.
The practical implication for builders is modest in the short term. Fork/exec is not going away. But the discussion surfaces real costs, particularly the memory overhead of loading the same shared libraries into every process, that matter more as workloads shift toward running many small AI inference processes in parallel.
So what?
If your product runs many short-lived processes, especially AI inference workers or sandboxed execution environments, the fork/exec overhead is a real cost you should be measuring. The WASM and eBPF trends are partly a response to this: both offer ways to run isolated code without the full weight of process creation.