Some alternates for dependencies
Bill Maltby at home
billm at wlmcs.wlmcs.com
Sat Feb 16 02:56:19 PST 2002
Oh Gerard, Gerard, Gerard...
Tsk, Tsk, Tsk. It sounds as if "pride goeth before a fall". If learning is
still an important goal, some considerations would be spurious - like whether
not grepping takes too long. The point is, IMO, "does it make it better/faster
for someone (new) to learn/install".
In article <20020215152800.A18646 at gwaihir.linuxfromscratch.org>,
gerard at linuxfromscratch.org (Gerard Beekmans) writes:
>> Nice thing to have but not for the book. The dependency lists have already
>> made grepping through the book a major PITA and I would love to see them
Have any of you spent _major_ effort trying to find the information you need
from many documents that are not cohesive? _That_ is a major PITA, _especially_
when trying to learn/do something new. Personally, I don't mind grepping/diffing
and sorting. It _can_ be mechanized, after all. This is one of the first things
I did _after_ my first fully manuall install. _And_ I did it against the HTML,
not the text. It takes a little more work to install, but I _learn_ more by
constantly reviewing the changes. Since it's all in a single document, I get
my needed daily dose in one spoonful, not 3 or 4 different spoonfuls.
>> kicked out of the book again. I think all of this belongs in a separate
>> document, not inlined with the text.
What is the focus of LFS? If it is just the mechanicals of installing, then
alfs will (eventually) displace LFS and we'll just have another RH/VA... Linux.
New users will tend to learn less and learn it slower, if at all. Imagine
settling in with your favorite novelist only to find you have to go get three
more books to finish the story.
>I wholeheartedly agree that it's not a nice thing to have when reading the
>.txt version of the book (I believe you use the .txt files mostly, right?).
>But not taking txt in mind, I think a condensed list is still nice. Then
>again, it'll be a very incomplete list and there is something to be said
>for "why settle for something incomplete while you can download the
Amen brother! He has _not_ lost sight of the light! Condensed _and_ complete!
Recruit, recruit so both objectives can be met in a single doc.
>I will just have to give this some thought. I'm also thinking again about
>the package descriptions among the installation instructions (they are fine
>in the Appendix though).
I'm aghast! Have you never considered eye flow and associativity? Stream of
conciousness? I _like_ "turning the page" and seeing a "complete" set of in-
structions, warnings, alternatives _and_ snigglets of information about the
components related to that package. It's so... related. Being my brain is an
associative processor, this helps assimilation and digestion of the info.
If a good part is moved "out of line", I must process an interrupt! Not good.
>I'm leaning towards making chapters 5 and 6
>installation instructions only (plus the installation instruction
>explanations) and in the future with the dynamic book generation thing you
>could enable the inclusion of those chunks on the installation pages if you
>really want to.
>This isn't a case at all where "Majority Rules". Even if everybody thinks
>it shouldn't be changed, I'm still looking at the layout of the book and if
>it looks profesional, etc. Currently it just doesn't.
This is the "pride" part. "Looking professional" is nice, but IMHO, is contrary
to the spirit of LFS? RedHat "looks professional". So does Microsoft. Need I say
more about it's relative importance in the grand scheme of things?
>-*- If Linux doesn't have the solution, you have the wrong problem -*-
>Unsubscribe: send email to listar at linuxfromscratch.org
>and put 'unsubscribe lfs-dev' in the subject header of the message
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev