Not to start a war here or discourage anyone but...

Have any of you at any time, in your own opinion found the LFS Book has better or clearer documentation than the Gentoo Handbook?

I can actually say...

Yes... to this question.

After attempting to read the Gentoo Handbook today I found that there are many things overlooked and under-documented by the handbook. By comparison to the attention to detail, I actually can say LFS seems so much easier to understand and seems more thorough.

It actually makes me appreciate LFS's book a lot due to it's superior level of documentation, even if it takes longer to build. It's like I know exactly what I'm doing without confusion.

I second that, Gentoo's documentation is always mostly out of date and when it is up to date it feels like the always seem to skimp on the details of why things need to happen this way or that way.

It's strange, but every time I've attempted to install Gentoo, each and every time, the install has always failed at some point. Either the kernel build errors, the kernel panics on load, or something was always missing to where nothing worked at all, or I got lost in the setup stages and said "screw it".

To me honestly, I actually wonder how anyone has really got Gentoo to work at all outside of using a Live Disk to install it.

LFS is supposed to be a more advanced distribution than Gentoo also, but it feels the exact opposite.

I gave up on Gentoo when I couldn't get - I think it was udev support in Thunar, or maybe it was something with udisks, I wanted to mount partitions in Thunar - without pulling in gnome-keyring. (I hate that stupid keyring, that eats all my passwords and leave everything unprotected...) I even tried to change the ebuilds, but couldn't find all places that was pulling it in.

Then I found out LFS was actually easier to install and get how I want it. I also think it was difficult to understand the instructions about Gentoo.

I've not used gentoo but have used loads of other distros over the years, debian,ubuntu,mint,sabayon,slackware,yellowdog,opensolaris and probably a few I've forgotten, but I have found the LFS book and associated documentation to be the best of the bunch and will probably never switch to another distro now.

I've installed Gentoo about 10 times on computers ranging from a PIII with 128MB of R.A.M. to a laptop with a 4th-generation Intel Core processor, and don't see much wrong with the main handbook. Some of the wiki pages are out-of-date to varying degrees, but I haven't found anything essential to be missing. But then, maybe I know most of what needs to be done already, so maybe I know how to fill in the gaps?

I've installed Linux from Scratch twice, and I can't fault the documentation, apart from the fact that it's tedious, which is more a reflection of the nature of the project itself. Then again, after you've installed L.F.S., you still can't do much with it. From there, you need to move into B.L.F.S., which for me was hours upon hours of tracking dependencies manually. If I want X, I need a, b, c, and d, and for optional feature e, I need 1, 2, and 3. Then for b, I need subdependencies 1b, 2b, and 3b... and so on and so on. Thank goodness I use Openbox, because I would never want to install something like Gnome in Linux from Scratch.

Gentoo has many possibilities. You can use GRUB or LILO. You can use OpenRC or Systemd. You can install Gnome 3 or no desktop environment at all. L.F.S. is like this, as well, but Portage automates dependency resolution, downloading, configuring, compiling, and installing the packages, and so on.

L.F.S. walks you through by the hand with every single command that you need to run to get a specific minimal installation. Then B.L.F.S. might or might not have specific instructions for what you might want to do next. Gentoo teaches you how to make the minimal installation, and gives you guidelines on what to do from there, along with specific instructions for various extras.

I believe gentoo chooses who it will work for, and I am not among the chosen. Over the years I've installed most advanced distro's, arch, lfs, slackware, freebsd, openbsd, but I have never gotten gentoo to work outside of a livecd, or the xbox. I eventually got it to install once, except for sound and network, and after some time, in fustration "rm -rf" the whole thing.

LFS was fun, but I soon realized that I needed to have a second computer or dual-boot another distro in order to do my homework. I still remember the feeling of excitement when I realized that I had built my very own linux system from scratch and the immediate dread when I realized I still had a long way to go to get firefox and open office installed before I failed out of college.

edit: yes, i found lfs easier to understand.

The LFS and BLFS books are indeed excellent. For my purposes (and I don't necessarily recommend this for newcomers to the system), I actually benefit from occasionally consulting the archived books in the museum such as this earliest one from December 1999:

http://archive.linuxfromscratch.org/...OWTO-1.0-HTML/

Following the evolution from the old static build era to the sophisticated shared library model used nowadays without any leakage from the host gives me greater appreciation for the architectural elegance of LFS/BLFS and reveals just how consistently good the book has been over almost 15 years.

The good thing I've noticed is you can take the LFS and BLFS books and apply them to just about any other Linux distribution to rebuild packages when documentation is scarce. Few if any other distributions can stake that claim that their methods can be universally transferred into another distribution.

The only other documentation I've found that's transferable as well is Slackware's Slackbuilds community project scripts which can be used with some editing or reference to install software into LFS/BLFS.

I think we are still talking apples an oranges. LFS is more of a teaching tool. One can't really afford the time needed to create and maintain a working lfs system in production. Gentoo could be used to create a working production system and maintain and update it.

I know your question is about documentation. Unfortunately I haven't read manuals with a child's eye in many years. I tend to make my own mistakes by jumping pages.

Why not? I have kept my 2 lfs-system updated for a year now, upgraded from LFS-7.2 to LFS-7.4. I build the updated packages at home and put them in my dropbox, and then I can just install them on my machine at work. And sometimes I have time to do the opposite, and build the packages at work and put them in my dropbox, so I have them when I come home. With scripting it's usually fast.

You don't even really need a package manager either, at least from my point-of-view. Usually anymore I have rebuilt packages without installing them after resolving all their sub-dependencies with make && make install && make clean very similar to how FreeBSD manages it's ports collection, so that if I need to remove a package all I need to run is make uninstall, and then do whatever else is needed.

As far as documentation goes, I've found the more detailed the documentation, the better the system is overall because if something screws up you don't get lost and have a broken system to deal with.

Teaching tool regarding LFS is a very reaching term. Slackware in my opinion is a better introductory and teaching GNU/Linux distribution. Yes, some stuff in the LFS books teach you, but often at times, even BLFS and LFS have their limits.

I've actually been debating whether or not to craft up a complete public script set for LFS and BLFS I'd like to dub as ELFS (Expanded Linux From Scratch) that goes into extras that can be used with either LFS or BLFS outright. I've just started but I'd like some help into the project if anyone is interested.

It's great knowing how to manage dependencies and configure, compile, install, and configure post-installation various programs, but doing all these steps manually for each upgrade seems a bit tedious. If I had infinite time (say a TARDIS and infinite longevity), I wouldn't mind using Linux from Scratch and keeping it up-to-date. Since I don't, I use L.F.S. as a learning tool, and use Gentoo for its automation.

It seems to come down to this, basically:

1. Find what program I want to install for a certain function.
2. Recursively find all the dependencies that are required or satisfy extra options that I want to enable.
3. Download, extract, configure, and compile the source code, then install the packages in order.
4. Troubleshoot and fix any errors.
5. Set up the programs post-installation with any run-time options that I want.

Having learned to do all this, I don't lose much from automating steps two and three, and it saves a lot of time.

Usually resolving dependencies manually is relatively simple.

On non-BLFS/LFS packages often I'll look at Slackware's SlackBuild scripts and get a generalized idea for the configuration and building, then work on dependencies.

I often use the readout from ./configure to see if any dependencies are missing at that time, and then go hunt them down and see if they exist on SlackBuilds.org and follow their list, or utilize the readouts from ./configure to see what else is supported.

The thing with Linux is resolving dependencies is one of the core aspects anyone using Linux should learn. Often at time, all you'll have is a configure script and a makefile and nothing else along with some piss-poor documentation that says nothing about the dependencies. Know how to resolve them is one thing that is a much have in a skill set.

My point wasn't that resolving dependencies isn't simple, but that it's time-consuming. Sure, I know how to (a) read the L.F.S./B.L.F.S. documentation to see what dependencies I need, (b) read the website for the program to see what its maintainer says it needs, (c) run ./configure and, based on an error message, figure out what dependency I am missing, or (d) check in Gentoo to see what it needs.

My point was that doing all this is unnecessarily time-consuming after I already learned how to do it the first time. For me, there is no point in going back and doing it all again, because I probably won't learn much new this time, since I've done it at least twice already.