It mostly falls out of Linus&#x27;s position that security bugs are just normal bugs, and the implications about the investment put into fixing them in a timely manner, or preventing them from happening in the first place. A little more concretely, off the top of my head:<p>* There is not much interest in proactive security-hardening of the like taken by grsec, PaX, etc. This is not to say that they should just pull grsec or PaX upstream wholesale, but that there&#x27;s not much interest in solving the problems that lead to those things existing out-of-tree in the first place.<p>* There is no process for security review of new features. While things are casually reviewed, it&#x27;s assumed that it&#x27;s okay to go ahead and ship some new code, and new security holes can be fixed in the future just like functionality bugs can be fixed in the future.<p>* Stable point releases include everything from security fixes to added support for new hardware, and there is intentionally no distinction made between them. In many cases, there&#x27;s an active attempt to obfuscate what fixes are security-related, on the grounds that they&#x27;re all &quot;normal&quot; stable patches the way that security bugs are &quot;normal bugs&quot;. This means that users (both people who use the stable kernels directly, and people who make distribution kernels) need to either diverge from the upstream stable point releases, or test thoroughly before shipping&#x2F;deploying, which increases update latency significantly. Point releases cannot be used directly as urgent security updates.<p>* Not all security fixes are backported to stable point releases in the first place, because the development culture encourages thinking of them as &quot;normal bugs&quot;, and not all normal bugs are obviously worth backporting fixes for (otherwise why have a separate branch). It&#x27;s entirely possible to send a security patch to the kernel, not say it&#x27;s security-related (because you&#x27;re asked not to), and have it fail to go to stable. It&#x27;s entirely possible for a patch to be quietly dropped because it&#x27;s too much effort to backport -- again, the lack of difference from &quot;normal bugs&quot; means that there&#x27;s no guarantee that  security bug fixes will get backported.<p>* Aggressive commitment to an unstable kernel API, let alone ABI, means that stable point releases require rebuilding third-party modules, and may break them, and that there&#x27;s absolutely no way for a good portion of users to even be on the latest stable point release. RHEL has its massive awful backport series, where the kernel in current, supported RHEL releases does not resemble either the original branch point or the current upstream very well, because their customers are paying them to for <i>reliably</i> being able to upgrade to RHEL-released kernels.<p>* As a result of the last two bullet points, there&#x27;s a lot of divergence between the upstream kernel and what people actually run, which is what Linus is getting at in these posts, when he says, correctly, that <i>him</i> identifying security bugs would be more helpful to attackers than legitimate users. But there&#x27;s no interest in making that not be the case in the first place.<p>I have a bunch of more minor complaints (the number of security <i>misfeatures</i> in the kernel like &#x2F;dev&#x2F;random and Linux &quot;capabilities&quot;, which indicate the lack of a healthy security development culture, and the aggressive &#x2F; personality-based management style, which may be conducive to certain development goals but cannot be conducive to security).<p>To be fair, this is a completely valid philosophy for a project to have. There are good reasons to decide that security is just not that important, compared to other things they could be doing. Most of this is being very <i>intentional</i> about letting security be a low priority. For instance, the kernel folks have very good reasons for not having a stable kernel API or ABI, because they don&#x27;t want people using out-of-tree code, in pursuit of certain engineering goals. They understand there&#x27;s a tradeoff between that and other engineering goals, like getting more users to run a current release, and they&#x27;re fine with that.<p>(Whether it&#x27;s a valid philosophy to choose to <i>use</i> such a project for secure systems is a different question, but this is just about their internal development philosophy.)<p>Firefox, on the other hand, is a project that very much wants people to be on the latest release all the time, and favoring security is one of the inputs to them in making that tradeoff. Firefox is a project where they <i>can</i> go from announcing that they&#x27;ve found a security bug to the patch being deployed on most users&#x27; machines within hours, and they&#x27;ve optimized for making that be the case. At that point they <i>can</i> handle security bugs differently from normal bugs, and expect that to be a net positive for users. They do have problems about stability of internal APIs (used by add-ons), but they&#x27;re much more cautious about it, and there&#x27;s no viable business in &quot;You&#x27;ll probably get security fixes in a timely fashion, but your add-ons will definitely still work&quot;. Firefox cares about architecting things to be secure by design, and they run their own enterprise release channel with the intention that even conservative deployments will use the binaries from that channel directly.