On Fri, 03 Oct 2008 22:12:49 -0700 John Rudd <[EMAIL PROTECTED]> wrote:
>
>At the very least, when the config file and options change, the ClamAV
>team should post a notice which explicitly lists (and only lists):
>
>1) new config items
>2) removed config items
>3) config items whose syntax, semantics, or options changed, and how
>4) supported but deprecated items, and what, if anything, replaced them
>
>This shouldn't just be buried in release notes, a read me file, or a
>change log. It should be in those places _TOO_, but it should also
>exist as its own stand-alone statement that any one of us can easily
>see and find.
From my experience, if an end user refuses to RTFM, adding additional
reading material is not going to solve the problem. The needed
documentation is all ready readily available. The motivation to fetch
and read it are what is sorely lacking.
>And what they REALLY ought to do is supply a tool which reads old
>config files, and does something like a lint check. With multiple
>verbosity level options, it should read the existing config file, and
>say things like "which lines have errors", "what's wrong with this
>line", "what parts of that line are no longer supported", and if
>possible give the new/current syntax for the line in question. In the
>most trivial case, you should be able to invoke:
>
>clamavcfgcompiler -o oldconfigfile -n newconfigfile
>
>and it will generate the new config if there are no errors, generate
>STDERR reports for deprecated options that aren't show-stoppers, and
>generate STDERR reports and not generate a new config file if there
>are show-stopping errors.
I suppose the development crew could spend the next year or two
attempting to create just such a tool that will work correctly under
all possible OS's and environments; as well as with the diversified
update packages available. Of course the development of ClamAV would
suffer; however, at least one SA would be spared the problem of
actually doing his/her job.
>For those who say "as a sysadmin you should follow best practice X to
>prevent these problems"... the same is easily leveled at the clamav
>developers. They have best practices they should follow as well, with
>regard to supplying software that is commonly, widely known to be, and
>intended to be, used in such critical roles.
"Best Practices" requires any SA, as well as any sane individual, to
properly check out any piece of software before blindly installing it.
This is even more important in any critical 'time' or 'use' situation.
>And, really, they no loner get to hide behind it being a community
>project, it's now owned by a company. If they want to maintain the
>integrity of a company image that provides software that is reliable,
>especially reliable in mission critical roles, then they need to
>address this ASAP.
If, and that is a big 'if', you were paying for the service, you might
have a valid argument with regards to hiding behind the 'beta' or
whatever tag you prefer to call it. However, as a free product, you
enjoy no such luxury. Again, just check out Google and there crap. A
great deal of their garbage will not even run on anything but a Win32
platform.. Are you inundating them with requests to get their act
together? I think not.
--
Jerry
[EMAIL PROTECTED]
I base my fashion taste on what doesn't itch.
Gilda Radner
signature.asc
Description: PGP signature
_______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
