As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, e

As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, especially after Spectre--Linus and a large part of the community were resistant to mitigations and code refactors that didn't actually add functional behavior, and especially if they were visible to userspace, harming backward compatibility. But those types of patches were precisely what grsecurity was pushing. So you basically had a fundamental clash of philosophies (independent of the clash of personalities) about whether the work grsecurity was doing was even valid from a software engineering standpoint. Arguably because of the relentless onslaught of exploits and growing enterprise influence, the Linux community slowly relented, but never with a mea culpa, AFAIK. A similar dynamic played out with /dev/urandom, where the Linux community and subsystem maintainers were adamant that the existing blocking and entropy accounting behaviors were crucial to security and non-negotiable. But now look where things stand--both are gone after 10-15+ years of debate. Again, without any mea culpas. Ditto for sandbox-friendly interfaces. Once upon a time any grievance that an interface which relied on /proc, /dev, or similar was suboptimal from a sandboxing standpoint (kernel surface area, headaches with chroots, etc) was met with derision. Eventually we got getrandom(2), and other recent application interfaces, like process descriptors, were revised so they were usable without /proc or similar. You could see alot of this play out on Slashdot, HN, etc as commenters frequently parroted Linux developers' talking points and assertions. There's plenty of blame to go around.