fork has two uses. One is to run a bunch of child processes that the parent can control and hand work to. Think web workers in apache2 with the parent accepting

fork has two uses. One is to run a bunch of child processes that the parent can control and hand work to. Think web workers in apache2 with the parent accepting connections and the children processing the requests. The other is to start unrelated programs. Think bash which can start vim. I think for the first use case, it is stupid to have to reap the child process or else it gets inherited by init. Instead you should be able to mark that process as a worker from the get go. It doesn't make sense for apache2 workers to keep running if the parent process died. In the latter use case, I agree with the OP. I'd rather set up the structure of what I want to happen, then start that process as a completely independent thing. spawn seems like the way to go for this. The good news is that we can totally have all those options as long as we keep fork as is at least for the next 50 years :)