No sound lessons

Dan McGhee beesnees at
Mon Aug 22 03:35:46 PDT 2005

Randy McMurchy wrote:

>Andrew Benton wrote these words on 08/22/05 01:20 CST:
>>That doesn't mean that it isn't an issue. I remember when I first did LFS getting sound to work was a big deal and it was the same issues that Randhir is reporting. I didn't post to the list about it, I struggled in silence and used Google. Just because people don't post to the list doesn't mean that they aren't having issues. You shouldn't just dismiss someone for talking about their experiences. BLFS may be very good but it will never be perfect, there will always be room for improvement
>Andy, with all due respect, how to unmute the channels is clearly
>pointed out in 'man alsamixer'. BLFS is not in the business of
>rewriting documentation that already exists. Please understand I
>am not trying to "dismiss" the suggestions provided by the OP, I
>am only stating that for BLFS to include what he is asking for, is
>to be duplicating existing documentation.
>Surely, we expect folks to use the man pages, right?
I've been eavesdropping on this conversation.  Please excuse my butting in.

IMHO you are both right--as is Rhandir.  I describe my competency level 
as "advanced noob."  This means that I have enough knowledge to break my 
box and then try to figure out how to fix it.  My path through Linux has 
been Redhat --> Mandrake --> LFS/BLFS.  It has taken me four years to 
get here.  I am also a user, not a programmer.

There are a number of forces at work in linux, and, specifically here, 
BLFS.  Among these are a user's desire to have things work "out of the 
box" or, failing that, specific instructions to make things work.  On 
the other hand, here in LFS and BLFS, the goal is to build at least an 
operating system, if not a distro, and configure it for running.

I'm not sure of any statistics, but I believe that many linux users, 
including myself, are windoze refugees.  For that system user, most 
operations are hidden and one just "points and clicks" to acheive 
success.  If something doesn't work, one just gets more software and 
uses more memory --> gets a faster processer --> adds more RAM --> gets 
a bigger hard drive --> etc, ad nauseam.

In linux, if something doesn't work "out of the box," there's an implied 
responsibility on the part of the user to figure out how it works and 
fix it, or, at least, to learn something about how the app or utility 
works so that the user, then, can ask "intelligent" questions for help.  
For windoze refugees, this is a steep learning curve. [I know :)]

My criticism of linux, in general, (but not of LFS/BLFS--more later) is 
that much of the documentation, including the man pages, is confusing, 
not-helpful, poorly written and geared for programmers.  I personally 
have offered to help in these areas for a number of applications, but 
have been rebuffed or have been told that I need to learn either XML or 
SGML so that I can submit edits in the "right" format.  (I believe that 
this syndrome is just the opposite of the "out of the box" syndrome.)

After a few days or weeks of google, the Linux Documentation Project and 
man pages, a user may ask for help on a forum or mailing list--with 
varied degrees of response and expertise.  This brings me to LFS/BLFS.

You folks who have the experience in this project are walking a razor's 
edge in this area.  Why?  Because you are so knowledgeable and helpful.  
Of all the forums (more properly fora) and mailing lists that I have 
haunted, this list is the most responsive and helpful.  Somewhere in the 
archives there's a statement something to the effect, "...if it has to 
do with configuration regardless of the topic, it belongs in BLFS."  
That's a great attitude!!!

Both the LFS and BLFS books are so well written and edited, that many 
people, I think, will suggest additions outside the goals of LFS/BLFS, 
as may be the case here.  These books are almost "cookbooks," and, if it 
means anything, pass my tests for well written documentation.  However, 
I still think it's incumbent on users to do research on a given 
situation.  Yes, unmuting the mixers in ALSA is a piece of basic 
knowlege and I have no problem with anyone gently, but firmly, saying to 
someone, "RTF man pages, HOWTO, guides, or README."  Doing this research 
in linux seems to be a "right of passage"--and necessarily so.  In 
linux, as opposed to windoze, the user makes it work, not the software.

A good example of this situation is the INSTALL documentation for 
building kernels.  It talks in there about NOT building in /usr/src and 
mentions contamination by the "kernel du jour."  But that's all it 
says.  It was not until LFS that I learned about the headers and that I 
could actually build in a different directory as me, and not root, and 
why this was better.  It was as clear as mud in the kernel documentation.

I've preached long enough.  I apologize.  Just wanted to add my 
$0.02--adjusted for inflation, of course.  Maybe someday I will have 
more knowledge to be able to contribute more here and take some of the 
load off you seasoned veterans.  Until that day comes, keep up the good 
work and thanks.


More information about the blfs-support mailing list