On May 4, 2012, at 1:53 PM, Bruce Dubbs wrote:
> Qrux wrote:
>
>>> The users need to learn to think about what needs to be done, not just
>>> copy/paste without understanding.
>>
>> As a proxy example of ambiguity, do you not see the...confusion...some might
>> experience when in your previous email, you said:
>>
>>> If you follow the instructions literally, they work. Making inferences and
>>> adding things not in the book is where users run into problems.
>>
>> "Think!" "Don't infer!"
>>
>> I'm saying it could use more clarity. You're saying that you're not
>> technically wrong. Those two can exist at the same time.
>
> But what you are asking for is more instructions, not more clarity.
I said several things. The first is that there is some potential for ambiguity
in statements like:
"Think, but don't infer."
Then, as a practical approach, I suggested repetition--after I suggested more
"signposts" that warn of potential pitfalls. Don't latch on. It was just an
example. You seem to be entrenched in the idea that "if you need signposts,
you're (careless|stupid|lazy). That's not always the case.
One solution is to keep saying: "Reread Section 5."
I'm exploring other solutions, because I think it's silly to insist that the
book is well-written when, for every single release, many people are confused
by how to begin Chapter 5. I didn't have an issue. But I can certainly
understand how others might.
> Section vi. "It is also expected that you have a reasonable knowledge of
> using
> and installing Linux software.:
>
> Section 3.1. "Downloaded packages and patches will need to be stored
> somewhere
> that is conveniently available throughout the entire build. A working
> directory
> is also required to unpack the sources and build them. $LFS/sources can be
> used
> both as the place to store the tarballs and patches and as a working
> directory."
>
> Section 5.3. General Compilation Instructions "For each package: Using the
> tar
> program, extract the package to be built. In Chapter 5, ensure you are the
> lfs
> user when extracting the package. Change to the directory created when the
> package was extracted."
>
> How do we clarify that? Repeat it for every package? If there is something
> unclear, I'll change it, but I can't read it for the users.
If you always have the same issue at the same point in the book, you might come
to the conclusion that it's a hard part, and only (careful|smart|hard-working)
people will understand. You could also conclude that it's a confusing part
(perhaps also hard), and while we need people to be able to read, we can also
provide a warning here that highlights the relative importance of this
statement.
The point is, there is plenty of prose in the book. I could completely skip
every word of Section i, Section ii, Section iii, Section iv, and Section v,
and successfully build the book. In fact, I've done exactly that, and had no
issue.
But, then, you want me to read Section vi and take it as gospel? Are you
starting to understand what I mean about signposts? There is nothing special
about the appearance of Section iv. Do you see how that might relate to
organization of the information, and not the content?
> We did add to 5.4: "Go back and re-read the notes in the previous section.
> Understanding the notes labeled important will save you a lot of problems
> later."
And, while the unpacking instructions in 5.3 are indeed marked as "important",
do you also see that Sections 5.1 and 5.2 are completely irrelevant to the
explicit directions? You know how some text books often have sections which
are only meant to be read in an advanced course? Well, 5.2 is exactly like
that. But, why strew information all across the book? Chapter 5 is the
backbone to the entire thing. But it starts with a somewhat irrelevant section
(5.1), and an advanced section (5.2). Then, you want people to know that the
"Important" part of (5.3) is *actually* important?
Here's something "Important" from 5.2:
====
"Before continuing, be aware of the name of the working platform, often
referred to as the target triplet. A simple way to determine the name of the
target triplet is to run the config.guess script that comes with the source for
many packages. Unpack the Binutils sources and run the script: ./config.guess
and note the output. For example, for a modern 32-bit Intel processor the
output will likely be i686-pc-linux-gnu.
"Also be aware of the name of the platform's dynamic linker, often referred to
as the dynamic loader (not to be confused with the standard linker ld that is
part of Binutils). The dynamic linker provided by Glibc finds and loads the
shared libraries needed by a program, prepares the program to run, and then
runs it. The name of the dynamic linker for a 32-bit Intel machine will be
ld-linux.so.2. A sure-fire way to determine the name of the dynamic linker is
to inspect a random binary from the host system by running: readelf -l <name of
binary> | grep interpreter and noting the output. The authoritative reference
covering all platforms is in the shlib-versions file in the root of the Glibc
source tree."
====
I'd argue that it's not important at all. Maybe to someone who's taking LFS
and working on a derivative work. Or to someone who's messing about with the
toolchain.
But, put simply: it's pretty hard to separate the complete irrelevance of
5.2-"Important" from the absolute necessity of 5.3-"Important". This is an
issue of poorly structured book organization--not the information intended to
be conveyed in the book.
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
