- nested xmallocs (typical in complex code) is a problem for NOFORK
-rare: not used often enough to bother optimizing (example: poweroff)
-longterm: often runs for a long time (many seconds), execing would make
- memory footprint smaller
-daemon: runs indefinitely
+ detailed audit often turns out that it's a leaker
+hardware: performs unusual hardware ops which may take long,
+ or even hang due to hardware or firmware bugs
+
+Interesting example of "interactive" applet which is nevertheless can be
+(and is) NOEXEC is "rm". Yes, "rm -i" is interactive - but it's not that typical
+for users to keep it waiting for many minutes, whereas running "rm" in shell
+is very typical, and speeding up this common use via NOEXEC is useful.
+IOW: rm is "interactive", but not "longterm".
+
+Interesting example of an applet which can be NOFORK but if not,
+then should not be NOEXEC, is "usleep". As NOFORK, it amount to simply
+nanosleep()ing in the calling program (usually shell). No memory wasted.
+But if ran as NOEXEC, it would create a potentially long-term process,
+which would be taking more memory because it did not exec
+and did not free much of the copied memory of the parent
+(COW helps with this only as long as parent doesn't modify its memory).
+