I can't believe I've been suckered into this nonsense
This is part of the attitude problem from many open source projects.
They are (too often) run by technicians and programmers with no input
from the business side.
OH, lets not forget certain users
What the Clamav team did, I can't believe it would have made it
through a business analyst and I can't believe that any executive
would have signed off on something like that after considering the
potential impact it could have on their clients.
For the last 4 years or so I have had to shift my mindset from that of
pure sysadmin to taking business considerations into account; its very
easy for someone who is absorbed with programming and engineering to
forget that IT is there to support business and that business is not
there to support IT.
This is something that I personally have struggled hard with, it can
be difficult for a 'geek' to move in that direction.
You're giving yourself too much credit. Lets look at this (yet again)
shall we?
People (and you) are upset because they (not me, not them, not the
clamav dev team) decided to ignore the notifications and warnings and
their ( and your) out of date and E-O-L'd AV stopped working. On top of
this due to MTA configuration choices made by some of these same people
when their AV died, so did their mail system. Soooooooo it must be
somebody's fault other than the person(s) in charge of the configuration
and maintenance of these boxes that fault tolerance was not taken into
consideration? Who set up the mail system to die if clam-av was not
available? Not the the Clam dev team.
So many OSS projects do not view their users as clients or customers;
they view them either as experimental subjects or as fellow
experimenters. They only take the technical considerations into
account and largely ignore potential impact on business.
Business impact was caused by the person(s) maintaining, and configuring
the systems that tears are being spilled over. Speaking of impact, what
would the impact be if certain affected customers should find out that
the reason for the service interruption they experienced was because
their service provider couldn't be bothered to take notice of EOL
warnings and properly update their Anti-Virus?
This is true both of the Clamav developers and of those people who
didn't take precautions against potential problems such as the Clamav
developers introduced. (And make no mistake; a problem was *created*
by the Clamav team, a problem that did not exist prior to the changes
they made).
There is no problem. If you want to run a EOL version of ClamAV all you
have to do (I believe) is stop running freshclam. The obvious issue with
this is that you will no longer be receiving virus updates.
If you want to receive virus updates, then UPDATE your version to the
current and functional version.
But no, you expect ClamAV to do what no other company would do. Keep the
old supported and fork the new version so both can be ran.
Perhaps all the fuss is because your dist is also out of date, and not
capable of supporting or compiling the new version? This too can be
fixed by upgrading either your dist, or components.
(Hint: The later only requires sources and the knowledge to use a compiler)
Like I'm sure Microsoft would support a EOL'd OS past it's DOD (Date of
Death). It's just not going to happen. And on the business side, it
doesn't make business sense for them to do so.
This isn't a vendor problem.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
