A fork() in the road
microsoft.com/en-us/research/publication/a-fo...
microsoft.comPosted Apr 10, 2019, 8:38 PM UTC
2113
microsoft.comNice to see Microsoft Research using its resources to publish wild-eyed screeds, flaming another research department whose APIs still continue command far more influence than their own, despite having been disbanded decades ago. I.e. Bell Laboratories. No one cared when MS "deprecated" getenv() in their ridiculous C library that's been known to wrap main() with spyware, so no one's certainly going to care now. The whole crux of their argument is basically that fork() makes it hard for them to invent new forms of DRM and tool around with microcontrollers. Very sad.
3
But where's the proof of such spyware?
1
1
I see you're a man of culture ;) But the funny thing is how they explicitely name the functions. Fortunatelly i fell in love with gcc/clang and linux.
1
Slashdot is considered cultured these days? You're too kind. Linux/Clang/GCC are very good and worth loving. They've also had their share of... best intentions accidents. Like the time the Debian secretary commented out OpenSSL's RNG to fix a Valgrind warning. Intel actually released a new x86 hardware feature to prevent that specific incident from happening again. Then GCC wrote an intrinsic wrapper for it, that had another well-intentioned accident lool.
1
Cross-posting this in case some of you don't read r/programming - this coincidentally showed up there right as I've been considering moving my OS to use semantics closer to
vfork()for its fork implementation.I like fork. Haven't read this and I really don't care enough to do so, so I don't know if they're making any good points or not, but I'll just disagree on the face of it. Fork is just a brilliantly elegant design.
Basically says fork/execve are old and that posix_spawn/clone should be used instead.
Problem is posix_spawn directly calls fork/exec and fork is a special case of clone. So in that regard there's not really a solution.
The argument is a little higher-level than those implementation details, though. The call to action is "move software in general away from fork, towards spawn", but that's in order to enable OS developers to implement spawn in other ways than just as a fork/clone wrapper.
I'm not completely sold, tbh - I like fork/exec conceptually. But I think they raise a lot of good points worth considering.
I get their argument. Problem is they don't provide a tangible solution, if there was one is use it.