> You're missing the point. I don't think I am. You're focusing on one particular thing and invoking platitudes that are completely irrelevant. You're actively

> You're missing the point. I don't think I am. You're focusing on one particular thing and invoking platitudes that are completely irrelevant. You're actively attempting to change the conversation topic to fit your viewpoint. That's not okay. No one is talking about the philosophy of feature development and adoption. I gave another example of where we preemptively mitigate issues that has nothing to do with philosophical waxing on "did we really need to do this" or "nobody really wanted that feature": Specter/Meltdown. So two things, to get this conversation back on track: 1) The idea that DNNSEC is worthless/useless/bad is not "famous" by any reasonable use of that term. I explicitly stated it was only something you see in particular circles. The fact that the actual most popular piece of software used to manage DNS enables DNNSEC by default, and one of the biggest 3rd party public providers for DNS has it opt-out only is a testament to this fact. It's myopic to think that other people are aware of these things when the entire ecosystem is signaling quite the opposite. 2) DNSSEC might be useless, but in abstract terms arguing against systems designed to mitigate attacks simply because those attacks haven't been seen in the wild is a bankrupt idea in the world of security. So if you want to say DNSSEC is a bad idea then stick with that, but don't say it's a bad idea because we haven't seen an actual attack with what DNSSEC is trying to prevent. The claim again, is bankrupt when you're talking about securing systems. >but the social process that caused a coding 101 bug to potentially compromise the vast majority of server installations is why Heartbleed is important. I actually want to speak to this, because it's kind of a popular thing to say in the world of software development, but it fundamentally misunderstands what's actually happening. You're right that a social process allowed the coding 101 bug to happen and exist for so long, but you're wrong about which social process. People's motivations for a feature have no bearing on how exploitable code gets written. Because features that people do want are victim to the same kind of errors in code. If you immediately falsify your perspective about which social process is in play you see it becomes irrelevant. You can completely take people's motivations out of the equation and the same process and class of error exists that allows the exploits and bugs to happen. I am not saying that increases in LOC does not correlate with an increase in bugs. That's a fairly standard fact. I am saying that people's motivations for features have no bearing on how open source projects fall victim to shoddy code. The social process that IS to blame is the fact that people don't invest in open source software, yet depend on it for their entire ecosystem. A student wrote some code, submitted it, and it was reviewed by one person. That code was never really looked at again, not really tested, but allowed to exist in the software for years. If the social ecosystem around open source software was one where more eyes had been laid on the code created it might not have happened all together, and relying on a student to write the code is a travesty in its own right all together. But people's motivations for writing code? Not really relevant in terms of LOC, exploits, and code quality.