plans and wishes

Bill's LFS Login lfsbill at nospam.dot
Thu Jan 15 15:31:09 PST 2004


On Thu, 15 Jan 2004, Alex Groenewoud wrote:

> Greg Schafer wrote:
> > On Tue, Jan 13, 2004 at 11:15:25PM +0100, Alex Groenewoud wrote:
> > ><snip>

> > > b) Move the section on Asking for help to an appendix, and refer to it
> > > from somewhere at the beginnig of chapter 5.
> >
> > I'd object to this, unless you can provide rationale.
>
> Offering help right at the start makes it look to me as if we expect
> that people _will_ need help.  And to my mind makes it look too
> inviting.

That's pretty thin reasoning. I believe *most* technical publications
have introductory text that provide references to places to get help or
additional information. There is also usually a much more extensive
list very late in the book. I have never heard anyone disparage that
because it "looks like they will need help". I tend to think it shows an
awareness of reality (some folks may need help), consideration for those
with more curiosity and helping the user because if and when help is
needed, a reference has already been seen and (if they are like me) they
easily recall that it was up in the introductory sections.

That's really *consideration* for the user, a good thing.

><snip>

> But we shouldn't have memorized those numbers, sorry.  As Jeroen said,
> we should look at what is best for the readers, not for the editors.

Within reasonable limits, yes. What's reasonable is quite subjective and
there will likely be several different views on that.

><snip>

> > > j) Change from using $LFS to /lfs.  If we can make a symlink on the
> > > host's root dir, we can also make a mount point.
> >
> > I object. We already make a mount point i.e. /mnt/lfs. What would this change
> > buy us?
>
> Not having to explain $LFS.  Not having to say to do an 'echo $LFS' two
> or three times.  Not having to remember to set LFS also when being root
> just before chrooting.

$LFS does serve a purpose though. How often might it serve that purpose?
I don't know about typical users. From a maintenance of the book
standpoint, one instance of setting LFS, with explanation, allows the
rest of the book to be totally independent of the actual *value* of
$LFS.

This same benefit then extends to the user who might (as I do) have
multiple build directories, each with its own name that helps me
identify what each is for. I can have concurrent build structures in
place and by just setting $LFS to the appropriate value, I'm ready to
roll. No additional changes to commands and text in the book needs no
interpolation.

Lastly, it can be used in various in-line documents ("here" documents)
with an unprotected delimiter to automatically insert the correct value
of $LFS into the document, avoiding manual changing of those if you are
working in another area.

All of which is meaningless if you expect that our audience
(intermediate-to-advanced users) would never dare deviate from the
book's instructions.

On a general note, this feels like "dumbing down" the book.

>
> Alex

-- 
NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
lfsbillATearthlinkDOTnet
Fix line above & use it to mail me direct.



More information about the lfs-dev mailing list