> if the other processes would themselves kill those which have been
> stopped, it might make a more robust fork bomb, by slowing down the
> progress in stopping them.. but ultimately, it takes less time to
> send a stop than it does to figure out that another one has been
> stopped,

Who said anything about figuring out that they're stopped?  Just kill
one for every two you fork.  Who cares whether it's stopped or not?

I think it would be possible to make a wabbit that would be
approximately impossible to kill with any tool that depends on human
interaction (like top), though probably it could be dealt with by a
tool that renices itself to -20 and then never does anything that might
block while fetching the process list and sending out signals.
Provided it busy-waits for user input it might even be possible to give
it a user interface (though if you're using something like X, you'd
have to renice your X server and maybe other processes like xterm too).

I'm not sure abusing ptrace wouldn't permit surviving even that,
though; I'd have to think about it and check into details (like what
happens when a ptraced child has its tracer killed).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B