M. Fioretti wrote:
So, my advice is "just do it". someone will fix it.
Here I could simply answer "after you, please" or repeat what I wrote
above: we're talking about quality, not quantity. But I have a very
fresh, real world example of somebody who "just did it" and things
didn't go as you say, so I'll let that speak for itself. Have a look
to the thread about Postfix How-tos starting at
http://archives.neohapsis.com/archives/postfix/2008-12/0133.html
There is a problem peculiar to the free/open source world in that poor
quality versions of things have no reason to ever go away. That takes
care of itself in the commercial versions where there is a cost to
maintain them and when the value no longer covers the cost they will die
gracefully and disappear. I don't have a solution for this - it is
just an observation that if anyone ever releases bad documentation or
even advice, others will be finding and following it years later via
google and other archives.
the thread summary is:
- postfix gurus only wrote good, but too difficult docs
- some popular postfix howtos (by other people who "just did them")
are broken
- newbies read **those** docs only, as the "official" ones are too
difficult
- they make mistakes following those docs, ask how to fix them to the
postfix list. This happens several times a year.
- every time, postfix gurus answer "those docs are broken, check the
official docs"
- for any number of reasons, postfix gurus have no plan to write better
howtos themselves
- nobody but postfix gurus could write better howtos than those
already available, or fix those ones. Excepted a good technical
writer **paid** enough to spend on the subject lots of time, since
it isn't an easy task by any means.
I have a different take on this. Complex programs like postfix have
(and need) thousands of options to cover every possible case. However,
there are probably less than a dozen mail server configurations that
anyone who is not already an expert should try to implement. Rather
than confuse people who should be just following standards with the
thousands of options they shouldn't touch anyway, we need a dozen
templates for this sort of program and something that makes it easy to
adapt any needed local settings without breaking the template-provided
program operation settings.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
