LFS 6.4 Book HTML
viperjason at gmail.com
Sat Apr 4 14:32:29 PDT 2009
There are always sub-revisions of source code. Minor things get fixed
and promoted as the newest. Like the kernel for instance. There is
2.6.x.y Major version is 2.6 and then there is a minor release of x.
Bug fixes for x get a number put into y.
For the book, it could be 6.4.X where X is the latest version of the
6.4 book. Only changes made would be spelling, grammar, and FTP
Just my 2cents.
On Sat, Apr 4, 2009 at 12:24 PM, <genericmaillists at gmail.com> wrote:
> On Saturday 04 April 2009 14:28:53 Tomas Klacko wrote:
>> On Sat, Apr 4, 2009 at 7:02 AM, <genericmaillists at gmail.com>
>> > 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?
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
More information about the lfs-support