LFS 6.4 Book HTML

genericmaillists at gmail.com genericmaillists at gmail.com
Sat Apr 4 12:24:20 PDT 2009


On Saturday 04 April 2009 14:28:53 Tomas Klacko wrote:
> On Sat, Apr 4, 2009 at 7:02 AM,  <genericmaillists at gmail.com> 
wrote:
> > On Friday 03 April 2009 23:13:19 Chris Staub wrote:
> >> Jason Erickson wrote:
> >> > I've been using this for the past week learning about linux
> >> > and the installs and it has been a great tool.  I want to
> >> > first thank you for offering this book and helping others
> >> > learn how to build linux from scratch to make our own custom
> >> > installs.
> >> >
> >> > I did notice a few things going through it that I thought
> >> > might be useful to update.
> >> > For Glibc (2.8-20080929) - I couldnt find this so I went to
> >> > Glibc website and got 2.8  I have had no install problems
> >> > with any of the programs by using this code.  The original
> >> > download location of
> >> >
> >> > :ftp:// sources. redhat. com/ pub/ glibc/ snapshots/ glibc-
> >> > : 2. 8-
> >> >
> >> > 20080929. tar. bz2 doesnt seem to exist anymore.  I got
> >> > Glibc from http://ftp.gnu.org/gnu/glibc/glibc-2.8.tar.gz
> >> >
> >> > For section 5.21 Gawk-3.1.6 There seems to be a formatting
> >> > issue....here is what the book says:
> >>
> >> Looks like you missed a page. Both of these are known issues
> >> that have been documented in the Errata -
> >> http://www.linuxfromscratch.org/lfs/errata/6.4/
> >
> > Why should electronic documents (soft copies, live copies,
> > these can always be updated because they are not actually
> > printed and bound) on the Internet be treated in the same
> > limiting manner as a printed document (hard copies once printed
> > bound and distributed cannot actually be changed)? Why not just
> > put the correction in the actual document rather than
> > referencing it some where else? Other documentation for
> > software on the Internet will tell the reader to use a link to
> > the copy found on their site because it is always current.
>
> When you release an electronic document (be it a book
> or a source code), then you would probably give it a number
> or some identification, to identify that particular release.
>
> Then, when you later discover issues in your release,
> would you rather patch them in place, or setup an errata page
> and fix the stuff in the next release?
>
> Tomas Klacko

If it is source code you always give it a number. Open source also 
gets released rather quickley.

Most Distros release fixes or newer versions of apps but they don't 
change the number of the released distro until they make big enough 
changes. They also don't have a separate reference to those changes 
that has to be checked some where else and could be overlooked 
because it is not in the flow of the document.

An electronic book that is designed to be a help to people to learn 
how to do something should not follow the constraints of a 
physically printed, bound and distributed book.

A physically printed, bound and distributed book is constrained that 
way by default. There is no way around that.

To deliberately limit yourself in that manner with a live flowing 
electronic document is just foolish. Why limit your flow of 
communication by following the traditions of an old technology that 
does not have a better choice?

-- 
http://www.wowgreen.net/11324



More information about the lfs-support mailing list