Eric Rostetter wrote:

> Well, maybe your "automatically upgrading" software needs improvment,
> or just maybe you should follow standard best practices and not do
> automatic upgrades on a critical/important production system?

I partly agree with that, but I also think that ClamAV developers need
to make their software more admin-friendly.  The canonical situation
is one in which a small (but technically adept) company is responsible
for hundreds of Clam installations for technically naive customers.
In this situation, the ClamAV policy really hurts.

> You are using a pre-release fast changing piece of software.  Yes, it
> will change.  If you don't like that, wait for version 1.0 before you
> use it.

Oh, come on.  ClamAV might be numbered 0.xx, but for all practical
purposes, it is widely-used production-ready software.  Version
numbers are completely meaningless, especially in the open-source
world, unless they're specifically tagged "alpha" or "beta".

On my current Debian system, I count 369 packages versioned 0.xx and I
wouldn't call many of them "pre-release" or "beta".

> Yes, the parser could skip bad entries, but that would probably leave
> users thinking that it was doing something that it wasn't, which would
> be bad (and would generate much list traffic).

A three-version "accept / deprecate / reject" policy would be far
friendlier, IMO.

> Let's see.  You want it to be mature, but it hasn't even had a 1.0 release?

Red herring; see above.

I want two things out of ClamAV: (1) Security and (2) Least Surprise.
So far, it's not doing spectacularly well on either.

Regards,

David.

PS: Please don't take this too badly.  I'm very grateful to the ClamAV
team for their software and all their hard work.  My comments are intended
merely to help improve the software, not as gratuitous complaints.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

Reply via email to