Eric Rostetter wrote: >> The canonical situation >> is one in which a small (but technically adept) company is responsible >> for hundreds of Clam installations for technically naive customers.
> Maybe you should manage their installations for them? We do! That's the point. WHEN (not IF) we have to upgrade Clam in a hurry because of a security issue, we have to go and fix the config files. If Clam did the accept/deprecate/reject cycle, we could do security upgrades in a big hurry, and then go fix the config files in a more leisurely and thoughtful way. >> In this situation, the ClamAV policy really hurts. > It can, yes, but it doesn't have too. And you could instead use > a production level AV product instead, if you wanted. I consider Clam production-level. >> Oh, come on. ClamAV might be numbered 0.xx, but for all practical >> purposes, it is widely-used production-ready software. > The authors obviously don't agree, or they would have released it by > now. Let's ask them: ClamAV developers: Do you consider ClamAV to be production-ready for real systems? > Don't use non-production level software if you want production level > support. I don't *want* support. I'm just trying to improve ClamAV. > Yes, and it is okay to ask the authors to consider this for future > inclusion, but it is not okay to insult them for not yet providing > it or to demand that they now provide it, when you are using > pre-released software. Where did I insult? (The OP was not me.) > I have a problem with people _demanding_ it be improved right now, for > free, when the software is still in development stage, and they are not > offering to help with any changes in any way (financially, code patches, > etc). I've contributed both money and patches to Clam in the past. Regards, David. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
