China DOS Union

How To Ask Questions The Smart Way
The Art of Asking Questions

Copyright (C) 2001 by Eric S. Raymond
Chinese version Copyleft 2001 by D.H.Grand(nOBODY/Ginux)

English version: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Thanks to Eric for his patient guidance and consent, this article was able to be completed and published. The copyright of the English version belongs to Eric Steven Raymond,
and the copyright of the Chinese version belongs to D.H.Grand.

Contents

Introduction
Before You Ask
How To Ask
Choose the right forum carefully
Try to use mailing lists
Use proper wording, correct grammar, and accurate spelling
Send questions in an easy-to-read format
Use meaningful, specific subject headers
Be precise and informative about your problem
Volume is not precision
Describe the symptoms, not your guesses
Describe your problem's symptoms in chronological order
Don't ask people to reply by private email
Be explicit about the question you have
Don't ask questions that should be solved by using a little brainpower
Prune pointless queries
Courtesy never hurts, and sometimes helps
Follow up with a brief note on the solution
How To Interpret Answers
RTFM and STFW: go find out for yourself
If you don't understand...
Dealing with rudeness
On not reacting like a loser
How To Ask Smart Questions
Good and Bad Questions
If You Can't Get An Answer

====
Introduction
====

In the world of hackers, what kind of answer you get to a technical question depends on the difficulty of digging out the answer, and just as much on the way you ask. This guide is meant to help you improve your way of asking questions, so that you can get the answer you most want.

First of all, you must understand that hackers really only like challenging problems, or good questions that stimulate their thinking. Otherwise, what are we even here for? If you have a good question worth chewing over again and again, we will naturally be very grateful. Good questions are a stimulus, a gift, they can improve our understanding, and they often expose problems we had never noticed or thought about before. To hackers,
“Good question!” is heartfelt, high praise.

Although hackers are notorious for scorning simple questions and for being unfriendly, and at times it may seem as though we are hostile to newbies and to those lacking knowledge, that is not really the case.

We do not wish to conceal our contempt for certain kinds of people -- those who refuse to think, or who do not do what they should before asking questions. Such people only murder time -- they only want to take, never give, and pointlessly consume our time, time that we could have spent on more interesting problems or people more worth answering. We call such people “losers” (for historical reasons, we sometimes
spell it “lusers”).

We also know that many people only want to use the software we write, and have no interest in technical details. For most people, a computer is merely a tool, a means to an end; they have more important things to do, and more important lives to live. We understand that, and do not expect everyone to be interested in the technical issues that fascinate us. However, our style of answering questions is aimed at
a different group -- people who are interested, and willing to actively participate in solving problems. This will not change, nor should it change; if it did, we would lose the efficiency that we pride ourselves on.

To a large extent, we are volunteers, taking time out of our busy lives to answer questions, and we are often
flooded with them. So we ruthlessly filter out some topics, especially discarding those who look like losers, in order to use our time more efficiently to answer the questions of winners.

If you feel our over-arrogant attitude is unpleasant and makes you feel wronged, try putting yourself in our shoes.
We are not asking you to bow down to us -- in fact, most of us like nothing more than fair exchange. As long as you make a small effort to meet the most basic requirements, we welcome you into our culture. But having us help people who are unwilling to help themselves
is meaningless. If you cannot accept this kind of “discrimination”, we suggest you spend some money and sign a technical support contract with a commercial company instead of begging hackers for help.

If you decide to ask us for help, of course you do not want to be seen as a loser, much less become one of them. The best way to get an effective answer right away is to ask like a winner -- smart, confident, with a clear way of thinking about solving the problem, only occasionally needing a bit of help on a specific issue.

(Comments on improving this guide are welcome. Any suggestions please E-mail to esr@thyrsus.com, however
please note that this article is not a general guide to netiquette, and I will usually reject suggestions that do not help people get useful answers in technical forums.)
(Of course, if you write Chinese, you'd better send it to DHGrand@hotmail.com ;-)

========
Before You Ask
========

Before asking a technical question by email, newsgroup, or chatroom, check whether you have done the following:
1. Read the manual all the way through, and try to find the answer yourself.
2. Look for the answer in the FAQ (a well-maintained FAQ can cover almost everything .
3. Search the web (I personally recommend google~~~).
4. Ask skilled friends around you.

When you ask your question, first explain what you have done before that point; this helps establish your image: you are not a beggar trying to get something for nothing, and you do not want to waste other people's time. It is even better if you can show what you learned from those steps. If the person asking can learn something from the answer, we are more willing to answer.

Think things through carefully and prepare your question well. Hasty questions get only hasty answers, or no answers at all. The more you show the effort you put into solving the problem before seeking help, the more likely you are to get substantial help.

Be careful not to ask the wrong question. If your question is based on a wrong assumption, an ordinary hacker (J. Random
Hacker) will usually answer you with a pointless literal explanation, while thinking “stupid question...”, hoping that you will learn something from the answer to your question (rather than the answer you wanted).

Never assume you are entitled to an answer; you are not. After all, you are not paying anything for this service. You must “earn” an answer yourself by asking a substantial, interesting, thought-provoking question -- one that potentially contributes to the experience of the community, rather than merely passively demanding knowledge from others.

On the other hand, showing that you are willing to do something in the process of finding the answer is a very good beginning.
“Can anyone give me a hint?”, “What am I missing in this example?” and “What should I check?” are more likely to get answers than “Please post the exact procedure.” Because you appear to have the ability and determination to finish it if someone just points you in the right direction.

========
How To Ask
========

------------
Choose the right forum carefully
------------

Choose where you ask with care. If you do something like the following, you will very likely be ignored or regarded as a loser:
1. Post your question in a forum where it is completely irrelevant
2. Post a very basic question in a forum discussing advanced techniques; or vice versa
3. Cross-post to too many different newsgroups

Hackers often delete questions asked in the wrong place, in order to protect their communities from being flooded by masses of unrelated posts.
You wouldn't want your post to get cut down like that, would you?

Generally speaking, a question posted to a carefully chosen public forum is more likely to get useful answers than one sent to a closed little circle. There are several reasons for this. One is that public forums have more potential answerers; another is that public forums have a larger audience. Hackers would rather let as many people as possible -- rather than just one or two limited individuals -- benefit from the answer.

----------------
Try to use mailing lists
----------------

If a project has its own development mailing list, send your question to that mailing list instead of to some developer, even if you know very well who is most likely to answer your question. Carefully check the project documentation and homepage to find the mailing list address. There are four reasons for this:
1. Any good question worth asking one developer is worth putting before the whole development community. Conversely, if
you think the question is not worth bringing up on the mailing list, then there is no reason to bother any individual developer with it.
2. Asking on the mailing list helps distribute the developers' workload. A particular developer (especially if he is the project lead) may be too busy to answer your question.
3. Most mailing lists have archive history, and those archives can be searched by search engines. People can find your question and its answer there instead of asking the same question over and over on the list.
4. If a certain question gets asked frequently, developers can use that fact to improve the documentation or improve the software, thereby reducing user confusion. But if questions are always asked privately, no one can get an overall grasp of the situation.

If you cannot find the mailing list address for the project and can only see the project maintainer, then write to the
maintainer. In that case, don't assume the mailing list does not exist. In your letter, make it clear that you have
done your best to look for it and still could not find it. Also make it clear that you do not mind if the message is forwarded to others. (Most people think private mail should remain private, even if there is nothing in it that needs to be kept secret. Allowing your message to be forwarded gives the recipient a way to handle your mail.)

----------------------------
Use proper wording, correct grammar, and accurate spelling
----------------------------

Experience tells us that careless writers are usually sloppy thinkers as well (I am willing to bet on it).
Answering questions from careless people is hardly worth it; we would rather spend our time elsewhere.

Therefore, it is very important to state your question clearly and fully. If you find that too troublesome, we will also be too lazy to pay attention to you. Be careful in choosing your words. You do not have to use stiff, formal language -- in fact, hacker
culture values informality. Use slang accurately and speak with humor if you like, but do not misuse it;
you must show that you are thinking and paying attention.

Correct spelling, punctuation, and capitalization matter. Don't confuse “its” and “it's”, or
“loose” and “lose”. Do not write entirely in uppercase; that is regarded as rude shouting (all lowercase is not much better either, because it makes reading difficult. Alan Cox
can get away with all lowercase, but you can't).

More generally, if your question is written like
a semi-literate person, you will very likely be ignored. If you write like
a cracker (a pj enthusiast) or a script kiddie (someone who only uses ready-made tools to make trouble), you are absolutely asking for trouble yourself; you are guaranteed to get nothing but merciless rejection (or, at best, a whole pile of sarcastic and mocking “help”).

If you are asking in a forum that uses a language other than your native one, you may make a few minor spelling and grammar mistakes -- but you absolutely must not be careless in your thinking (yes, we can tell the difference). Also, unless you know exactly what language your answerers use, please use English. Hackers in a hurry often simply skip questions they can't read, and English is the working language of the Internet. Using English can
reduce the risk of your question being thrown away unread.

------------------
Send questions in an easy-to-read format
------------------

If you make your question hard to read and understand, it will be more easily ignored. So you should:
1. Use plain text email, do not use HTML (turning off HTML is not hard).
2. MIME attachments are usually okay, but they must have real content (for example attached source files or
patches), not just file templates produced by your mail client (for example a copy of your email).
3. Do not put all your questions in one giant paragraph with constant line wrapping. (That makes it hard for the person replying to answer only
part of the question; even if they can answer all of it, I would still prefer things to be clearly organized one by one . It is very
likely that the recipient can only read mail on an 80-character-wide text display, so set your line wrap to within 80 characters accordingly.
4. Do not use MIME Quoted-Printable encoding in English-language forums; this encoding is
very necessary for languages that ASCII cannot represent, but many mail agents do not support it. In that
case, the page full of “=20” symbols breaking up the text is ugly and distracting.
5. Never expect hackers to enjoy reading closed proprietary file formats, such as M$ Word
format. Most hackers react to this the same way you would if someone piled steaming pig dung on your doorstep (meaning
no one will step through your door -- translator's note).
6. If you send mail from a Windows machine, turn off M$'s stupid “smart quoting”
feature. This will save you from stuffing garbage characters into your mail.

----------------------------
Use meaningful, specific subject headers
----------------------------

On a mailing list or in a newsgroup, a subject line within about 50 characters is the golden chance to catch the attention
of experienced experts. Don't waste that chance with rambling “Help me” (let alone obnoxious things like “Save me!!!!!”).
Do not imagine you can move us by the depth of your suffering.
Do not use blank space instead of describing the problem, not even for a very short description.

Stupid question:
Save me! My laptop won't display properly!

Smart question:
Deformed mouse cursor under XFree86 4.1, Fooware MV1005 display chip.

If you ask a question in a reply, remember to modify the subject line to show there is a question inside. A question
that looks like “Re: test” or “Re: new bug” is hard to attract enough attention. Also, quote and trim the previous content
to give new readers some clue.

------------------
Be precise and informative about your problem
------------------

1. Carefully and clearly describe the symptoms.
2. Provide the environment in which the problem occurs (machine specs, operating system, application, and anything else).
3. Explain how you researched and tried to understand the problem before asking.
4. Explain what steps you took to try to solve it before asking.
5. List recent hardware or software changes that might be relevant.

Try to imagine how a hacker would question you in return, and answer those questions in advance when you ask.

Simon Tatham wrote an excellent short article called “How to Report Bugs Effectively”. I strongly recommend you read it too.

--------
Volume is not precision
--------

You need to provide precise and useful information. This does not mean you should simply dump tons of broken code or data
verbatim into your question. If you have a huge and complicated test case, try to trim it down as much as possible.

This is useful in at least three ways. First, showing that you made an effort to simplify the problem increases your
chances of getting an answer; second, simplifying the problem increases your chances of getting a useful answer; third, in the process of refining
your bug report, you may discover the problem yourself or correct it.

------------------
Describe the symptoms, not your guesses
------------------

It does not help hackers if you tell them what you think caused the problem. (If your guess were that useful, would you still
need to ask others for help?) So make sure you tell them the symptoms of the problem exactly as they are, and do not mix in your
own interpretations and deductions. Let the hackers diagnose it.

Stupid question:
I keep getting SIG11 errors during kernel compilation. I suspect some flying wire is touching a trace on the motherboard.
What is the best way to check for that?

Smart question:
I built my own K6/233 system, with an FIC-PA2007 motherboard (VIA Apollo VP2 chipset), 256MB
Corsair PC133
SDRAM. During kernel compilation I get frequent SIG11 errors. It starts happening after the machine has been on for 20 minutes; it never
happens within the first 20 minutes after boot. Rebooting does not help, but after powering it off overnight it will work for another 20 minutes. I have replaced all the
memory, with no effect. A typical compile log from the relevant part is as follows...

------------------
Describe your problem's symptoms in chronological order
------------------

The clues most helpful for finding a problem often lie in the series of actions right before it happened, so your explanation
should include the steps you took and the computer's reactions, up to the point where the problem appeared. In command-line cases, keeping a session log (for example using the script tool), and quoting the relevant twenty or so commands can be very helpful.

If the crashing program has diagnostic options (for example using -v to switch to verbose mode), try to think carefully about which option to choose
so that the session log contains useful debugging information.

If your explanation is long (more than four paragraphs), it may help to briefly summarize the problem at the beginning, and then describe it in chronological order. That way hackers will know what to look for in your description.

--------------
Don't ask people to reply by private email
--------------

Hackers believe problem solving should be a public, transparent process. As long as any more perceptive person notices that an answer is incomplete or incorrect, the original answer can and should be corrected. Also, the person answering gets the reward they deserve through having their skill and knowledge noticed and accepted by everyone.

If you ask someone to reply to you privately, you undermine both the process and the reward system. Don't make that request. It is
the answerer's right to choose whether to reply privately -- if they do choose that, it is usually because they think the answer is too obvious or has bad public implications, and others will not be interested.

There is only one limited exception: if you expect to receive a lot of similar replies, you can say, “Mail the answer to me, and I will summarize it.” Saving the mailing list or newsgroup from a flood of duplicate posts
is very gentlemanly -- but remember to keep your promise to summarize.

--------------
Be explicit about the question you have
--------------

Rambling, unfocused questions are almost endless time black holes. The people most likely to give you useful answers are also the busiest
people (they are busy because they personally do most of the work). Such people are not very fond of unbounded time black holes, so it can also be said that they are not very fond of rambling questions.

If you clearly state what you want the answerer to do (give advice, send a piece of code, review your patch,
or something else), you are most likely to get a useful answer. That sets an upper limit on the time and effort involved,
making it easier for the answerer to focus on helping you, and that works very well.

To understand the world experts live in, think of expertise as an abundant resource, while reply time is a scarce resource. The less time your problem takes to solve, the more likely you are to pry an answer out of a busy expert.

Therefore, optimizing the structure of your question and reducing as much as possible the time experts need to solve it
will help a lot -- and that is often different from simplifying the problem. So asking “I want to understand X better,
can you give me some hints?” is usually better than asking “Can you explain X?” If your code
doesn't work, it is wiser to ask what is wrong with it than to ask someone to rewrite it for you.

------------------------
Don't ask questions that should be solved by using a little brainpower
------------------------

Hackers are always good at recognizing which questions ought to be solved by you yourself; because most of us
have solved such problems on our own before. Likewise, these are problems you should work through yourself, and you will learn from it.
You may ask for a hint, but don't ask for a complete solution.

----------------
Prune pointless queries
----------------

Do not end your question with pointless words such as “Can anyone help me?” or “Is there an answer?”
First, if your description of the problem is not very suitable, asking that is just drawing legs on a snake. Second, because
it is redundant, hackers will find it annoying -- and will often respond with logically correct answers
to show their contempt, such as “Yes, someone can help you” or “No, there is no answer.”

----------------------------
Courtesy never hurts, and sometimes helps
----------------------------

Be polite, use “please” more often, and “thanks in advance.” Let everyone know that you appreciate the time
they spend helping you voluntarily.

To tell the truth, although this is not as important as grammatical, clear, accurate descriptions, avoiding private formats, and so on
(and it cannot replace them), hackers generally prefer direct and technically sharp
bug reports to polite nonsense (if this confuses you, remember that we
judge a question by how much it can teach us).

However, if you have many unresolved problems, being polite will increase your chances of getting a useful answer.

(We have noticed that since this guide was published, the only serious negative feedback from senior
hackers has been about thanking in advance. Some hackers feel that “thanks in advance” implies that
you will not thank anyone afterward. Our suggestion is: thank people both times.)

------------------------
Follow up with a brief note on the solution
------------------------

After the problem is solved, send everyone who helped you a note telling them how it was solved,
and thank them again. If the problem attracted
wide attention in a newsgroup or mailing list, you should post a follow-up there.

The follow-up does not have to be long or deeply detailed; a simple “Hi, it turned out to be a bad network cable!
Thanks, everyone -- Bill” is better than saying nothing at all. In fact, unless the conclusion is really very
technical, a short and sweet summary is better than a long academic paper. Explain how the problem was
solved, but there is no need to retell the entire process of solving it.

Besides being polite and providing feedback, this kind of follow-up helps others search the mailing list/newsgroup/forum for the complete solution that helped you, which may also be useful to them.

Finally (at least?), this kind of follow-up helps everyone who provided help gain a sense of satisfaction from it.
If you are not yourself an old hand or a hacker, then trust us: this feeling is very important to the mentors
or experts you ask for help. Problems dragged out forever without resolution are discouraging; hackers long to see problems solved. Good deeds are rewarded; satisfy that desire, and next time you
post a new question, you will benefit from it.

============
How To Interpret Answers
============

--------------------
RTFM and STFW: go find out for yourself
--------------------

There is an ancient and sacred tradition: if you receive a reply saying “RTFM （Read The f\*\*king Manual）”,
the answerer thinks you should go read the damn manual. And basically, he is right -- you should read it.

RTFM has a younger relative. If the answer is “STFW （Search The f\*\*king Web）”,
the answerer thinks you should go search the damn Web. Basically, he is right too, so go look.

Usually, a person who answers you with one of these two lines will give you a manual or a URL
that contains what you need, and while typing those words, they are looking at it themselves. These replies mean the answerer believes (1). the information
you need is very easy to get; (2). searching for that information yourself will teach you more than having it poured into you.

Do not be upset by this; by hacker standards, the fact that he did not ignore your request
already more or less shows he is paying attention to you. You should be grateful for his grandmotherly kindness.

----------
If you don't understand...
----------

If you do not quite understand the answer, do not immediately ask the other person to explain. As when you previously tried to solve
the problem yourself (using the manual, FAQ, the Web, people around you who are good at this), go try to understand it. If
you really do need the other person to explain, remember to show that you have learned something.

For example, if I answer you: “It looks like zEntry is blocked; you should clear it first.” then:

A very bad follow-up question: “What is zEntry?”

A smart way to ask would be: “Oh~~~ I checked the help, but zEntry was only mentioned under the -z and -p
parameters, and neither of them explained it clearly:< Did you mean one of those
two? Or did I miss something?”

--------
Dealing with rudeness
--------

A lot of what seems rude in hacker circles is not meant as an insult. More precisely, it is
the product of a direct, no-nonsense way of communicating, a way that comes from people caring more about
solving problems than about making people feel warm and fuzzy while they still remain confused.

If you feel you are being treated rudely, stay calm. If someone really behaves crudely,
there will usually be elders on the list/newsgroup/forum who will have a word with him. If that does not happen, and
you lose your temper, then it is quite possible that the other person's words and actions are within what the hacker community considers acceptable, and
you will be regarded as the one at fault. That will hurt your chances of getting information or help.

On the other hand, from time to time you will run into genuinely rude behavior and attitudes for no reason. The other side of
the above is that people are allowed to hit real offenders hard, using harsh language to dissect their improper words and actions. If you really decide to do that, first weigh your own abilities very, very carefully. There is only a thin
line between justified roughness and starting a pointless flame war, and many hackers have carelessly charged
right into it. If you are a newbie or an outsider, your chances of avoiding this mistake
are very slim. If what you want is information rather than troublemaking, don't risk replying; it is best
to take your hands off the keyboard.

(Some people claim that most hackers have mild symptoms of autism or social impairment syndrome,
and that they really do lack part of the brain structure that helps “normal people” engage in social behavior. This
may be true, or it may not. If you are not a hacker yourself, then imagining us as
brain-damaged may help you cope with our oddities. Say what you like, we do not care;
we are happy to live by our own ideas, and we are always quite skeptical of medical concepts.)

In the next section, we will talk about another subject; the “rudeness” you may encounter when you step out of line.

================
On not reacting like a loser
================

It is very likely that on forums in the hacker community you will receive a lot of public attacks -- in the various ways described in this article, or in similar ones, and there may also be all kinds of side remarks
telling you how annoying you are.

If the nightmare comes true, the worst thing you can do is whine about it, complain that you were personally attacked,
demand an apology, scream, hold your breath, threaten to sue, complain to his boss,
leave the toilet seat up, and so on and so on. Instead, you should do this:

Let it go, it's no big deal. In fact, doing so is proper and beneficial
(mainly good for body and mind.

The norms of a community are maintained not by the community itself, but by the people who actively enforce them, and that
enforcement is public and obvious. Do not complain that all criticism should be delivered by private message;
it should not be that way. When someone points out that what you said is wrong, or that he has a different opinion,
it is useless to insist that he is humiliating you. Those are loser attitudes.

There are some hacker forums that, because of a misunderstanding of excessive modesty, prohibit participants from posting messages specifically aimed at finding fault with others, and tell them “if you are unwilling to help users, then shut up.” They
believe that steering participants off-topic will only make them indulge in meaningless babble, and thus destroy the point of a technical forum.

Exaggerated “friendliness” (in that style) or useful help: you choose for yourself.

Remember: when a hacker says you are annoying, (no matter how rough the language), and warns you not to do
that again, his real intention is not aimed at (1) you, and (2) his community. He could easily have
ignored you and erased you from his sight. If you cannot manage gratitude, then at least
show some dignity. Do not complain, and do not expect that just because you are a newcomer,
with dramatically sensitive
and fragile nerves and a self-bestowed sense of entitlement, you should be treated like a delicate doll.

==========
How To Ask Smart Questions
==========

Here are a few classic stupid questions, and what hackers are thinking when they refuse to answer them:

Question: Where can I find program X?
Question: My program/configuration/SQL statement doesn't work
Question: Something is wrong with my Windows, can you help me?
Question: I have problems installing Linux (or X), can you help me?
Question: How can I crack root / steal OP privileges / read other people's mail?

Question: Where can I find program X?
Answer: In the same place I found it, idiot -- at the other end of a search engine. Good grief!
Are there still people who can't use Google?

Question: My program (configuration, SQL statement) doesn't work
Answer: That doesn't really count as a question, does it? I am not interested in figuring out your real problem if
I have to ask you twenty questions to get there -- I have more interesting things to do.
When I see this kind of question, my reaction is usually one of the following three:
1. Do you have anything else to add?
2. Too bad, I hope you can fix it.
3. What the hell does that have to do with me?

Question: Something is wrong with my Windows, can you help me?
Answer: Sure, throw away the M$ junk and switch to Linux.

Question: I have problems installing Linux (or X), can you help me?
Answer: No, only by working on your machine myself can I find the problem.
Go ask your local Linux user group for hands-on guidance instead (you can
find a list of user groups here).

Question: How can I crack root / steal OP privileges / read other people's mail?
Answer: Wanting to do that proves you're a despicable person; wanting a hacker to help you proves you're an idiot!

==============
Good and Bad Questions
==============

Finally, I will give some examples to show how to ask intelligently; two ways of
asking the same question are put together, one stupid, the other wise.

Stupid question: Where can I find materials on Foonly Flurbamatic?
Asking it that way is just asking for an answer like “STFW”.

Smart question: I searched Google for “Foonly Flurbamatic 2600”, but
found no useful results. Does anyone know where to find information on programming this device?
This question has already STFWed, and it looks like he really has run into trouble.

Stupid question: I can't compile the source I got from the FOO project. Why is it so lousy?
He thinks it's all somebody else's fault, what an arrogant guy.

Smart question: The FOO project code will not compile under Nulix version 6.2. I read the FAQ,
but it did not mention any Nulix-related problems. Here is the log from my compilation process; what
am I doing wrong?
He explained the environment, read the FAQ, identified the error, and did not push responsibility
onto others. This guy is worth paying attention to.

Stupid question: Something is wrong with my motherboard, who will help me?
An ordinary hacker's answer to this kind of question is usually: “Sure, should I also pat you on the back
and change your diaper?” and then press the delete key.

Smart question: I tried X, Y, and Z on an S2464 motherboard, but nothing worked. I then tried
A, B, and C. Please note the strange phenomenon when I tried C. Apparently there is shrinkage in the sideband transfer,
but the result is unexpected. What are the usual causes of sideband leakage on an SMP motherboard?
Does anyone have any good ideas about what I should test next to track the problem down?
This guy, from another angle, is worth answering. He shows the ability to solve problems,
instead of just sitting there waiting for an answer to fall from the sky.

In the last question, notice the subtle but important difference between “tell me the answer” and “give me a clue, tell me what diagnostic work I should
do next.”

In fact, the latter question came from a real
question on the Linux kernel mailing list in August 2001. I (Eric) was the one who asked it. I observed
this inexplicable lockup on a Tyan S2464 motherboard, and the list members provided important information for solving that problem.

By the way I asked the question, I gave everyone something worth chewing on; I made it easy for people to join in
and get drawn into it. I showed that I had ability equal to theirs, and invited them to explore it with me. I told them what wrong turns I had already taken, so that they would not waste time repeating them. That is a sign of respect
for the value of other people's time.

Later, when I thanked everyone and praised how well this process (meaning the discussion on the mailing list
-- translator's note) had worked, one Linux kernel mailing list (lkml) member
said that the problem got solved not because I was a “celebrity” on that list, but because
I asked in the right way.

We hackers are, in a sense, people rich in knowledge but lacking in human warmth; I believe
he was right: if I had asked like a beggar, then no matter who I was, I would definitely have annoyed some
people or been ignored by them. He suggested that I write this down and give some guidance to the person writing this guide.

================
If You Can't Get An Answer
================

If you still cannot get an answer, please do not assume we are unable to help you. Sometimes it is simply that the people who
saw your question do not know the answer. No response does not mean you were ignored, though admittedly
the difference is hard to tell.

Generally speaking, simply reposting the question is a bad idea. That will be seen as meaningless
noise.
noise.

You can get help through other channels, which are often more suitable for the needs of beginners.

There are many online and local user groups made up of enthusiastic software fans (even if they may
never have written any software themselves). Such groups are often formed so people can help each other
and help newbies.

Besides that, you can seek help from many commercial companies, large or small (Red
Hat and LinuxCare are two of the most common examples). Do not feel frustrated that you have to pay to get help! After all, if your car engine's cylinder seal blows out -- which is entirely possible -- you still have to take it to a repair shop and pay
for the repair. Even if the software did not cost you a cent, you still cannot insist that technical support must always be free.

For mass-market software such as Linux, each developer will have at least tens of thousands of users.
It is simply impossible for one person to handle help requests from tens of thousands of users. Understand that even if you have
to pay for help, what you pay is still tiny compared with having to buy comparable software

(usually technical support for closed-source software costs much more than for open-source software,
and the content is not as rich, either).

This is about question-asking techniques for hackers. Is this a hacker forum?

Although this is about question-asking techniques for hackers, we can still learn from it! Asking questions on a DOS forum also requires some skill. Everyone hopes to see good questions rather than terrible, clueless ones. Nobody wants to answer terrible questions, and even if someone is willing to answer, they have no way to begin, because they simply have no idea what you're asking about, or they just can't imagine how you ran into this kind of problem.

Too long. The most important thing is that I can't understand it at all.