On Apr 16, 2010, at 4:10 PM, Simon Hobson wrote:
Jerry wrote:
> Err, it does have something to do with it. You made the assertion
that no-one would spend money replacing a system rather than upgrade
it. Two of us now have pointed out that real world PHB do exactly
that sort of thing - and this issue with clamav getting the kill
switch can be just the sort of excuse they need. It may not be a
valid reason, but then so many business decisions are based on
having
> enough excuses to do what you want rather than doing what would
logically be right. As Giampaolo comments, some people (especially
PHBs) simply see it as "that Linux stuff blew up, best go with
Microsoft like everyone else".
The two who have "pointed out that real world PHB do exactly that
sort
of thing" now are operating broken systems. So much for credibility.
There you are again - that attitude is rubbing people up the wrong
way and not helping. May I point out that my system was working fine
until fed sour data ? Your analogy would be like saying that a car
is broken if someone put sugar in the tank, and it would be all the
owners fault as long as the vandal (it's claimed) told them in
advance to fit a sugar filter.
No, to use your car analogy, that would be like stating for 6 months
that the fuel was changing and you need to do something about any you
deciding they didn't really mean when you put the incompatible fuel in
your car....
> Fortunately that's not the case where I am - this box replaced an
iMail server running on NT4 which was forever crashing and getting
used for spamming. No-one on the engineering or support teams
mourned
it's loss ! But equally, if it wasn't for the licence costs,
management would still be happier with a Microsoft 'solution'.
NT is ancient history. Why you would even mention it is beyond me,
although it might be interesting to know when they actually did get
around to swapping it out. Then again, maybe I don't want to know.
Yet guess what, NT is still in use in many places (and it's why MS
bought Connectix so they could rebrand their virtualisation software
and sell it to customers so they could run their NT systems on newer
systems). There are many reasons for using old software - in fact I
have a PC down in the garage that still runs DOS/Windows3. In that
case, it's an embedded system and it really, really wouldn't be
worth trying to touch it - only to scrap it and buy another machine.
We've got customers running similarly old software because that's
what the package works with - and it would be horrendously expensive
to upgrade (in many cases meaning scrapping the machine it runs).
Another server I run is also not updated. In this case, not only
would I have to fix any issues related to the server itself - but
I'd also risk breaking any of the customer sites it runs. Just
before it was handed to me, the guy that built it did some updates -
and then handed it over with an "oops, can you fix it" yes I've had
a security issue with it, but that was a config issue. If customers
want to upgrade - I move them to a newer server.
What I'm trying to get through is that there are valid reasons for
not running the very latest bleeding edge stuff. I agree that with
something like Clamav there aren't that many show stoppers, but you
come across as having the attitude that old versions should simply
cease to exist and anyone running then is automatically an idiot.
It would be nice to have a job where all I have to do is run a few
servers - and I have all the time I need to update them (and fix
them when the update breaks it*), but I have a real world job where
that isn't the case.
* BTW - thinking back, I've had more things break from updates, than
I have had problems from not updating. In that respect, even with
this issue, it's not been too bad a return from the policy decisions
I've taken.
--
Simon Hobson
But you have not been forced to go to bleeding edge. 0.95 is outdated
but still receives the updates OK. In all development there comes a
time when you have to break with compatibility in order to achieve the
results you desire. The ClamAV team felt that this was the time.
Jim
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
