Also, gents.
ufdbGuard is cool, but:
- Where is good documentation? I found only one connon PDF. No
performance recommendations, no administrator's guide - this good piece
of software not so trivial as squidGuard, i.e., I don't know, how to
support only used blocking categories databases without rebuilding them
all, no concepts guide - the architecture of solution is not obvious.
May be I need glasses, but Reference manual + man pages is not enough
for average SA's. Not at all will read sources.
- AFAIK, it uses daemon-centric architecture. Well, but different OS
uses different startup facilities. I want to have possibility to tune it
up by myself or installation must correct do it on target OS. And please
note, that not only Linux existing in the world. ;) SystemV init was
deprecated in some systems years ago. ;) And will be good to document
all of this in installation guide.
Did you agree?
17.02.15 17:28, Antony Stone пишет:
On Tuesday 17 Feb 2015 at 11:00, Marcus Kool wrote:
On 02/16/2015 11:43 PM, Amos Jeffries wrote:
PS. Marcus, perhaps you should go on search around to find distro
maintainers who are publishing SG and convince them to replace the
defaults with ufdbguard. I have to do that periodically to clear up old
Squid versions being forced on users. It helps to find out what bugs
they are patching or struggling with silently as well.
For reasons unknown I am not very good in convincing other people what
they should do :-)
Perhaps it is better to wait for the time that maintainers and admins
see for themselves what is best.
Hm, the problem I see with that is that package maintainers are not always
admins of the systems using those packages, therefore they're not the people
who run into the problems caused by outdated packages.
Lots of system admins (the ones who don't appear on this list, for example)
just assume "it's the current software being provided by my distro, therefore
it must be the one recommended by the developers", therefore they never find
out that the developers of the software recommend doing something new, while
the package maintainers have never moved on from old versions or old
techniques.
I do think we need to inform package maintainers that what they're doing is no
longer what the developers recommend, to try to close the gap between the
people who start from "here's what I get from my distro" and "but this is the
right way to do things" (which we see often enough on this and similar lists).
When the package maintainer is a developer, this situation generally sorts
itself out pretty quickly, but this is not often (AFAIK) the case, so
announcing the current recommendations to the people runnning the distros can
make a big difference.
Regards,
Antony.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
