[mdlug] Future presentations.

[Mat Enders]

link works now must have been a temporary issue with the server

On Tue, Jan 17, 2012 at 7:52 AM, 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



-- 
Mathew E. Enders

"Where once Samba and Apache sold Linux to the world they are now just
part of the plumbing.  But that's OK, plumbers make good money."
--Jeremy Allison