LFS Future Braindump
randy at linuxfromscratch.org
Tue May 27 06:51:43 PDT 2008
Robert Daniels wrote these words on 05/25/08 09:00 CST:
> My first point is one that has brought up before. We need better
> descriptions of the packages and why you might want them.
Essentially, what you're saying is that the documentation that
describes the packages is lacking. That would be true in many,
many open source projects. To most, documentation is not very
Unfortunately, we can't "task" anyone to do it. We need
volunteers who will step up and say they are willing to do it.
> To take an
> example from the above project, "The OpenLDAP package provides an open
> source implementation of the Lightweight Directory Access Protocol."
> In my early Linux days, I thought 'OK that's nice, so what is this LDAP
> thing actually used for? I seem to access my directories just fine
> without it, so what's different about this?' We all do a wonderful job
> of documenting build dependencies, instructions, and methodologies, but
> less so on why we are building things.
I've always looked at it like this:
1. Just because a package is in the book, be it a dependency of
another package or not, doesn't mean that we expect folks to
2. If someone doesn't know what a package does, or is used for,
then they need to research it. BLFS shouldn't do *everything*,
folks should do some research on their own.
3. If someone doesn't know what a package does, or is used for,
and they don't don't bother researching it, then they probably
don't need it.
Many packages are very complex and as Bruce has said, whole
books have been written about them. What one person needs LDAP
for, may be irrelevant to another. Bottom line is that one
needs to do some research on their own.
Personal Observation and strictly just a humble opinion:
Too many suggestions are being made to turn BLFS into a
"Distro". I don't think that is what [B]LFS is all about.
But mostly, I don't think there would ever be enough manpower
to document [B]LFS so well and so complete that one could
blindly follow along and end up with a "Distro". There must
be some guiding reason why one is installing the packages
they are installing.
> Second, I find that there is an almost total lack of information on how
> to make the various pieces work together. Without that knowledge to
> tie everything together, it's difficult finished product that is more
> than a big mashup of software. For my example, I know I need OpenLDAP,
> Kerberos, Cyrus-SASL, and probably a database like PostgreSQL. It
> seems the most likely way to go is use LDAP directly, using Kerberos as
> a backend for authentication, and the database for information storage.
> But maybe I'm supposed to use Kerberos directly, and the authentication
> then fetches all my information from and LDAP backend. And just where
> does SASL fit into all this?
Google is your friend. I am a firm believer in that we don't
need to document everything like that as it is already documented
elsewhere on the web. [B]LFS has always tried to maintain the
position of 'don't redo documentation that is already provided
elsewhere' (simple paraphrased paragraphs presented for
> These issues led me back to Alan Lord's suggestion about transforming
> LFS into a set of course modules. This would be quite a change to the
> books, not a short-term project and not one to be done lightly. I
> personally think this format would be very good for the LFS project.
> It would be better suited to provide the solution to problems like
> mine. Explain each piece's purpose, and what place it has in the
To me, that would require a completely different mindset for
how development works, and would then be near-sighted, because
the way I see it, whoever and for whatever reason someone writes
something might be a completely different reason for why someone
else needs something. Subjective, subjective, subjective.
The last thing I think BLFS needs to do is have documentation
for 6 scenarios where Cyrus-SASL could be effective. This information
is already out there, and I'm a believer that it is good for folks
to have to do some work on their own.
> Whether LFS goes down a road similar to that or not, I think parts of
> these ideas could be used without changing things too drastically. For
> one, one the Stunnel page, we currently refer the Samba instructions
> for a concrete example of the configuration and usage of Stunnel. I'd
> like to see more of these use cases and examples of software
I agree that this would be good (and not because I was the one
that wrote the Stunnel-Samba example). But only in cases where a
clear example such as this can be easily documented. A hodgepodge
of examples that one may or may not need would get confusing.
> Second, it might be worth considering reorganizing the
> BLFS book. Instead of all the packages being listed on the front page
> separated into general categories like "General Utilities"
> and "Servers", there could perhaps be a front page where the user would
> select a purpose for the end system, eg 'Webserver' or 'Home Desktop'.
> The selection would link to a page listing the various types of
> software one may be interested in for that purpose. So a dedicated
> webserver likely wouldn't need a an office suite or cd burning
> utilities, while your average home desktop has no need of an http
> server or Kerberos.
I disagree that the "average home desktop has no need of an http
server". But that is just me. And that is the problem. I don't
think BLFS should be in the business of recommending what a
"webserver" needs, or what a "desktop" needs. We create instructions
to build packages that one can use to build whatever it is they
want to build.
I don't think examples of prototype versions of "whatever" type
of platform one may want is the business we should get into. Far
too subjective for one thing. But mostly, it's back to a manpower
thing. Shoot, we can't even get package updates done on a regular
basis any longer, how can we expect to keep up entire examples
of various platforms?
> These different sections would directly list only
> applications and daemons the user would directly interact with.
> Libraries would just be accessed through dependency links from the
> top-level applications. For the most part, this would just be a
> rewriting of the various index files, not touching the package pages.
> The hard parts would be deciding on a set of target purposes, and
> deciding what packages do or do not fit under a particular purpose.
> That would be somewhat arbitrary, some home desktop users really do
> want to run an http server.
I used this example above, without ever even reading this, so it
does show that it would be nearly impossible to "catagorize" the
packages for one purpose or another. Again, there is so much out
on the web about all this already that it could turn BLFS into
an incomplete reference about everything. Why should BLFS provide
information that skims over a subject when we could simply
provide a link to complete and thorough coverage of it?
> Also, a link to a flat listing of all
> packages included in the book would be included, equivalent to the
> current index of the BLFS book. If there is interest, I can try to
> hack up a quick version of this idea.
I'm not sure what you even mean by this. We have this in the
index already, what more would be different about it?
Disclaimer for all of my responses:
My thoughts and ideas are not meant to discourage folks from
considering the ideas being presented, it is simply my observations
of some of the likely pitfalls and impossible situations.
rmlscsi: [bogomips 1003.22] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 220.127.116.11 i686]
08:18:00 up 99 days, 23:06, 1 user, load average: 0.00, 0.07, 0.08
More information about the blfs-dev