Comment by Someone
4 years ago
An ad hominem is not a strong argument to dismiss the claim.
Did reading the paper change your opinion?
It also isn’t “the Linux way”, it’s “the Unix way”. Linux has posix_spawn now, but, reading the paper, apparently lots of tools don’t use them ¿yet?.
> An ad hominem is not a strong argument to dismiss the claim.
I'm not dismissing the claim based on it. I'm just going in skeptical since the author has an incentive for people to believe this conclusion, even if it isn't true. If a paper claims that smoking is a net benefit to your health, wouldn't you want to know that it was funded by tobacco companies?
> Did reading the paper change your opinion?
No, it didn't. Here's a few counterarguments:
* "Fork is no longer simple" - there's a lot of things you might want to do between fork and exec, and it's really not simple to have a different way to do all of them: https://lwn.net/Articles/360556/
* "Fork encourages memory overcommit" - this makes the implicit assumption that overcommit is bad, but this isn't established to be the case.
* "fork restricts the definition of a process to a single address space" - but the only difference between processes and threads is whether or not they share an address space.
* "Fork infects an entire system" - like the GPL infects an entire codebase? If something is useful, it's not necessarily a bad thing that everything will support it.
* "However, the reasons that motivated multi-process servers are long gone" - The prefork MPM isn't deprecated and there's still reasons it needs to be used sometimes today.
> Linux has posix_spawn now
posix_spawn isn't a syscall; it's a userspace function implemented by using vfork and exec internally. But if all you had were posix_spawn, there'd be no reasonable way to implement fork in terms of it, despite the fact that there are some uses for it.