LFS Future Braindump

DJ Lucas dj at linuxfromscratch.org
Sun May 25 11:52:19 PDT 2008


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.




More information about the blfs-dev mailing list