Re: [lfs-support] Chapter 5 questions
I started reading 7.0, and I was doing OK until about Chapter 5. Until I realized that some of my directories didn't seem right. Somehow I ended up with just a sources directory on the LFS partition. I'm not a hardened expert in Linux yet, but I do have some knowledge and I have alot of experience with computers in general. Am I required to be an expert to do this? This is my first attempt at LFS. I am trying to learn Linux at a deeper level. We try to give you a vehicle for learning. Do you? There seems to be an awful lot of hostility on here for newcomers. I'm not questioning the entire LFS philosophy, I just think the book has a couple of things the average newcomer might not understand. If you guys are so hostile to newcomers, then maybe you should just flat out tell them not to be here. Overall I was impressed by the book, but then I come on here for some CLARIFICATION of a few things and I am labeled as stupid and a troublemaker who didn't read anything and knows nothing about Linux. That's some way to greet people who are interested in your project and trying to understand the book. I guess what threw me was in Section 5.4, it says: The Binutils documentation recommends building Binutils outside of the source directory in a dedicated build directory: As I mentioned in one of my previous e-mails to the group, I wasn't too sure what this meant. I didn't understand what ...outside of the source directory... meant. I thought if it was truly outside the source directory, then where does it go? Do you know what the source directory is? Do you know what it means to be 'in' a directory? Yes, I know what it means to be 'in' a directory. But do you not see from a newcomers perspective that you seem to use source directory in more ways than one? $LFS/sources and (for example) $LFS/sources/binutils-x.x could BOTH be referred to as source directories. And when you say to build (again for example) the binutils-build directory OUTSIDE of the source directory, that can have more than one meaning. It could mean to build it outside of the $LFS/sources directory OR it could mean to build it outside of the $LFS/sources/binutils-x.x SOURCE directory, So for example, depending on one's interpretation of source directory, the binutils-build directory could be in either: $LFS/sources/binutils-build/ OR $LFS/binutils-build/ because the second one would indeed be outside the source directory As it stands, I think it can be confusing when to run things as root and when to run them as lfs user as the book doesn't always say. Yes it does. It's not repeated every page though. Under section 2.3 the very first thing one does (other than version-check.sh in the Preface) is create the file system using the mke2fs command. Where does it say you need to be root for that? I'm just saying maybe not everyone knows that you need to be root in order for that to work. Wouldn't it be worthwhile to simply add two words to clarify on page 15? To create an ext3 file system on the LFS partition, run the following [AS ROOT]: mke2fs -jv /dev/xxx I haven't read the entire book, maybe things change later on, but it seems like you should mention this. Also, I think it can be a little confusing as to what directory I am supposed to be in when running the commands sometimes, as that is very important too. What part of: For each package: 1. Using the tar program, extract the package to be built. In Chapter 5, ensure you are the lfs user when extracting the package. 2. Change to the directory created when the package was extracted. 3. Follow the book's instructions for building the package. do you not understand? Wow, again with the hostility. Let's say hypothetically that I have to uncompress the binutils-x.x file. It may not be immediately obvious where one is supposed to be when issuing the command: mkdir -v ../binutils-build cd ../binutils-build Couldn't the book simply clarify (briefly) where the binutils directory should be to clarify it for new users? Are you guys aware that a fairly substantial number of the web links in the book no longer work? I made a list and tried to send it to lfs-dev, but that was before I realized that I had to join it first, so not sure if anyone received it. You are using a book that was published in September. Links change. It's up to you to find new ones. The books are like RFCs. Once published, we do not change that version. I never said I had a problem downloading packages. But it is good to know (now) that you do not revise released books. I was referring to some homepage links which the lfs-dev list has verified. I also tried e-mailing lfs-support-ow...@linuxfromscratch.org about a week ago to get some help, but never heard back from anyone. That's the mailman internal address. You have the right address now. That is the e-mail address given at the bottom of:
Re: [lfs-support] Chapter 5 questions
On 5/4/2012 5:34 AM, Scott Robertson wrote: I started reading 7.0, and I was doing OK until about Chapter 5. Until I realized that some of my directories didn't seem right. Somehow I ended up with just a sources directory on the LFS partition. I'm not a hardened expert in Linux yet, but I do have some knowledge and I have alot of experience with computers in general. Am I required to be an expert to do this? This is my first attempt at LFS. I am trying to learn Linux at a deeper level. We try to give you a vehicle for learning. Do you? There seems to be an awful lot of hostility on here for newcomers. I'm not questioning the entire LFS philosophy, I just think the book has a couple of things the average newcomer might not understand. If you guys are so hostile to newcomers, then maybe you should just flat out tell them not to be here. Overall I was impressed by the book, but then I come on here for some CLARIFICATION of a few things and I am labeled as stupid and a troublemaker who didn't read anything and knows nothing about Linux. That's some way to greet people who are interested in your project and trying to understand the book. I guess what threw me was in Section 5.4, it says: The Binutils documentation recommends building Binutils outside of the source directory in a dedicated build directory: As I mentioned in one of my previous e-mails to the group, I wasn't too sure what this meant. I didn't understand what ...outside of the source directory... meant. I thought if it was truly outside the source directory, then where does it go? Do you know what the source directory is? Do you know what it means to be 'in' a directory? Yes, I know what it means to be 'in' a directory. But do you not see from a newcomers perspective that you seem to use source directory in more ways than one? $LFS/sources and (for example) $LFS/sources/binutils-x.x could BOTH be referred to as source directories. And when you say to build (again for example) the binutils-build directory OUTSIDE of the source directory, that can have more than one meaning. It could mean to build it outside of the $LFS/sources directory OR it could mean to build it outside of the $LFS/sources/binutils-x.x SOURCE directory, So for example, depending on one's interpretation of source directory, the binutils-build directory could be in either: $LFS/sources/binutils-build/OR $LFS/binutils-build/ because the second one would indeed be outside the source directory As it stands, I think it can be confusing when to run things as root and when to run them as lfs user as the book doesn't always say. Yes it does. It's not repeated every page though. Under section 2.3 the very first thing one does (other than version-check.sh in the Preface) is create the file system using the mke2fs command. Where does it say you need to be root for that? I'm just saying maybe not everyone knows that you need to be root in order for that to work. Wouldn't it be worthwhile to simply add two words to clarify on page 15? To create an ext3 file system on the LFS partition, run the following [AS ROOT]: mke2fs -jv /dev/xxx I haven't read the entire book, maybe things change later on, but it seems like you should mention this. Also, I think it can be a little confusing as to what directory I am supposed to be in when running the commands sometimes, as that is very important too. What part of: For each package: 1. Using the tar program, extract the package to be built. In Chapter 5, ensure you are the lfs user when extracting the package. 2. Change to the directory created when the package was extracted. 3. Follow the book's instructions for building the package. do you not understand? Wow, again with the hostility. Let's say hypothetically that I have to uncompress the binutils-x.x file. It may not be immediately obvious where one is supposed to be when issuing the command: mkdir -v ../binutils-build cd ../binutils-build Couldn't the book simply clarify (briefly) where the binutils directory should be to clarify it for new users? Are you guys aware that a fairly substantial number of the web links in the book no longer work? I made a list and tried to send it to lfs-dev, but that was before I realized that I had to join it first, so not sure if anyone received it. You are using a book that was published in September. Links change. It's up to you to find new ones. The books are like RFCs. Once published, we do not change that version. I never said I had a problem downloading packages. But it is good to know (now) that you do not revise released books. I was referring to some homepage links which the lfs-dev list has verified. I also tried e-mailing lfs-support-ow...@linuxfromscratch.org about a week ago to get some help, but never heard back from anyone. That's the mailman internal address. You have the right
Re: [lfs-support] Chapter 5 questions
On Fri, 2012-05-04 at 03:34 -0700, Scott Robertson wrote: Under section 2.3 the very first thing one does (other than version-check.sh in the Preface) is create the file system using the mke2fs command. Where does it say you need to be root for that? I'm just saying maybe not everyone knows that you need to be root in order for that to work. Wouldn't it be worthwhile to simply add two words to clarify on page 15? It might, but see - this is why we emphasise that a certain amount of knowledge is required. We assume that if you're doing an LFS build, you don't need to be told that formatting a partition must be done as root. Please understand - we're not trying to be rude or hostile. We can, and do, make changes to improve the book's instructions, when we find that people are mislead by poor wording or lack of explanation. But well... the instructions you're having difficulty with are ones that many others have been successfully using for many years now. If you're having this much difficulty with them, it does suggest to us that a lack of Linux/Unix experience is a factor. It may not be immediately obvious where one is supposed to be when issuing the command: mkdir -v ../binutils-build cd ../binutils-build Remember the bit change to the directory created when the package was extracted, followed by follow the book's instructions for building the package. That tells you exactly where you should be when running that command. Re-read that page General Compilation Instructions - it really is very, very important, and we've spent an awful lot of effort making those instructions as clear as possible. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
On 04-05-2012 08:23, Eleanore Boyd wrote: On 5/4/2012 5:34 AM, Scott Robertson wrote: [...] Now, have you tried this solution: untar the package, go into the unpacked directory, then do copy+paste operations to make sure you don't inadvertently screw something up? Then all you have to do is make sure you replace certain pieces with the appropriate value for the new system. Tends to work like a charm. (Then again, I have a fascination with progress scrolling up the screen, and progress bars moving...) Elly Scott, Elly is right. Read the printed copy, but copy and paste from the web or from a locally saved copy. You can try to understand everything, but after some machines built, will discover that many things, including commands, variables, configurations, command arguments, were not clear at first sight. With the exception of those who originally built the LFS project from scratch - LFSFS :-), the ones who replied to this thread, myself included, have, at some stage been newcomers to LFS. I had difficulties, but they were exactly due to lack of the required experience. I have always had good support. Eleanore, a high school student working during a computer class and after school on such things as LFS, if I am not mistaken, could even be considered a newcomer, as I only remember her posts since March 2012, although with much better linux background than myself, when newcomer: this is not a shame for me, but it is a honour for her. If we people were rude, you could just be ignored, at least in this thread. But we think that discussion is good and hope you have patience with us, as we have had with you (and others have had with me!). (Mis)quoting what Bruce recently said: try to be on the technical side and remember that faces are not visible in written communication, so a relevant part of information about corporal language is missing, which could be misleading. This is a place for technical discussions, so let us do it peacefully. Finally, thank you for giving this wonderful people the opportunity to show their generous and kind personalities. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
Scott Robertson wrote: What part of: For each package: 1. Using the tar program, extract the package to be built. In Chapter 5, ensure you are the lfs user when extracting the package. 2. Change to the directory created when the package was extracted. 3. Follow the book's instructions for building the package. do you not understand? Wow, again with the hostility. The reason it sounds hostile is because we spend a lot of time trying to explain and users regularly skip the explanations. Whether you skipped reading them or not, your questions indicate that you did not understand them. If you follow the instructions literally, they work. Making inferences and adding things not in the book is where users run into problems. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
On May 4, 2012, at 8:42 AM, Bruce Dubbs wrote: Scott Robertson wrote: What part of: ... do you not understand? Wow, again with the hostility. The reason it sounds hostile is because we spend a lot of time trying to explain and users regularly skip the explanations. Whether you skipped reading them or not, your questions indicate that you did not understand them. If you follow the instructions literally, they work. Making inferences and adding things not in the book is where users run into problems. Easy. :) * * * Scott, please try to understand that LFS is put together by a volunteer corp of programmers and admins, not professional writers. So, there will be parts of the book that are INCREDIBLY important to read, and parts of the book that are more optional in nature. So, try to understand that the point of feedback that sounds like: What part of XYZ don't you understand? is a reminder (though not a particularly nice one) that the problem is likely some assumption you are making, and that much closer attention needs to be paid somewhere--though, in general, that where is not well-marked. That having been said, LFS is a deeply technical project. It's a bit like instructions to build your own particle accelerator, not an Ikea cabinet. Yes, you'll need to read--then reread--every word, and assume that everything is important. * * * LFS devs, writers, and editors, please try to understand that the LFS can read like a list of GPS coordinates given at 1mm spacings without altitude and annotations. If I follow it *exactly*, and assume no errors in the readings or the map, and I make the same set of assumptions as you, then I'll get there. But, if I miss by just a tiny bit, instead of walking along a ridge, I fall off the cliff. Having been around a bit to see users struggle and struggle and struggle with the implied directions in Chapter 5 about unpacking stuff, (esp. when the rest of time you're repeating to people to follow the book VERBATIM), it seems that there could be more warning there. Having said that, I recognize that the editors are professional techies--not professional writers. At least, I hope not. :) If 1 out of every 10 map-users falls off the cliff, is it worth thinking about how to annotate the map instead of insisting that people just stop falling over the cliff? Most of the people who fall over don't seem to be saying the book is wrong (some do, but just have Ken gently accost at those people with obscure classical references...by the time he's done, they'll just think they've been given a Swedish massage in a part of their brain they never knew they had). Does anyone know a technical writer that might be able to offer some time to address that one glaring issue? The message that gets repeated over and over is that LFS is not a distro, but a book. Well, then it's in an interesting category of being both a tech project but also a book. When a written metaphor is weak, we don't usually tell readers to change their mental models (unless you're Joyce); we just get a red pen and write constipated thinking in the margins. Surely there's some room to say that the book needs better writing, even if the instructions are technically correct. Q -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] X unsolved and networking solved
On Fri, May 04, 2012 at 11:14:19AM -0500, Bruce Dubbs wrote: Ken Moffat wrote: Actually, 10 bootable partitions on a dos disk is pushing it - I suppose one or more of /boot, /home, swap is in a primary partition. Why? As of Jan 20, 2010 Disk /dev/sda: 320.1 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0080 Device Boot Start End /dev/sda1 * 63 208844 /boot 100M /dev/sda2 20884519743884 /opt 10G minus /dev/sda31974388525607609 Swap 2G /dev/sda425607671 439398399 Extended /dev/sda52560767346588499 lfs-7.0-rc? 10G /dev/sda64658856367569389 lfs-6.5 10G Aug 2009 /dev/sda76756945387104429 Ubuntu 9.04 10G minus /dev/sda887104493 108085319 blfs dev 10G /dev/sda9 108085383 191992814 /usr/src 40G /dev/sda10 191992878 233954594 /mnt/backup 20G /dev/sda11 233954658 254935484 /home10G /dev/sda12 254935548 317862089 ?? 30G /dev/sda13 317862153 338842979 lfs-20110110 10G /dev/sda14 338843043 359823869 lfs-20100816 10G /dev/sda15 359823933 380804759 lfs-7.1-rc1 10G /dev/sda16 380805120 419866623 ubuntu 11.04 20G /dev/sda17 419868672 439398399 ubuntu 10.10 9G -- Bruce I believed, obviously wrongly, that the maximum value for a logical partition on dos disks was 15. Did you have to do the math yourself to get the sizes in that table ? ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
Qrux wrote: LFS devs, writers, and editors, please try to understand that the LFS can read like a list of GPS coordinates given at 1mm spacings without altitude and annotations. If I follow it *exactly*, and assume no errors in the readings or the map, and I make the same set of assumptions as you, then I'll get there. But, if I miss by just a tiny bit, instead of walking along a ridge, I fall off the cliff. Having been around a bit to see users struggle and struggle and struggle with the implied directions in Chapter 5 about unpacking stuff, (esp. when the rest of time you're repeating to people to follow the book VERBATIM), it seems that there could be more warning there. Computers are like that. Get one bit wrong and the whole thing fails. What more do you want? 5.3 gives explicit instructions. 5.4 is binutils and the very first thing is a note to go back and ensure you understand 5.3. What we are not going to do is put on every page: tar -xf package.tar.xz cd package . cd .. rm -rf package package-build The users need to learn to think about what needs to be done, not just copy/paste without understanding. Also some users are just not ready for LFS. Section iv says: Building an LFS system is not a simple task. It requires a certain level of existing knowledge of Unix system administration in order to resolve problems and correctly execute the commands listed. In particular, as an absolute minimum, you should already have the ability to use the command line (shell) to copy or move files and directories, list directory and file contents, and change the current directory. It is also expected that you have a reasonable knowledge of using and installing Linux software. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] X unsolved and networking solved
Ken Moffat wrote: On Fri, May 04, 2012 at 11:14:19AM -0500, Bruce Dubbs wrote: Ken Moffat wrote: Actually, 10 bootable partitions on a dos disk is pushing it - I suppose one or more of /boot, /home, swap is in a primary partition. Why? As of Jan 20, 2010 Disk /dev/sda: 320.1 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0080 Device Boot Start End /dev/sda1 * 63 208844 /boot 100M /dev/sda2 20884519743884 /opt 10G minus /dev/sda31974388525607609 Swap 2G /dev/sda425607671 439398399 Extended /dev/sda52560767346588499 lfs-7.0-rc? 10G /dev/sda64658856367569389 lfs-6.5 10G Aug 2009 /dev/sda76756945387104429 Ubuntu 9.04 10G minus /dev/sda887104493 108085319 blfs dev 10G /dev/sda9 108085383 191992814 /usr/src 40G /dev/sda10 191992878 233954594 /mnt/backup 20G /dev/sda11 233954658 254935484 /home10G /dev/sda12 254935548 317862089 ?? 30G /dev/sda13 317862153 338842979 lfs-20110110 10G /dev/sda14 338843043 359823869 lfs-20100816 10G /dev/sda15 359823933 380804759 lfs-7.1-rc1 10G /dev/sda16 380805120 419866623 ubuntu 11.04 20G /dev/sda17 419868672 439398399 ubuntu 10.10 9G -- Bruce I believed, obviously wrongly, that the maximum value for a logical partition on dos disks was 15. I think the max is 63, but that would be in the kernel and maybe grub. Did you have to do the math yourself to get the sizes in that table ? Yes. I just did fdisk -l /dev/sda disk-layout and edited that to add my notes. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
On May 4, 2012, at 10:15 AM, Bruce Dubbs wrote: Qrux wrote: LFS devs, writers, and editors, please try to understand that the LFS can read like a list of GPS coordinates given at 1mm spacings without altitude and annotations. If I follow it *exactly*, and assume no errors in the readings or the map, and I make the same set of assumptions as you, then I'll get there. But, if I miss by just a tiny bit, instead of walking along a ridge, I fall off the cliff. Having been around a bit to see users struggle and struggle and struggle with the implied directions in Chapter 5 about unpacking stuff, (esp. when the rest of time you're repeating to people to follow the book VERBATIM), it seems that there could be more warning there. Computers are like that. Get one bit wrong and the whole thing fails. What more do you want? 5.3 gives explicit instructions. 5.4 is binutils and the very first thing is a note to go back and ensure you understand 5.3. What we are not going to do is put on every page: tar -xf package.tar.xz cd package . cd .. rm -rf package package-build Would it be hard to put an unpack_warning entity before each of the Phase 1 builds (all 2 or 3), or even the Phase 2 builds (those same 2 or 3)? It's about signposts. You know. Like the ones with the squiggly road to indicate curves ahead. Yes, speed limits, if rigorous observed will work most of time (though not always, like when HWY 17 was first built, with incorrectly counter-banked turns). So, a bit more information, with a warning sign, can help, when there's a confusing situation. I didn't say the instructions were wrong. I said signposts--or better writing--could be used. Writing means many things. In this case, you seem to be focusing on the words themselves. But what about structure? A little repetition goes a long way. 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. Q -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
On Fri, May 4, 2012 at 12:48 PM, Qrux qrux@gmail.com wrote: On May 4, 2012, at 8:42 AM, Bruce Dubbs wrote: Scott Robertson wrote: What part of: ... do you not understand? Wow, again with the hostility. The reason it sounds hostile is because we spend a lot of time trying to explain and users regularly skip the explanations. Whether you skipped reading them or not, your questions indicate that you did not understand them. If you follow the instructions literally, they work. Making inferences and adding things not in the book is where users run into problems. Easy. :) * * * Scott, please try to understand that LFS is put together by a volunteer corp of programmers and admins, not professional writers. So, there will be parts of the book that are INCREDIBLY important to read, and parts of the book that are more optional in nature. So, try to understand that the point of feedback that sounds like: What part of XYZ don't you understand? is a reminder (though not a particularly nice one) that the problem is likely some assumption you are making, and that much closer attention needs to be paid somewhere--though, in general, that where is not well-marked. That having been said, LFS is a deeply technical project. It's a bit like instructions to build your own particle accelerator, not an Ikea cabinet. Yes, you'll need to read--then reread--every word, and assume that everything is important. * * * LFS devs, writers, and editors, please try to understand that the LFS can read like a list of GPS coordinates given at 1mm spacings without altitude and annotations. If I follow it *exactly*, and assume no errors in the readings or the map, and I make the same set of assumptions as you, then I'll get there. But, if I miss by just a tiny bit, instead of walking along a ridge, I fall off the cliff. Having been around a bit to see users struggle and struggle and struggle with the implied directions in Chapter 5 about unpacking stuff, (esp. when the rest of time you're repeating to people to follow the book VERBATIM), it seems that there could be more warning there. Having said that, I recognize that the editors are professional techies--not professional writers. At least, I hope not. :) If 1 out of every 10 map-users falls off the cliff, is it worth thinking about how to annotate the map instead of insisting that people just stop falling over the cliff? Most of the people who fall over don't seem to be saying the book is wrong (some do, but just have Ken gently accost at those people with obscure classical references...by the time he's done, they'll just think they've been given a Swedish massage in a part of their brain they never knew they had). Does anyone know a technical writer that might be able to offer some time to address that one glaring issue? The message that gets repeated over and over is that LFS is not a distro, but a book. Well, then it's in an interesting category of being both a tech project but also a book. When a written metaphor is weak, we don't usually tell readers to change their mental models (unless you're Joyce); we just get a red pen and write constipated thinking in the margins. Surely there's some room to say that the book needs better writing, even if the instructions are technically correct. Q @Qrux.Qed: You have said it nicely... you do have a very valid point on how to present the information... -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
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. If we add the unpack instructions for the first 10 packages, someone will complain when they get to package 11. Repetition is not the same as clarity. 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. 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. Note that we did add a similar note to 5.5. GCC-4.7.0 - Pass 1. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
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
Re: [lfs-support] Chapter 5 questions
On 5/4/2012 4:45 PM, Qrux wrote: 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
Re: [lfs-support] Chapter 5 questions
Qrux wrote: One solution is to keep saying: Reread Section 5. 5.3? 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. The problem is that some users are trying to build LFS before they have sufficient background. You obviously do have the background, but it's not appropriate for others who have basically never used a shell to start LFS until they have developed more experience. The first clue is when users refer to folders instead of directories. 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. Yes, you could, but as I said, you have the appropriate background. I think everyone needs to read vi and vii. 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? Speaking of understanding, what does that mean? 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: [deleted quote] I can agree that the section of 5.2 could be changed to a note. There are 3 important sections in chapter 5, and 6 in chapter 6. 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. Is the extent of the changes you think are needed to just relabel one section? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
On May 4, 2012, at 3:23 PM, Bruce Dubbs wrote: 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: [deleted quote] I can agree that the section of 5.2 could be changed to a note. There are 3 important sections in chapter 5, and 6 in chapter 6. 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. Is the extent of the changes you think are needed to just relabel one section? If LFS is just a source code project, then to some extent you can say that prose style or organization is irrelevant. It's not, because it's often repeated that it's a book, as well. So, style is important, because organization can aid understanding. Which is to say, I think you missed my point about Sections (i) through (v). I didn't say (vi) or (vii), which I agree are more important, if not misplaced. But, (i) through (v) are pretty much irrelevant to a user. Why not just start at (vi)? Sure, the original creator should get a foreword, but then jump to the stuff that matters. Then, go straight into the build bits. All the motivation stuff--which, while fine for the start, should not be in the same (section|chapter) whatever as the irrelevant information. That should be canned into an appendix, or the *actually* important bits (e.g. vi and vii) moved into a different part of the book. As for the rest of what I said, sure...you could boil it down to: * Get rid of 5.1 and 5.2, or maybe move them into 4.x as a footnote. * The start of 5 should be: You'd better start paying attention, right the frak now. * Followed immediately by Important FOR USERS: Here's how to unpack stuff...blah blah blah So, yes, you could take what I've said and do some minor edits, but that feels like CSS decorating a web page. Alternatively, you could consider making changes to the organization of the book as it impacts readability. Traditionally, editors do that. In this case, you and Matt are more the technical reviewers. I assume that neither of you are writers...If so, then I apologize, but I still stand by my analysis. I'm saying the organization of the prose bits needs work. Which is different from Well, dude--spit it out. You want the red to be redder and the 'Important' to be a larger point-size? which seems to be more of what you're after. Q -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
Qrux wrote: If LFS is just a source code project, then to some extent you can say that prose style or organization is irrelevant. It's not, because it's often repeated that it's a book, as well. So, style is important, because organization can aid understanding. The descriptions and the organization is important, but it satisfies most users. We probably go through this discussion two are three time a year. Each time it's a single user that doesn't quite get it (you got it without problem). Since we have over 23000 registered users, I'd say that the vast majority get value from the book as it is. I'm not willing to make major changes for a vocal few. We will have to agree to disagree and move on. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
On Fri, May 4, 2012 at 7:02 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Qrux wrote: If LFS is just a source code project, then to some extent you can say that prose style or organization is irrelevant. It's not, because it's often repeated that it's a book, as well. So, style is important, because organization can aid understanding. The descriptions and the organization is important, but it satisfies most users. We probably go through this discussion two are three time a year. Each time it's a single user that doesn't quite get it (you got it without problem). Since we have over 23000 registered users, I'd say that the vast majority get value from the book as it is. I'm not willing to make major changes for a vocal few. We will have to agree to disagree and move on. Just because not many emails or voices out their opinion(s) like @Qrux has done, doesn't mean that they get it. They may not be able to put forth their thoughts like @Qrux has done. LFS is a fantastic resource, but like @Qrux is saying, there is room for improvement to make it even better. If some information on how to contribute in terms of improving the content or presentation style in the How to contribute (http://www.linuxfromscratch.org/lfs/contribute.html) page will be helpful and I would like to pitch in whatever ways I can. cheers... -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Chapter 5 questions
On Sat, May 5, 2012 at 3:28 PM, Anand Arumugam anand.aru...@gmail.comwrote: On Fri, May 4, 2012 at 7:02 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Qrux wrote: If LFS is just a source code project, then to some extent you can say that prose style or organization is irrelevant. It's not, because it's often repeated that it's a book, as well. So, style is important, because organization can aid understanding. The descriptions and the organization is important, but it satisfies most users. We probably go through this discussion two are three time a year. Each time it's a single user that doesn't quite get it (you got it without problem). Since we have over 23000 registered users, I'd say that the vast majority get value from the book as it is. I'm not willing to make major changes for a vocal few. We will have to agree to disagree and move on. Just because not many emails or voices out their opinion(s) like @Qrux has done, doesn't mean that they get it. They may not be able to put forth their thoughts like @Qrux has done. LFS is a fantastic resource, but like @Qrux is saying, there is room for improvement to make it even better. If some information on how to contribute in terms of improving the content or presentation style in the How to contribute (http://www.linuxfromscratch.org/lfs/contribute.html) page will be helpful and I would like to pitch in whatever ways I can. cheers... -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Before deciding how to change the book, shouldn't contributors be clear about (a) the purpose and (b) the audience of the book? It seems to me that there is a mismatch here: people have different views about the audience and purpose, so differ in their perceptions of the book. In my perception the book currently assumes that the audience is people with some (considerable) understanding of the command-line, and OS concepts in general (for example the fact that 'source directory' might have different meanings depending on context). If that is to remain the audience, there needs to be a method for coping with people outside the audience who happen to wander in - just as my local bar has a procedure for dealing with under-age people who wander in. And the purpose of the book (again, my perception) is educational, so the explanations about the tool-chain modifications and how cross-compilation works are not extras, but an integral part of the book. The aim is to learn, not just to get to the end. What that coping procedure should be is a second debate. Slainte Gordon -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
