Bruce Dubbs wrote: > Perhaps we need to let the editors scratch their itch to present things that > they feel are useful That could be dangerous! The way the book is laid out now, I fear it would lead to a hodgepodge of unconnected ideas scattered throughout the book, or worse yet, conflicting ideas or configurations.
Going back to Alexander's point above about Jim's Courier instructions: They were good! They worked well, until nobody wanted to use Courier anymore and we could not validate the instructions in the book. That is a good example of why *not* to add this type of information directly into the book. I used it for a while, and Jim's hint had a lot more information, but later I wanted more...single sign on, redundancy, greylisting, better filtering, more tweaks, etc. and neither Courier's MTA, nor SQL provided the best and/or easiest path to my goal. Courier would work fine against virtual users in LDAP, in fact the authdaemon and maildrop do work nicely as I still use those, but it would increase the page size tremendously to cover both configurations. Further, when an update occurs, both configurations would have to be validated before a version bump could occur in the book. My take is still that the wiki is the perfect place for this type of information. I think the wiki should be an incubator of sorts for new content intended for the book and really it should be merged with hints. How about, at least for now, rather than drastically changing the book, we provide an additional reading section on each package to make internal docs (hints/wiki) more visible. Better, move the currently valid hints (and all new ones) into the wiki under the same chapter headings as the BLFS packages, and provide links, in the book, upon the wiki author's request. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
