[mdlug] Future presentations.
Mat Enders
mat.enders at gmail.com
Tue Jan 17 08:34:31 EST 2012
Excellent response Adam however your link is broken.
Adam Tauno Williams <awilliam at whitemice.org> wrote:
>On Mon, 2012-01-16 at 11:46 -0500, Garry Stahl wrote:
>> > Yes. Thank you for the presentation. We'll have to think of more topics like this.
>> I can think of one, but I'll be damned if I can think of an adequate
>> presenter. Linux education. As a newbie slowly crawling out of that
>> state I have noted that most help is not very helpful. To paraphrase,
>> the average advice to newbies breaks down thus:
>
>I whole-heartedly *disagree* with the premise of this message. I'm not
>a newbie, but I was a newbie, and I interact with a lot of newbies. My
>single most emphatic bit of advice of newbies is: SLOW DOWN! Mostly I
>watch newbies flail about in veritable panic and throw solutions at
>problems in a terribly ineffective manner [like
>reinstall-reinstall-reinstall, install-more-packages, etc...]. There is
>nothing specific to LINUX or IT about this; slow and methodical wins
>the race [in any problem domain]. Stop and *think* about a problem,
>start from the bottom and work up [is the cable plugged in, is the link
>light on, do I have an IP address, do I have a gateway, can I ping the
>gateway...] Even after 20+ years of sys/net-admin I... start at the
>bottom and methodically work up. It works. Lunging to a *theoretical*
>source of a problem prior to gathering all the information is a recipe
>for failure [again: in any problem domain]. Slow down. Get a cup of
>coffee. Think. And not only will you be able to solve more problems
>you will also learn a great deal more from the process.
>
>> Newbie: "I have a dillywhop problem"
>> Guru 1: "Gain the knowledge level I have then do X and Y."
>> Guru 2: X might be helpful, but Y will simply muddy the problem, I
>> suggest you read the man page and try Z.
>> Guru 3: "X and Y worked for me."
>
>This sounds like an IRC conversation. Newbies have no business asking
>questions in IRC channels. IRC channels are a *BAD* source of
>information.
>
>Go where the Gurus are - the mail lists - and don't say "I have a
>dillywhop problem". If you say that you *DESERVE* an off-the-cuff
>stupid response. Say "I have dillywhop problem and I am running version
>XYZ of the relation application on a 64 bit whuzit-distro. Previously
>this did/did-not work when running version ABC. I don't believe I have
>changed anything relevant"
>
>Note: it said "I don't believe I have.." not "I haven't" because clearly
>you have. Let that sink in.
>
>GIVE INFORMATION! Clearly you are asking because YOU DO **NOT** KNOW
>why it is not working, so don't give *LESS* information. If I have to
>beat the poster for more information I'm going to just move on. It is
>*YOUR* problem and you want *MY* time so.. POST THE #$*&&*(!@Y$ RELEVANT
>INFORMATION.
>
><http://catb.org/~esr/faqs/smart-questions.html>
>
>Who takes there car into an auto-shop, drops of the keys and leaves a
>note saying "sometimes it doesn't start". You say "Here is my '68
>t-top camero and on really damp morning sometimes the engine cranks but
>it doesn't start"
>
>> Yes, our little group is as guilty as any other in this respect. The
>> steepest part of the Linux learning curve is often the people that try
>> and help you.
>
>Bogus. The steepest learning curve is typically learning to
>systematically approach problems. Again, irrespective of the problem
>domain.
>
>Here is my #1 tip:
>At the end of every message just always include:
> Distribution version and platform (x86, x86_64, Atom, etc...)
> Output of "uname -a"
> The *exact* version of the related package from your package manager.
>Just do it - every time. period. no exceptions. If you really can't
>take the time to do that.... why should I take the time to ask you for
>that information? Not sure what package(s) is related to the problem...
>take a guess, include a few. That at least some effort [which equals
>respect].
>
>> Things to Not Do:
>> 1) Read the Man page: These documents are written by everyone from
>> Charles Dickens, to Charles Manson. Many assume a certain level of
>> technological knowledge and are singularly unhelpful to-the beginner.
>> Most resemble crib notes for those than know what they are doing and
>> are meaningless jargon to those that don't. Like 90% of computer
>> documentation, useless.
>
>Bogus. Many man pages are very good.
>
>> 2) Type anything into the CLI:
>
>I'm sympathetic to this; but you really limit who can help you hear
>since the GUI admin tools are the one of most distribution specific
>components. And with the exception of YaST they generally SUCK and are
>quite limited
>
>> 4) Forget that not everyone is a coder: The question used to be is
>> Linux ready for Grandma?
>
>Yes, it is. Linux works great for Grandma. She will rarely flail about
>and break things.
>
>> As long as knowledge of the CLI is required,
>> no. This doesn't mean that Grandma is stupid. Many people are
>> excellent drivers, they use their cars successfully every day to
>> accomplish the tasks they need to do. Some are even professional
>> drivers that make a living with their cars. That doesn't mean they can
>> fix the engine or repair the suspension.
>
>This analogy is fallacious. Grandma can't fix or even install any OS.
>She can use them quite effectively.
>
>> car or design and print all your own books? Respect the fact that not
>> everyone can be a computer wizard, but the computer is a necessary tool
>> in today.s world.
>
>And the end-user asking for free advice can treat the 'guru' with the
>same respect they'd use when approaching an auto-mechanic or doctor at a
>social gathering when they intend to pump them for free advice.
>
>> 2) Remember that this person wishes to learn.
>
>No, I don't believe it always clear that this is true.
>
>> Do not place roadblocks in
>> the path of those that seek knowledge, help them as you yourself would
>> like to be helped.
>
>I do exactly that.
>
>> 5) Encourage questions. THERE ARE NO STUPID QUESTIONS!!
>
>Incorrect. There are stupid questions; or maybe not stupid but
>"disrespectful" and "uninteresting" questions. Like questions whose
>answer can be found in bold print on the home page of a project.
>Demonstrate effort with statements like "I saw the FAQ at <link> but
>nothing there seemed relevant".
>
>> No matter how
>> obvious you might think the answer is, they would not be asking if they
>> understood. Different people have different competencies and differing
>> ways of learning.
>
>Off topic, but I disagree. There is one and only one way to learn:
>Research, try, fail, research, try, fail, research, try, fail....
>succeed! Everything else is blather [educators attempting to rationalize
>their own failure]. There may be real differences in research methods,
>but pragmatically those difference are irrelevant when *seeking* help.
>When seeking the *seeker* does the heavy lifting; that is what "seeking"
>means. Lounging in a comfy chair and postulating is not seeking; that's
>just lazy.
>
>
>
>_______________________________________________
>mdlug mailing list
>mdlug at mdlug.org
>http://mdlug.org/mailman/listinfo/mdlug
More information about the mdlug
mailing list