Yes. It currently runs over 70% of global internet and considering all kinds of error conditions that show up on the global internet the code is extremely stable.
Sendmail used to run on something like 90% of the global Internet. And mail in the 1990s pretty much did work, pretty reliably. Would you have banked your site's security on the quality of Sendmail 8.6.12's code?
Slam dunk on that comment! Such systems, due to lots of debugging, can work reliably in a narrow set of use cases where specific features have massive use. Then there's the uncommon, usage scenarios and features that get much less debugging. Then there's all the patches they keep distributing to fix... "things."
And then the fact that safe, reliable code is only first step toward secure code where an intelligence, malicious person is targeting it. Totally different ballpark that neither Sendmail nor Cisco handled so well. Small shops like Sentinel and Secure64 did way better with a tiny fraction of the money. So, it has to be intentional for the extra profit at customers' expense.
Extremely stable, but not extremely secure. This could be said for many companies, and Cisco shouldn't really be singled out here, but I think this is part of tptacek's overall point. The world should move away from huge C code-bases for critical infrastructure and adopt "safer" languages (Personally I love Go, but Rust may be a better option for high-speed packet routing).
I've never used them for large volume actually. Are you using them via SMTP or API? I'm asking because I've never seen a single API call fail with them, but maybe it's about the volume like you said.
For large volume sending, I'd probably use AWS SES. In the past, I've used it for sending 150-200K/transactional emails per day and the service was very robust.
On the other hand, I've seen Mandrill increase the number of failed API calls with a lower sending volume.
> Then the technical interview came, and one of the interviewers was instantly hostile as soon as he saw me. It was weird. Weird to the point where the other tech interviewer started playing good cop, saying things like "he just covered that" and "no, that's true". Whiteboard coding is strange enough, but doing it with zero feedback and a hostile interviewer who keeps trying to push you in bad directions (inheritance over composition, singletons, etc.) is, well, interesting. The application came back with the inevitable "good skills but bad culture fit" euphemism.
Wait, you think the companies that have to move fast have the coddling environment?
> magine that each Python module runs as a microservice. For many modules this would lead to huge performance degradation, for example a regexp module can be called thousands times per second, the running time of a call is usually short and replacing an in-process call with a network call will give 100-1000x slowdown.
This is absolutely irrelevant. If your call budget is 400ms then extra 4ms that it takes fetching a data from a micro service is negligible. Make 400ms 4ms and you are done.
That's because you are looking at the wrong problem.
The biggest problem with common core is that it codifies social promotion under the guise of "schools know better" while linking promotion to money received by the schools.
