Dan Bernstein didn't "regard immediate profit as more important than long-term quality". Neither did Wietse Venema. Both were at extreme pains to make sure their <i>free</i> software was free of security problems. Unlike <i>any</i> commercial software, security software included, software security was the #1 priority for both these projects.<p>Both failed to ship code free of game-over security flaws.<p>I find your point about "tolerating" failure to be irrelevant to the real world at best. At worst, it's just fatuous.<p>I've shipped hundreds of thousands of lines of code, and I've led projects to review millions of lines more: chipset to JVM, embedded to desktop, open source and proprietary. It is a point of pride with us: <i>we always find things</i>.<p>You think you're being respectful of users when you chant "don't tolerate failure". What you're really doing is being disrespectful of computer science. All evidence available to us suggests that it is practically impossible to ship code --- or at least, real-world code --- without security flaws.<p>Is secure software an impossible goal? Not for computer scientists. For instance, a Stanford team build a system for evaluating code for flaws based on abstract analysis. That project became Coverity, a commercial product for scanning source code for flaws. They compete with a larger company called Fortify, in a hundred million dollar market for static code analysis.<p>Projects like Stanford Checker, or the OS and runtime hardening work being done in countless labs, have a chance of advancing the state of the art to where you think it really is now. A line developer on a browser project has no such chance.