David F. Skoll wrote: > Dennis Peterson wrote: > >> So does Oracle, Apache, Python, Perl, MySQL, and a zillion other >> products. Dead processes are widely accepted to not be chatty. Pardon my >> Dennis Miller moment here, but I'm going to go ahead and blame the admin >> if a critical process dies and they don't know about it. > > You are (as usual) utterly missing the point. > > The ClamAV developers have asked to make a policy change that makes > upgrading easier.
And you've missed the point that some people here have claimed that their clamd process has silently failed and was off line for days, and other such claims. No amount of hand holding for creating config files is going to make that problem better. That requires an interested admin. > > They politely asked to have a bug report opened. They seem willing to make > the change. It's little effort for them, will make many users happier, and > will have absolutely no effect on you. And I've offered earlier an excellent example of a product that goes down that path to help create a new config or to integrate an existing config file with a newer release. Nothing wrong with that - it's a great idea. But in the absence of that, to complain that one's processes have died and mail was tempfailed because of it and that it is the vendor's problem to fix is a freaking stretch. > > Yet you, as a non-ClamAV-developer, are ranting about sysadmin incompetence > and completely ignoring the real issue. The change DOES NOT AFFECT YOU in > the slightest. So what the HECK is your problem? I have no problem, David - I simply offered a means to help empower the interested admin to avoid wading through the docs to see what has changed. I snarkily noted it would probably be too much work for some and damn if the next post didn't validate that. The gentleman truly believes it is necessary to install ClamAV in order to preview the config files. Where do ideas like that spring from? Here's my concern - I'm sharing port 25 with a lot of these people's systems as we all are, and so there is a need and I think expectation that people who have systems that connect to other's systems have a responsibility to keep their systems running properly even when a vendor is not helpful. If they are lax in such a simple thing as configuring this product what other shortcomings do their systems have? I don't run AV tools because I have a problem - I run them because others have a problem. If everyone knew what they were doing and did a good job there'd be no need for any of this. That is an impossible expectation as evidenced by comments in this thread. dp _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
