While the whole chain has been somewhat interesting, I still believe that
for a production environment, this is SUICIDE.
(1) For the situation where large processes fork and immediately exec,
many other *IX system have a "vfork" system call to handle the situation.
Incorrect; pretty much all modern Unix systems which implement
copy-on-write VM semantics alias vfork to fork. The original API
specification for vfork() specifically explained that it was a
performance kludge that was likely to go away once C-O-W was
implemented, and that programs shouldn't depend on vfork()'s unique
semantics.
(3) This is sure a time waster for porting and developing programs to run
on Linux. "Hey, you know that program that worked fine on System A could
blow up on Linux." This is espcially true for those people who want
to move binaries from some other vendor's OS.
Shrug. Many other commercial Unix systems follow the same strategy as
Linux; why aren't you ranting and railing at Irix, OSF/1, AIX, etc.?
Pretty much any system which uses copy-on-write VM for performance
(which means pretty much all modern Unix systems) are going to have this
characteristic of not accounting for all possible writeable data pages
for their processes.
If you want to sabotage Linux you can continue claiming that Linux is
unique in this fashion. But it isn't, and it's not a problem.
- Ted