> > this is the first time, in SEVERAL years that i work with IT, > > that i've seen a software publisher pushing a 'kill' signature to its > > own software. > > Could you please qualify that statement. Do you mean that this is the > first instance of this kind you have experienced in several years, > meaning of course that there is a precedence for it, or that it is the > fist time in the several years you have worked at your profession that > you have observed this behavior? Your statement, as it now stands, is > ambiguous.
He is CLEARLY stating that he is several years he is working in IT, and that during his multi-year professional work he never saw a software publisher pushing a kill signature. What do you have to disambiguate? > > it's VERY common in the software industry to stop supporting old > > versions, but they simply stay working. They're outdated, > > unsupported, but they keep working. I have a working Redhat 9 machine > > running until today, despite the fact it's SEVERAL years unsupported > > and deprecated. Is this the best thing to do ? No, absolutely not, i > > dont want credits for that. But hey, it simply continue working. > > Many of use have taken that route as a 'stop gap' measure. However, to > instigate it as an official protocol is just asking for trouble. > (Reread > this thread for further details) Was the 'stop gap' really useful? To which purpose? Did the ClamAV team meant to stop old installations to work, in order to silence competitors? Perhaps to teach to clamav users about the very complex nature of today systems and services? Unfortunately, the net result will be that the management of the small companies running their crappy and old mailing systems will have to hardly face the fact their mailing box doesn't work anymore because a free component in it unreasonably stopped working. This will decrease their trust about free software: they are going to buy a new computer running Microsoft Exchange Server backed by something else then ClamAV... > > clamav took a VERY bad move, there's absolutely no doubt on > > that. This will surely affect the software credibility, as you can be > > sure that LOTS and LOTS of email servers are broken since the > > signature was published. > > Whether or not they make a bad decision is your unqualified opinion. It was blatantly a very bad move, because it assumed that the whole clamav user-base was diligently upgrading their clamav installations. Which can't be. > In addition, would you please be so kind as to qualify the "LOTS and LOTS" > with some actual documentation. Why? He got into this trouble but was knowledgeable enough to report his story to this mailing list. A lot of small, almost unattended mail servers run into the very same troubles. Their admin have already upgraded their installations or are unwilling/incapable to report here their story. So multiply 1 by at least 100000 and you get an idea... There are now at least 100000 people which are regarding clamav and (which is worst) open software less respectfully, now. > > despite the fact there's was good reasons for doing that, it WAS > > a VERY bad move IMHO. > > That statement is diabolically opposed to itself, although you did > qualify it with a "IMHO" disclaimer. > > The bottom line is you did not pay for or (to the best of my knowledge) > develop this software. You have no standing on the matter of how the > ClamAV team distributes it product. > > The ClamAV team choose to take the advice of Ricky Nelson, "You can't > please everyone so you have got to please yourself." Now that is the > bottom line. The bottom line is that there were very simple ways to circumvent the problem (see my previous posts). This time, it seems to me that the ClamAV team was a bit too lazy to implement them... Giampaolo _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
