why I run no-exec-stack patch

I've run at least one production server for more than a year with a couple of
different versions of solar designer's no-exec-stack patch. Judging by the
flurry of emails from people speculating how badly it must break trampolines,
I imagine that running it for a few days would have been enough to exceed all
the detractors combined. I've seen no ill effects. Not on libc, and especially
not on glibc. So I urge everyone who can't stand the idea of this option being
in the kernel to at least run it for a week.

So what if it's not a perfect solution. It will at least give us some more
creative exploits in the future. But it's certainly an improvement, and it
certainly raises the bar. So when my syslog says:

kernel: Possible buffer overflow exploit attempt:
kernel: Process crond (pid 612, uid 0, euid 0).

I can have a good laugh that even though a user beat me to the punch on an
exploit, I don't have to wonder if I've been rooted and don't know it.

I'm not close to talking about letting a box sit around unpatched for months
like too many do. I'm talking about why not put a barracade, even if ever so
small, into the ever tightening exploit-and-patch cycle. Anyone who doesn't
think this will help security is welcome to give me a shell account on their
box, so they can worry about skilled hostile users just like I do. And no fair
switching to OpenBSD first.

I mean really. Make it a kernel option that you have to check the
"experimental" box first in order to see, if it's really that important to
not have it be readily available. Otherwise, I'm really wondering where all
those people who thought it was a good idea to have a stinking web server
in kernel space have gone to.