One thing to learn from djb is how to write virtually bug-free code.
Much more people would be able to do that if they:
a. Stopped using buggy dependencies b. Focused on the task being solved instead of on the technology
Much more people would be able to do that if they:
a. Stopped using buggy dependencies b. Focused on the task being solved instead of on the technology
djb lives in a quaint fantasy toy land where he gets to write whatever he wants and doesn't have to interface with real world systems at scale. That's great when you're the author. Your software can be clean if you only write for yourself and not for 50 million other programmers trying to build software on top of your tools as well. But, it's painful when you're a user and real world problems get ignored because the author just never experiences your same problems (so they never care to fix them).
Much like how a startup isn't 90% code and 10% "company," public software in 2015 shouldn't be 100% writing code all day then dropping .tar.gz files on a server once every two years while ignoring wider principles of project governance, collaboration, and feedback/growth processes.
Rather than learning how upstart or systemd unit files work and learning their configuration languages, you only need to know how to start a process that runs in the foreground and logs to stdout.
[Service]
ExecStart=*path to process*
Publicfile and ucspi-tcp might not work "at scale", but qmail, ezmlm, djbdns and daemon-tools certainly work even for very large deployments. I would agree that qmail and ezmlm benefits from the patch-set floating around.