April 27, 1999		STNY LUG meeting at Spectra.Net offices.

These notes are Copyright 1998 by Jeremy D. Impson <jdimpson@acm.org>. You
may copy them in their entirety or in part for your own use (any use)
provided this copyright and credit notice is included in the copy.


How to find the answers to Linux-related technical questions on the
Internet.

man pages and accompanying docs are good, but because they are often
written by the software author(s), they often don't do a good job of
explaining 1) what is this software, 2)why would I want to use it, and 3)  
how do I (being a product of the MTV generation) get it to work RIGHT NOW?

DOCUMENTATION

The root (my starting point)
	http://metalab.unc.edu/LDP/
	
Highlights:
	HOWTOs 
		http://metalab.unc.edu/LDP/HOWTO/HOWTO-INDEX-3.html
	
	Linux FAQ (basic questions)		(*)
		http://metalab.unc.edu/LDP/FAQ/Linux-FAQ.html
	
	Installation and Getting Started Guide
		http://metalab.unc.edu/LDP/LDP/gs/gs.html	
	
	the SAG (System Administrator's Guide)	(*)
		http://metalab.unc.edu/LDP/LDP/sag/index.html
	
	the NAG (Network Administrator's Guide)	(*)
		http://metalab.unc.edu/LDP/LDP/nag/nag.html
	
	the Linux User's Guide
		ftp://metalab.unc.edu/pub/Linux/docs/linux-doc-project/users-guide/
	
	the Linux Programmer's Guide
		http://metalab.unc.edu/LDP/LDP/lpg/index.html
	
	The Linux Kernel			(*)	
		http://metalab.unc.edu/LDP/LDP/tlk/tlk.html
		
		
An asterisk (*) indicates that I (Jeremy) have actually used this guide in
early days, I still use the HOWTOs regularly


Not part of the Linux Documentation Project, but mailing list archives,
especially searchable ones, are incredible resources, especially for
resolving strange dependency issues, such as buggy hardware revisions.


USENET, web boards, and mailing lists

Please exhaust all of the above resources before posting to USENET,
mailing lists, etc.  The chance is very good that someone has had this
same problem before, and someone else has solved it.  Then, go to DejaNews
and AltaVista and do some searches.  The signal-to-noise ratio can be very
low, but it is worth a shot.  After all that(*), try these--

General Linux questions:
	comp.os.linux.misc
	comp.os.linux
	comp.os.linux.answers
	alt.uu.comp.os.linux.questions	(I occasionally use this, because fewer people use it than others, and thus there is less crap).
	comp.os.linux.admin
	linux-config@vger.rutgers.edu	(Majordomo)
	linux-admin@vger.rutgers.edu	(Majordomo) 


Getting timely information (I post STNY LUG meeting announcements here0
	comp.os.linux.announce

Distribution specific questions:
	alt.os.linux.slackware
	http://www.slackware.org/
	http://www.redhat.com/	-- this has plenty of publicly available mailing lists
	http://www.debian.org/	-- this too

Networking questions:
	comp.os.linux.networking
	linux-net@vger.rutgers.edu	(Majordomo)

The kernel development list:
	linux-kernel@vger.rutgers.edu		(Majordomo)
You probably don't need to post here. YOu really only post here if you are
developing a device driver and need the help of the elder gods, if you
have a well thought-out architectural suggestion.  Enquiring of the
existance of a driver for peculiar hardware is tolerated, because often
one of the head hackers may actually have something that they though no
one would be interested in.


(*--one exception to the "scour the Internet first, post questions second"
creed is the STNY news group.  It would be nice to get more traffic
there.)

When posting to one of these places, here are some things to consider.

1) Have specific subject lines.  I for one delete all USENET posts that
say "Problem".  I just don't have time to read them to see if I know
anything about their problem.

2) Along similar lines, say exactly what the problem is in the first
paragraph.  Give more details (symptoms) in the next.

3) Then tell about the environment--what distribution, what hardware, what
is the function of the box.  If you think it relevant, list the RAM
amounts, CPU type, BIOS revs.

4) Then, if you have any suggestions as to what the problem might be, list
them.  But don't confuse people by putting them first.  If you say "I know
the problem, and its X, but I don't know how to fix it".  If you don't
know how to fix it, it may not actually be X that is causing it.  But
someone who might have known that it was really Y causing the problem sees
you say that it is X, and knowing nothing about X (but a lot about Y),
stops reading and goes on.

Finally, ask Jeremy.  If he doesn't know how to fix it, he'll make
something up.  And it'll sound convincing.

--Jeremy