Anyone is free to do what they want, of course. I just don't recommend the use of such kernels, as over the years I've noticed several things:
1) Our development is very active, yet any 3rd-party packaging has always lagged (often quite badly). In fact just yesterday I had someone on the forums waste my time trying to get help compiling his "grsecurity" kernel that turned out to be a 2 year old Debian source of it.
2) Security isn't obtained by lifting individual features, and you can't just toss some code into a codebase and claim it works as intended just because it applies cleanly. I'll be giving a talk in October at H2HC where in part I'll talk about some security features that were ripped from grsecurity and submitted upstream, then neglected to the point where they no longer do what they claim.
3) When it comes to security features, I argue the same as in Plato's "Ion", that a security researcher with kernel development experience would know best how it should be merged to preserve its integrity. Not a kernel developer lacking security knowledge, and definitely not someone just testing to see if two codebases compile when merged.
I don't think any of the above is unreasonable. BTW, instead of making snide remarks, might your time be better served backporting some more missing security fixes to 3.2? ;)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds