Ian Eiloart wrote: > Because ordinary users and IT staff have different needs. Regardless of > what professionals actually do, they bloody well ought to think about it > first.
You are absolutely, 100% correct. I am also correct when I say that expecting that to happen in the real world is pretty naive :-) Software developers have a responsibility to make sure that upgrades happen with as few surprises as possible. As a concrete example: When PhishingScanURLs went on by default, I thought it was OK. Our mail server doesn't get enough volume to make the excessive CPU use a problem. Our larger customers got a nasty surprise, though. There simply wasn't enough information about the new feature for professionals to decide about it without reading the source code. Once I read the source code, it became obvious to me that it was a really bad idea and a really terrible implementation, so we scurried around turning it off on our customer installations. We shouldn't have had to do that. I shouldn't have to read source code to decide whether or not to use a new feature. > I don't mean the new feature should be on by default. Just that clamav > should start even in the absence of a config file with a setting for that > feature. So that the new code is backwardly compatible with the old config > file. Agreed, and the default setting for new features (in the absence of a config file) should be "off". Regards, David. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
