Get rid of (information for) lazy people - A proposal

Steve Wolfe nw at
Thu Sep 19 13:24:46 PDT 2002

> > If in the end we have a linux from scratch
> > encyclopedia, being the system build only a small part of it, good!

   Wow.  I believe that for the LFS project to try to be everything to
everyone would be a great disservice to the LFS project.  I think that
nearly everyone agrees that there has to be a limit as to how much the LFS
project provides, and after that, the end-user should look for other
sources of information and support.  The only question is this:  Where,
exactly, should the limit be set?

   Perhaps the idea lies not in having the LFS project try to be
everything, but in allowing other parties to create auxiliary
documentation.  I imagine that there are a lot of LFS users that would not
be able to contribute much to the actual LFS development, but could
contribute at least some useful, meaningful documentation that would
supplement the LFS book.

   Following that idea, a system of collaborative supplementation might be
just the ticket.  Keep the core LFS book at more-or-less the same support
level as it's at, but give each section it's own supplementary - but
seperate - documentation.  The mechanics of maintaining the auxiliary
documentation wouldn't be much different than any other collaborative
documentation effort.

   As an example of what I'm thinking of, let's say that I'm browsing the
LFS book via a web browser, and I'm on the step where glibc needs to be
compiled.  I'm curious about different versions about glibc, or how I can
minimize the size, or whatever.  Somewhere on the page, I see a link
titled "Auxiliary documentation", and click on it.  Now, I have access to
the various bits of wisdom that have been left for wayward stragglers such
as I.

   The number of contributors to the auxiliary documentation could vary
widely - anywhere from "A select chosen few" to "Anyone in the world".  My
guess it that something in the middle ("A medium-sized field of people
that have shown themselves somewhat trustworthy") would be best, but
that's up for debate.

   Again, the mechanics and semantics would need work.  We'd want those
who could contribute to the LFS book itself to do exactly that, while
allowing those who can offer a bit of related advice to help in the amount
that they are able.


Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list