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
(text/plain)