staticassertion

This notion was termed "security through obscurity" ie: "you use the less popular option, therefor that option is safer". It has nothing to do with "obscuring" in the sense of "hiding", that's a linguistic quirk of a colloquial term. If you were actually taking action to reduce the ability to understand a system in a way that you could meaningfully defend, it would no longer be "security through obscurity".

The argument has persisted because there are two different questions that sound the same (X is less typical than Y):

1. Is "X" safer than "Y"?

2. Is a user of "X" safer than a user of "Y"?

When looking at (1) in isolation, you can say things like "X lacks security features, therefor Y is safer" and "X is less often used, therefor X is safer", etc. This is a question about the posture of the project itself, in isolation.

(2) is about the context for users. The reality is that X, which perhaps is fundamentally less well built software, may actually have users who are attacked far less frequently.

Both are likely to favor "rarity is a poor indicator of safety" as we generally reject mitigation approaches that rely on attackers to behave specific ways, but what's important is that these are completely different questions and neither has to do with being obscured but rather rare.

None of this is about what is "obscured" or not. If something is obscured or obfuscated, that is a technique that can be evaluated separately by its own merits (ie: how hard is deobfuscation, how easy is it to adapt to deobfuscation, etc). All of this is about whether you're evaluating (1) or (2) - and in the case of (1), which is what the criticism always has focused on, the answer is that "rarity" is not a mitigation.

Editions exist to avoid breaking code over time.

Security through obscurity merely means that your system is atypical. It's not hidden, it's not secret, it's not hard to find, it's not hard to examine, it's not less visible, etc - there is nothing inherently different about the systems at all other than that one is more common than the other. It's just less typical.

That statement deserves support.

As for the latest patch, Greg is currently being forced to clean up a big fucking mess by external parties. And he's miserable about it.

I'd start with Greg's own words. You can probably find more on it from Spender/grsecurity's blog.

Literally never. Why would he? He's surrounded by sycophants. And we have Greg for whenever Linus isn't involved anymore, and Greg is just as boneheaded.

The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.

It's fundamentally their position to not work the way that you describe.

LPEs on Linux are obscenely commonplace.

They openly refuse to do this and have been given authority by MITRE to work against any such process.

I obviously do not expect someone who has merely heard of various CVEs before to know anything about the contents of those CVEs. The other poster said they had "read many CVEs", which I took to mean they have read many CVE disclosures, where the term is extremely common. Perhaps they meant that they've read about CVEs, in which case I can see why the term would not be on their radar.

The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvisor users are not impacted by this CVE. Seccomp also kills this CVE.