If no one can use your code, it doesn't matter how beautiful, well-thought-out, or well-written it is. Software exists for the purpose of being executed. If your project cannot be deployed with a reasonable amount of effort, it's worse than bad software, it's a waste of time.
What about easy-to-install software that makes it easy for Bad People to ruin the Internet and to compromise your server (and potentially your entire organization)?
That is bad too. If I had to pick between "secure + customizable but hard to setup" and "easy to set up, but is a one giant gaping security problem", I think I would rather have the first.
Software is about collaboration, like a relationship; one person shares their ideas (qmail), another shares his (your site's configuration), and both parties do better than the sum of their parts. Easy-to-install software that doesn't require thought or communication is a one-way conversation; nice in the short term, but not something you want to be with for the rest of your life.
I hate this attitude. If your code targets my system, I should be able to install it without editing it.
You certainly should, but it isn't the coder's responsibility to make this possible. It's the language/system designer's.
Just because C doesn't let you deploy nicely has nothing to do with djb's ability to create beautifully architected code, which is what Aaron is praising. I'm sure djb could have written equally beautiful code in Squeak Smalltalk, and it would have been a breeze to deploy, but had no impact on how elegant the code itself was.
C does let you deploy nicely. A makefile and some discipline are almost all you need. Granted it's not always easy to write a sane makefile, but that is the coder's and not the installer's responsibility.
I don't think it's every C coder's responsibility to know how to make and ship good makefiles. It's certainly is helpful if she does, but it seems silly to say that's a responsibility, just as it isn't the responsibility of an artist to know the laws governing international sales of her artwork.
Sure, but it all depends on the coder's goals. If there's a competing option that's easier to install, prospective users may go with something else. If the coder doesn't care and isn't looking for users, then that's fine.
QMail doesn't target Linux? Oh, wait, you mean it doesn't target me and others who doen't want to invest the effort in installing it. That's fine, I use Postfix and it works well enough for my needs.
So what? Comparative programs have the same issue therefore it is not an issue? I'm not disputing that QMail is an improvement over Sendmail; in fact, I'm not disputing QMail at all. I've never deployed it, nor do I plan to do so.
I'm merely expressing my belief that in code that is meant to be used in production, facilitation of deployment is part of the problem scope. This is especially so when proper deployment is critical (as is the case with a mail server for example.) If QMail make deployment more difficult than it could be, then that is a problem with QMail. It might be the result of a worthwhile trade off. It might be better than it's competitors. But it's still a problem.
