Quoting "David F. Skoll" <[EMAIL PROTECTED]>: > I partly agree with that, but I also think that ClamAV developers need > to make their software more admin-friendly.
I'm sure they will eventually. > 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? > 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. >> 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. The authors obviously don't agree, or they would have released it by now. I heard this same thing with dovecot. Same argument. Same outcome. Don't use non-production level software if you want production level support. Period. Either the creator doesn't feel it is ready for that, or they don't feel their support structure is ready for that, or they have no desire to provide that. In any case, you shouldn't use it, unless you are willing to accept the lack of such support. There are plenty of commercial AV products with proper support, if you require such. > Version > numbers are completely meaningless, especially in the open-source > world, unless they're specifically tagged "alpha" or "beta". Not true... I work on open source, and we take things like backwards compatibility very seriously. But only on the supported, stable releases. We break the development code all the time. We break pre-released software all the time. We even break Release Candidate compatibility from time to time. But we never* break BC in supported production releases (*okay, it has happened once or twice by accident, and in such cases we had to immediately release a new version to fix the BC break. Testing isn't perfect). > On my current Debian system, I count 369 packages versioned 0.xx and I > wouldn't call many of them "pre-release" or "beta". I would. That is the definition of a 0.x release. > A three-version "accept / deprecate / reject" policy would be far > friendlier, IMO. 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. >> Let's see. You want it to be mature, but it hasn't even had a 1.0 release? > > Red herring; see above. Blue herring, so what? > I want two things out of ClamAV: (1) Security and (2) Least Surprise. > So far, it's not doing spectacularly well on either. Yeah, and so far it is pre-release quality... So I wouldn't expect 2) to hold... As for security, well, that's a whole different issue... > 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. I have no problem with people asking for the software to be improved, and making suggestions on how that can be done. 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). And I have a problem when they are insulting to the authors. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
