>> Members of our admin staff have left notes in the /etc/motd "Contact >> ed@ for more information on restarting". > > This is psychology, not technology. > Yes, but the fact is your have to train people and document things like a startup procedure, which are usually simple. That is not philosophy it is lost time. I think the low adoption of run scripts speaks to its utility. That is my argument for the the replaced.
>>You could have been the one writing the book. Maybe I will have to. > So how would you deal with a crashing Apache, if you don't have daemon My point, apache does not crash often for me neither does qmail. Thus the auto-restart feature is not that useful. Couple that with my point about training people. It is hard to get a package "blessed" by any distro with svc if it does non standard things. That is going to hurt the adoption of qmail thus hurting its future. > Hmmm, rpm on FreeBSD? I hope not! Obviously I do not do RPM on FreeBSD. My point was that thanks to the "patchness" factor, I really can not use any package system. > Then you should purchase a product or hire someone to implement > something for you. Regardless of me doing it myself or hiring someone, time/money/resources is spent. In my opinion the "overhead" to run this MTA is very high. I used the word ludicrous. I will stand by it. Take for example SMTP TLS. Ideally during compile/make the mail server should detect TLS and activate it. Would you agree that most MTA's would do that? I should not have to pay money or spend more time configuring a no-brainer feature. > You're especially comparing qmail-ldap, which is mostly a pure mail > transport agent, to a groupware package that includes a mail transport > agent. Your arguments against qmail-ldap, from this perspective, apply > the same way across all other classic unix mail transport agent > packages, like Postfix, Sendmail and Exim, to name the biggest ones. Agreed, that is unfair. > You're only saying that nobody in your company deigned to learn > qmail+ldap. True, but many of the things I mentioned serve as a higher barrier to entry. Normaly ./configure && make && install && review mod the configuration && init script. qmail and qmail-ldap hardly work that way. The main issue as I mentioned is hunting down patches and through bad documentation. I can give you a simple example, one searches "daemontools" Already I am confronted with: http://thedjbway.b0llix.net/daemontools/installation.html http://cr.yp.to/daemontools/install.html What is this step? ln -s /usr/local/package /package Both people are setting up a different way. This is mostly what i was getting at in terms of time and expense. This is an issue for all open source projects but I find it particularly bad for qmail, qmail-ldap has less specific documentation then qmail. Comparing qmail as an mta to a groupware app is probably unfair, as you say. By hooking into ldap qmail-ldap presents itself as an enterprise solution. After all, who needs LDAP integration except large enterprises? The small documentation and the decentralized path management is a detraction in that area IMHO.
