No sound lessons
beesnees at grm.net
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