I've been follow grsec for a while now, and I really like the honesty around it. They admit what they are and aren't good at, and as for the product itself (grsec), it has become my go to hardening system for the kernel over SELinux (I know you can combine the two, I don't though). Combined with other measures I think I am doing a pretty good job in balancing out the usability security scale.<p>If you haven't taken the time to learn grsec, you will thank yourself later if you do. Keep in mind though there was some recent drama with some people/companies not properly attributing grsec, so you want to use current instead of stable imho. Alpine linux has grsec build in, gentoo has some good guides, and so does arch, but I tend to add it to debian.<p>As far as the state of linux/kernel security, I blame one thing in particular, and that is complexity and amount of code. The many eyes theory has a fault, in that it assumes a lot of people will look at the code and with enough people the bugs (security bugs) will be found. Well the problem is that the linux kernel is now at 10 million+ loc. So even with a shitton of people digging through the code, lots of stuff is going to get missed, and the real problem is that there are a lot less people looking at the code than we all want to think.<p>I think the primary way we will be able to move to <i>security</i> in the future is in efforts to refactor and reduce complexity of code in general, along with working on making it easier to read (or better commented).<p>This is one reason why I find minix 3 to be a very interesting project, at <10k loc.