[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