中国DOS联盟

### How To Ask Questions The Smart Way
Asking Questions Wisely (Part 1)

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's patient guidance and permission, this article was completed and published. The English version of this guide is copyrighted by Eric Steven Raymond,
and the Chinese version is copyrighted by D.H.Grand.

Table of Contents

Introduction
Before Asking Questions
How to Ask Questions
Choose the Forum Cautiously
Try to Use Mailing Lists
Use Appropriate Words, Correct Grammar, and No Spelling Errors
Send Questions in a Readable Format
Use a Descriptive and Accurate Title
Describe Precisely and Provide Abundant Information
Don't Talk Too Much
Only State Symptoms, Not Guesses
List Symptoms in Chronological Order
Don't Ask for Private Responses
Know What You Want to Ask
Don't Ask Questions That Should Be Solved by Yourself
Remove Meaningless Questions
Humility Never Does Harm and Often Helps a Lot
Add a Brief Explanation After the Problem is Solved
How to Understand Answers
RTFM and STFW: Don't Bother Me
Still Don't Understand
Facing Rudeness
Never Be Like a Loser
Think Twice Before Asking
Good Questions, Bad Questions
What to Do If You Can't Find the Answer

====
Introduction
====

In the hacker world, what kind of answer can you get when you ask a technical question? It depends on the difficulty of digging out the answer, and also on the way you ask the question. This guide is designed to help you improve your questioning skills to get the answer you most want.

First of all, you must understand that hackers only prefer difficult tasks or good questions that can stimulate their thinking. If not, why are we here? If you have a good question worth our repeated pondering, we will be very grateful to you. A good question is an inspiration, a generous gift, which can improve our understanding and usually expose problems we never realized or thought about before. For hackers, "Good question!" is a heartfelt great compliment.

Although hackers have a bad reputation for despising simple questions and being unfriendly, sometimes it may seem that we are hostile to novices and those with poor knowledge, but that's not the case.

We don't want to hide our contempt for such people - those who are unwilling to think or don't do what they should do before asking questions. Such people will only kill time - they only want to take, never give, and waste our time needlessly, while we could have spent the time on more interesting questions or more worthy people. We call such people "lusers" (due to historical reasons, we sometimes spell it as "lusers").

We also know that many people just want to use the software we write and are not interested in technical details. For most people, the computer is just a tool, a means to an end; they have more important things to do and a more important life to live. We understand this and don't expect everyone to be interested in the technical questions that drive us crazy. However, our style of answering questions is aimed at such a group of people - those who are interested and willing to actively participate in solving the problem. This will not change and should not change; if it changes, we will lose the efficiency we are proud of.

We are largely volunteers, taking time out of our busy lives to answer questions, and are often overwhelmed by questions. So we ruthlessly filter out some topics, especially those that seem like losers, in order to use time more efficiently to answer the questions of winners.

If you feel that our overly arrogant attitude makes you uncomfortable and wronged, you might as well put yourself in our shoes. We didn't ask you to submit to us - in fact, most of us like fair deals the most. As long as you make a little effort to meet the minimum requirements, we will welcome you into our culture. But it's meaningless to let us help those who are not willing to help themselves. If you can't accept this "discrimination", we suggest that you spend some money to find a commercial company to sign a technical support agreement, don't beg hackers for help.

If you decide to ask us for help, of course, you don't want to be regarded as a loser, and even less want to be a member of losers. The best way to get an effective answer immediately is to ask like a winner - smart, confident, with ideas for solving the problem, just occasionally needing a little help on a specific question.

(Welcome to put forward improvement suggestions for this guide. Any suggestions please send an email to esr@thyrsus.com, however, please note that this article is not a general guide to netiquette, and I usually refuse suggestions that are not helpful for getting useful answers in technical forums.)
(Of course, if you write in Chinese, it's better to send it to DHGrand@hotmail.com;-)

========
Before Asking Questions
========

Before asking a technical question via email, newsgroup, or chat room, check if you have done:
1. Read the manual thoroughly and try to find the answer by yourself.
2. Find the answer in the FAQ (a well-maintained FAQ can cover everything:).
3. Search on the Internet (personally recommend google~~~).
4. Ask your friends who are good at this around you.

When you ask a question, first explain what you have done before; this will help establish your image: you are not a beggar who wants to get something for nothing and is not willing to waste others' time. It's even better if you can explain what you have learned from these operations. If the questioner can learn something from the answer, we are more willing to answer his question.

Thoughtfully prepare your question. Hasty questioning can only get hasty answers or no answers at all. The more you show the efforts you have made to solve the problem before seeking help, the more substantial help you will get.

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 meaningless literal explanation, thinking "stupid question...", hoping that you will learn a lesson from the answer to the question (rather than the answer you want).

Never think you are entitled to an answer, you don't have this entitlement. After all, you haven't paid any remuneration for this service. You have to "earn" an answer by asking a meaningful, interesting, and thought-stimulating question - a question that has a potential contribution to the community's experience, rather than just passively asking for knowledge from others - to earn this answer.

On the other hand, showing that you are willing to do something in the process of finding the answer is a very good start. "Can anyone give some hints?" "What's missing in my example?" and "What should I check?" are easier to get a response than "Please post the exact process". Because you seem to have the ability and determination to complete it as long as someone points out the correct direction.

========
How to Ask Questions
========

------------
Choose the Forum Cautiously
------------

Be careful to choose the place to ask questions. If it's described as follows, you are likely to be ignored or regarded as a loser:
1. Post your question in an irrelevant forum
2. Post a very basic question in a forum discussing advanced skills; and vice versa
3. Post cross in too many different newsgroups

Hackers usually cut off questions asked in the wrong place to protect their community from being flooded with a large number of irrelevant posts. You don't want your post to be cut off like this.

In general, it's easier to get useful answers by sending the question to a carefully selected public forum than to a closed small circle. There are several reasons for this phenomenon, one of which is that there are more potential question answerers in the public forum; another reason is that there are more listeners in the public forum. Hackers are more willing to let as many people as possible - rather than a limited one or two - benefit from the answer.

----------------
Try to Use Mailing Lists
----------------

If a project has its own development mailing list, send the question to this mailing list instead of a certain developer, even if you know very well who can answer your question best. Carefully check the project documentation and project homepage to find the email list address of this project. The reasons for doing this are fourfold:
1. Any good question worth asking a certain developer is worth asking the entire development community. Conversely, if you think this question is not worth mentioning in the mailing list, there is no reason to harass any developer with it.
2. Asking questions in the mailing list can share the workload of developers. A certain developer (especially when he is the project leader) may be too busy to answer your question.
3. Most mailing lists have historical archives and can be retrieved in search engines. People can find your question and answer from them without asking again and again in the list.
4. If a certain question is often asked, developers can improve the documentation or software accordingly to reduce users' confusion. But if the question is always asked privately, no one will have an overall grasp of it.

If you can't find the email list address of the project and can only see the maintainer of the project, then write to the maintainer. In this case, don't think that the mailing list doesn't exist. Write in your letter that you have tried your best to find it and still can't find the mailing list. Also indicate that you don't mind transferring this message to others. (Most people think that private letters should be private, even if there is nothing to keep secret. Allowing your message to be forwarded to others gives the recipient a choice in handling your email.)

----------------------------
Use Appropriate Words, Correct Grammar, and No Spelling Errors
----------------------------

We have found from experience that careless writers are usually also sloppy thinkers (I bet). It's not worth answering the questions of careless people, and we would rather spend time elsewhere.

Therefore, it's very important to clearly and fully express your question. If you find it troublesome to do so, we will be lazy to pay attention to you. Pay attention to refining your words. You don't have to use rigid and formal language - in fact, the values of hacker culture are informal. Use slang and humorous language accurately, but don't misuse them; you must show that you are thinking and paying attention.

Correct spelling, punctuation, and capitalization are important. Don't confuse "its" and "it''s" or "loose" and "lose". Don't use all uppercase forms, which is regarded as rude shouting (all lowercase is not much better either, because it will make reading difficult. Alan Cox can use all lowercase, but you can't).

More generally, if your question is written like a semi-literate, you are very likely to be ignored. If it's written like a pj enthusiast or a script kiddie (someone who only uses ready-made tools to make trouble), it's definitely asking for trouble, and you can be sure that you will get nothing but ruthless resistance (or, the best result is to get a lot of sarcastic "help").

If you are asking questions in a forum in a non-native language, you can make some small mistakes in spelling and grammar - but never be sloppy in thinking (yes, we can distinguish the two). In addition, unless you are exactly sure what language your answerer will use, please use English. Hurried hackers usually simply skip questions they can't understand, and English is the working language on the Internet. Using English can reduce the risk that your question is discarded without being read.

------------------
Send Questions in a Readable Format
------------------

If you make your question difficult to read and understand artificially, it will be easier to be ignored. Therefore, you should:
1. Use plain text email and don't use HTML (it's not difficult to turn off HTML).
2. Usually, you can attach MIME attachments, but there must be real content (such as attached source files or patches), not just the file template generated by your email client (such as a copy of your email).
3. Don't put all the questions in one long paragraph that keeps wrapping lines. (This will make it difficult for the person replying to answer part of the questions. Even if all questions can be answered, I would rather have them one by one in an orderly manner:). It's very possible that the recipient can only read the letter on a text display with a width of 80 characters, so set the line wrapping mode accordingly within 80 characters.
4. Don't send in MIME Quoted-Printable encoding in an English forum; this encoding format is very necessary for languages that cannot be expressed in ASCII code, but many email agents don't support it. At this time, full of "=20" symbols split the text, which is not only ugly but also distracting.
5. Never expect hackers to be willing to read files in closed proprietary formats, such as Microsoft Word format. Most hackers' reaction to this is like you piling up hot pig manure on the doorstep steps (meaning no one will step into your door - translator's note).
6. If you send an email through a computer installed with Windows, turn off Microsoft's stupid "smart quotes" function. This can save you from having garbage characters in your email.

----------------------------
Use a Descriptive and Accurate Title
----------------------------

In the mailing list or newsgroup, the subject title within about 50 words is the golden opportunity to catch the attention of senior experts. Don't waste this opportunity with wordy "Help me" (let alone the annoying words like "Help!!!"). Don't try to move us with the degree of your pain, and don't use spaces instead of the description of the question, even if it's extremely short.

Stupid question:
Help! My laptop can't display normally!

Smart question:
Mouse cursor distorted under XFree86 4.1, display chip of Fooware MV1005.

If you raise a question in the reply, remember to modify the content title to indicate that there is a question in it. A question that looks like "Re: Test" or "Re: New bug" is difficult to attract enough attention. In addition, quote and cut the previous content to leave clues for new readers.

------------------
Describe Precisely and Provide Abundant Information
------------------

1. Describe the symptoms carefully and clearly.
2. Provide the environment where the problem occurs (machine configuration, operating system, application program and anything else).
3. Explain how you studied and understood this problem before asking the question.
4. Explain what steps you took to solve it before asking the question.
5. List the recent hardware and software changes that may have an impact.

Try to imagine how a hacker would ask you back and pre-answer him when asking the question.

Simon Tatham has written an excellent short article titled "How to Report Bugs Effectively". It's highly recommended that you also read it.

--------
Don't Talk Too Much
--------

You need to provide precise and effective information. This doesn't mean that you simply dump tons of error codes or data completely into your question. If you have a huge and complex test condition, try to cut it as small as possible.

There are at least three uses of doing this. First, it shows that you have made efforts to simplify the problem, which can increase your chance of getting an answer; second, simplifying the problem increases your chance of getting a useful answer; third, in the process of refining your bug report, maybe you can find the problem or make a correction by yourself.

------------------
Only State Symptoms, Not Guesses
------------------

It's not helpful to tell hackers how you think the problem is caused. (If your inference is so effective, why do you need to ask others for help?) Therefore, make sure you tell them the symptoms of the problem exactly, without adding your own understanding and inference. Let hackers diagnose it.

Stupid question:
I keep encountering SIG11 errors in kernel compilation. I suspect that a flying wire is connected to the trace on the mainboard. What's the best way to check this situation?

Smart question:
I have a self-made K6/233 system, the mainboard is FIC-PA2007 (VIA Apollo VP2 chipset), 256MB Corsair PC133 SDRAM. I keep getting SIG11 errors in kernel compilation. This situation occurs frequently after 20 minutes of booting, and never occurs within the first 20 minutes after booting. Restarting doesn't help, but shutting down for a night and then it can work for 20 minutes again. All memories have been replaced, but it's of no effect. The typical compilation record of the relevant part is as follows...

------------------
List Symptoms in Chronological Order
------------------

The most helpful clue for finding the problem is often a series of operations before the problem occurs. Therefore, your description should include the operation steps and the computer's reaction until the problem occurs. In the case of command line operations, saving an operation record (for example, using a script tool) and citing about 20 relevant commands will be very helpful.

If the crashing program has a diagnostic option (for example, use -v to switch to detailed mode), try to carefully consider choosing the option to add useful debugging information in the operation record.

If your description is long (more than four paragraphs), it will be helpful to briefly describe the problem at the beginning and then elaborate in chronological order. Then hackers know what to look for in your description.

--------------
Don't Ask for Private Responses
--------------

Hackers think that the process of solving the problem should be open and transparent. As long as any more insightful person notices that the answer is imperfect or incorrect, this initial answer can and should be corrected. At the same time, the answerer is rewarded as he is noticed and accepted by everyone through his ability and knowledge.

If you ask for a private answer from the other party, this not only disrupts the entire process but also the reward system. Don't mention this requirement. It's the right of the answerer to choose whether to answer privately - if he chooses to do so, it's usually because he thinks the answer is too obvious or has a bad public impact and others won't be interested.

There is only a limited exception: if you expect to receive a large number of similar responses, you can say: "Send the answer to me, and I will summarize it." Rescuing the mailing list or newsgroup from a large number of repeated posts is very gentlemanly - but please remember to fulfill your promise about summarizing.

### How To Ask Questions The Smart Way
### Asking Questions Wisely (Part 2)

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's patient guidance and consent, this article was completed and published. The English version of this guide is copyrighted by Eric Steven Raymond, and the Chinese version is copyrighted by D.H.Grand.

--------------
Understand What You're Asking
--------------

Wandering questions are like endless time black holes. The people who can give you useful answers are also the busiest ones (they're busy because they have to do most of the work themselves). Such people don't like endless time black holes, so you could say they don't like wandering questions.

If you clearly state what you need the responder to do (provide advice, send a code snippet, review your patch, or something else), you're most likely to get a useful answer. This sets an upper limit on time and energy, making it easier for the responder to focus on helping you, which works well.

To understand the world experts live in, imagine professional skills as abundant resources and response time as scarce resources. The less time it takes to solve your problem, the more likely you are to get an answer from a busy expert.

Therefore, optimizing the structure of your question to minimize the time experts need to solve it is very helpful - this is usually different from simplifying the problem. So, asking "I want to better understand X, can you give some hints?" is usually better than asking "Can you explain X to me?". If your code isn't working, it's wiser to ask what's wrong with it than to ask someone to fix it for you.

------------------------
Don't Ask Questions That Should Be Solved by Yourself
------------------------

Hackers are always good at distinguishing which questions should be solved by yourself; because most of us have solved such problems ourselves. Similarly, these problems need to be solved by you, and you'll learn something from it. You can ask for hints, but don't ask for a complete solution.

----------------
Remove Meaningless Questions
----------------

Don't end your question with meaningless words, such as "Can anyone help me?" or "Is there an answer?". First: if your description of the problem isn't very appropriate, asking like this is even more redundant. Second: because asking like this is redundant, hackers will be annoyed by you - and usually respond with a logically correct answer to show their disdain, such as "Yes, someone can help you" or "No, there's no answer".

----------------------------
Humor Is Never Harmful and Often Helps a Lot
----------------------------

Be polite, use "please" and "thank you in advance". Let everyone know that you are grateful for their time and voluntary help.

Tell the truth, although this isn't as important as (and can't replace) grammatical, clear and accurate descriptions, avoiding private formats, etc.; hackers generally prefer straightforward and technically sharp bug reports rather than polite nonsense (if this confuses you, remember that the standard we use to measure the value of a problem is: how much we can learn from it).

However, if you have many unsolved problems, politeness will increase your chance of getting useful answers.

(We have noticed that since this guide was published, the only serious defect feedback received from senior hackers is about the pre-thank you. Some hackers feel that the implication of "thank you in advance" is that you won't thank anyone later. Our suggestion is: thank everyone.)

------------------------
After the Problem Is Solved, Add a Brief Explanation
------------------------

After the problem is solved, send an explanation to all those who helped you, let them know how the problem was solved, and thank them again. If the problem has attracted widespread attention in a newsgroup or mailing list, you should post a supplementary explanation there.

The supplementary explanation doesn't need to be long or in-depth; a simple sentence like "Hello, it turned out to be a network cable problem! Thank you everyone - Bill" is better than saying nothing. In fact, unless the conclusion is really technically sophisticated, a short and cute summary is better than a long academic paper. Explain how the problem was solved, but there's no need to repeat the process of solving the problem.

In addition to showing politeness and providing feedback, this supplement helps others search for the complete solution that helped you in the mailing list/newsgroup/forum, which may also be useful to them.

Finally (at least?), this supplement helps all those who provided help get a sense of satisfaction. If you aren't an expert or hacker yourself, just believe us, this feeling is very important to the mentors or experts you ask for help from. An unsolved problem will make people discouraged; hackers are eager to see the problem solved. Good deeds are rewarded, satisfy their desire, and you'll benefit the next time you post a new question.

============
How to Understand the Answer
============

--------------------
RTFM and STFW: Don't Bother Me
--------------------

There's an old and sacred tradition: if you receive a reply of "RTFM (Read The f**king Manual)", the responder thinks you should read the damn manual. Of course, basically he's right, you should read it.

RTFM has a young relative. If the answer is "STFW (Search The f**king Web)", the responder thinks you should search the damn web. Basically, he's also right, just go find it.

Usually, the person who replies with one of these two sentences will give you a manual containing the content you need or a website, and they were reading it when they typed these words. These replies mean that the responder thinks (1). The information you need is very easy to obtain; (2). You'll learn more by searching for this information yourself than being fed it.

Don't be upset about this; according to hacker standards, he didn't ignore your request and has shown a certain degree of concern for you. You should be grateful for his grandmotherly kindness.

----------
Still Don't Understand
----------

If you don't understand the answer very well, don't immediately ask the other party to explain. Do what you did when you tried to solve the problem yourself before (use the manual, FAQ, network, experts around you), to understand it. If you really need the other party to explain, remember to show that you've learned something.

For example, if I reply to you: "It seems that zEntry is blocked; you should clear it first.", then:

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

The smart way to ask is like this: "Oh~~~ I read the help but only the -z and -p parameters mentioned zEntry and neither explained it clearly: <Do you mean one of these two? Or did I miss something?>"

--------
Facing Rudeness
--------

Many of the rudeness in the hacker circle isn't intentionally offensive. More appropriately, this is the product of straightforward and no-nonsense communication, which stems from people's nature of focusing on problem-solving - more than being confused but still feeling warm and affectionate.

If you feel treated rudely, keep calm. If someone is really rude, usually there will be elders in the list/newsgroup/forum to talk to him. If not, and you lose your temper, it's very likely that the other party's words and deeds are within the norms of the hacker community, and you're considered at fault. This will be unfavorable for you to get information or help.

On the other hand, you may occasionally have rude words and attitudes for no reason. The other side of the above phenomenon is that people allow to severely criticize real offenders and analyze their improper words and deeds with sharp words. If you really decide to do this, weigh yourself carefully and carefully. There's a thin line between reasonable rudeness and starting a meaningless argument, and there are many hackers who rashly cross it; if you're a novice or outsider, the chance of not making this mistake is very slim. If you want to get information instead of making trouble, don't risk replying, it's better to take your hand off the keyboard.

(Some people claim that most hackers have mild symptoms of autism or social disorder syndrome, and indeed lack part of the brain structure that helps "ordinary people" with social behavior. This may or may not be true. If you aren't a hacker yourself, then, imagining us as people with brain defects will help you face our weirdness. Just speak up, we don't care; we're happy to live our own way and are always quite skeptical about medical concepts.)

In the next section, we'll talk about another topic; the "rudeness" you may encounter when you make a mistake.

================
Never Be a Loser
================

It's very possible that you'll receive a lot of public attacks in the hacker community forum - in various ways mentioned in this article or similar methods, and there may be all kinds of side remarks to tell you how annoying you are.

If the nightmare comes true, the worst thing you can do is to complain about it, complain about being personally attacked, ask the other party to apologize, scream, hold your breath, threaten to sue the other party, report to his boss, not lift the toilet seat, and so on. However, you should do this:

Let it go, it's not a big deal. Actually, doing this is appropriate and beneficial (mainly for physical and mental health:).

The norms of the community are maintained not by the community, but by the people who actively promote them, and this maintenance is public and obvious. Don't complain that all criticism should be sent through private messages, it shouldn't be like that. When someone points out that your words are wrong or he has a different view, it's useless to insist that he is humiliating you. These are the attitudes of losers.

There are some hacker forums that, out of misunderstanding of high humility, prohibit participants from posting posts specifically for picking on people, and are told "If you don't want to help users, then shut up." They think that diverting participants' topics will only make them indulge in meaningless chatter, thus losing the meaning of the technical forum.

Exaggerated "friendliness" (in that way) is still useful help: it's up to you to choose.

Remember: when a hacker says you're annoying, (no matter how rude the language is) warning you not to do that again, his intention isn't aimed at (1) you, and (2) his community. He could have easily ignored you and wiped you out of his sight. If you can't accept showing your gratitude to him, at least show your magnanimity, don't complain, don't expect to be treated like a fragile doll just because you're a newcomer, you have dramatic sensitive and fragile nerves and self-proclaimed rights.

==========
Think Twice Before Asking
==========

The following are some classic stupid questions and what hackers think when refusing to answer:

Question: Where can I find the X program?
Question: My program/configuration/SQL statement isn't working
Question: I have a problem with Windows, can you help me?
Question: I have a problem with installing Linux (or X), can you help me?
Question: How can I crack the root account/steal OP privileges/read others' emails?

Question: Where can I find the X program?
Answer: Right where I found it, you fool - the other end of the search engine. Oh my god! Is there anyone who doesn't know how to use Google?

Question: My program (configuration, SQL statement) isn't working
Answer: This isn't a problem, I'm not interested in finding out your real problem - if I have to ask you twenty questions to find it out - I have more interesting things to do. When seeing this kind of question, my reaction is usually one of the following three:
1. Do you have anything else to add?
2. That's too bad, hope you can get it sorted out.
3. What the hell does this have to do with me?

Question: I have a problem with Windows, can you help me?
Answer: Yes, throw away the rotten Windows garbage and switch to Linux.

Question: I have a problem with installing Linux (or X), can you help me?
Answer: No, I can only find out the problem by working on your computer in person. Still, go to your local Linux user group to seek hands-on guidance (you can find the list of user groups here).

Question: How can I crack the root account/steal OP privileges/read others' emails?
Answer: Wanting to do this means you're a scoundrel; wanting to find a hacker to help you means you're an idiot!

==============
Good Questions, Bad Questions
==============

Finally, I'll give some examples to illustrate how to ask questions smartly; two ways of asking the same question are placed together, one is stupid, and the other is wise.

Stupid question: Where can I find information about Foonly Flurbamatic?
This way of asking is nothing but to get an answer like "STFW".

Smart question: I searched Google for "Foonly Flurbamatic 2600" but didn't find useful results. Who knows where to find information about programming this device?
This question has already STFWed, and it seems he really has a problem.

Stupid question: The source code I got from the FOO project can't be compiled. Why is it so bad?
He thinks it's everyone else's fault, this arrogant guy

Smart question: The code of the FOO project can't be compiled under Nulix 6.2. I read the FAQ, but it doesn't mention problems related to Nulix. Here's the record of my compilation process, is there anything I did wrong?
He explained the environment, read the FAQ, pointed out the error, and he didn't shift the responsibility of the problem to others, this guy is worth paying attention to.

Stupid question: There's a problem with my motherboard, who will help me?
The usual answer of ordinary hackers to this kind of question is: "Okay, do you also want me to pat your back and change your diaper?" and then press the delete key.

Smart question: I tried X, Y, and Z on the S2464 motherboard, but nothing worked, and then I tried A, B, and C. Please note the strange phenomenon when I tried C. Obviously, there's a contraction in the sideband transmission, but the result is unexpected. What are the usual causes of sideband leakage on multi-processor motherboards? Who has a good idea what tests I should do next to find out the problem?
This guy, from another perspective, is worth answering. He shows the ability to solve problems instead of waiting for the answer to fall from the sky.

In the last question, pay attention to the subtle but important difference between "tell me the answer" and "give me hints and point out what diagnostic work I should do next".

In fact, the latter question originated from a real question on the Linux kernel mailing list in August 2001. I (Eric) was the one who asked the question. I observed this inexplicable lock-up phenomenon on the Tyan S2464 motherboard, and the list members provided important information to solve that problem.

Through my question method, I gave everyone something worth pondering; I made it easy for people to participate and be attracted. I showed that I have the same ability as them and invited them to discuss with me. I told them the detours I took to avoid them wasting time again, which is a respect for the value of others' time.

Later, when I thanked everyone and appreciated that the program (referring to the discussion in the mailing list - translator's note) worked very well, a member of the Linux kernel mailing list (lkml) said that the problem was solved not because I was a "celebrity" in this list, but because I asked the question in the correct way.

We hackers are a bit knowledge-rich but lack human touch from a certain perspective; I believe he's right. If I asked the question like a beggar, no matter who I am, I would definitely annoy some people or be ignored by them. He suggested that I write down this matter and give some guidance to the person who wrote this guide.

================
What If You Can't Find the Answer
================

If you still don't get an answer, don't think that we think we can't help you. Sometimes it's just that the person who sees your question doesn't know the answer. No response doesn't mean you're ignored, although it's undeniable that this difference is hard to distinguish.

In general, simply reposting the question is a very bad idea. This will be regarded as meaningless noise.
Noise.

You can get help through other channels, which are usually more suitable for beginners' needs.

There are many online and local user groups composed of enthusiastic software enthusiasts (even if they may never have written any software themselves). Usually, people form such groups to help each other and help novices.

In addition, you can seek help from many commercial companies, whether they are large or small (Red Hat and LinuxCare are two of the most common examples). Don't be depressed because you have to pay to get help! After all, if the cylinder seal of your car engine bursts - it's completely possible - you still have to send it to the repair shop and pay for the repair. Even if the software didn't cost you a cent, you can't demand that technical support is always free.

For popular software, like Linux, each developer has at least tens of thousands of users. It's completely impossible for one person to handle the help calls from tens of thousands of users. You should know that even if you have to pay for help, it's negligible compared to the fact that you have to buy the same software (usually the technical support cost of closed-source software is much higher than that of open-source software and the content is not so rich).

Raise your hand if you have the patience to finish reading this post!

Oh!
It seems that ko20010214 should learn how to post properly by himself, so that others can have the patience to read it!

If you don't have the patience to read... then don't bother.
This is still in Chinese. If it were in English, probably even less patience, right?
If you don't have the patience, how can you read those software instructions? Especially the instructions for English software??
I also hate those who directly ask about how to use software without reading those software instructions,
including those mentioned above who don't know how to ask questions and don't learn how to ask questions,
so I post this "The Wisdom of Asking Questions" here...
Everyone can read it or not. It won't do you any harm to read it. At least after learning it, when you ask questions later, others are more willing to answer you.

Before asking questions:

1. If you are a newbie, please read "The Wisdom of Asking Questions" and the forum frequently asked questions (we haven't sorted out the forum frequently asked questions for the time being)
2. Use the Google (http://www.google.com/) engine to find answers
3. Carefully select the relevant topic forums
4. Use a title that is meaningful and accurately describes the content
　　But recently, there are many such posts as the following: (If in the Kanxue forum, such posts will be directly deleted!)
（1）、。
（2）、Help me.
（3）、Save me!
（4）、Novice asks for advice!
（5）、
（6）、Expert, help me!
（7）、Moderator, come in!

Because the topic is too simple and cannot reflect the content of the post, so generally no one is willing to click into such posts to reply (everyone is busy, and will only view posts that are interested according to the topic), so you won't get everyone's help.
I see such topic posts, even if I know the answer, I generally don't want to reply.

5. Don't ask for private replies
6. After the problem is solved, add a brief explanation
7. Email posting to distribute your materials or works is not welcome
8. You can delete and modify the post content by yourself when there is no reply (forum management operations).
9. Please do not post off-topic topics! Such as various group announcements, birthday wishes, chatting, etc.
10. "Regarding the problem of what experts and what putting on airs" please go to the following website to see what others say: http://www.chat001.com/forum/crackforum/253995.html

11. Go find a few DOS introductory books to read first!
12. Look at the forum frequently asked questions before asking questions;
13. Ask the forum for help only after you have tried your best and can't solve it!

We welcome such posts:

When you encounter a problem and it is difficult to solve, write down the detailed situation you encountered, and we all answer together.
When you have a small achievement and have a deep feeling about your result, write down your mood, and we all share the happiness together
When you discover or learn to use a new DOS software, please write down your experience and insights, and publish the software download address, and we all make progress together
When you have become an expert, looking back on the rookie era, the ups and downs, please write it down to inspire the morale of the rookies who can't spread their wings yet.
The good posts will also be included in the highlights.

We do not welcome such posts:

Immediately asking how to use **software?** Where can the software be found (unless you have looked for it and haven't found it)? Such people are lazy and only enjoy the fruits of others.
Immediately asking how to steal passwords, how to steal QQ, how to use Trojan. Such people have bad character, and to put it seriously, they are depraved.
Immediately using abusive language against others, abuse is strictly prohibited here!! Attacks on each other are strictly prohibited!!
The fate of such posts will be - deleted.

Here is a reading reflection on "The Wisdom of Asking Questions" (it can be said to be a critique of "The Wisdom of Asking Questions", heh heh...).

If you are interested, you can take a look:

Nonsense All the Way - Reading Reflection on "The Wisdom of Asking Questions"
http://tongtian.net/cgi-bin/topic.cgi?forum=10&topic=1214&show=25

The views in this post are worth thinking about,
And some of the views in the subsequent replies are also worth us thinking about...

It is suggested to put that review here for everyone to see.

Since a link was provided, there's no need to re-post it here.

Completely agree, really classic. Learned some things again! Every time I come here and get something is my greatest joy! Thanks to ko20010214 and Wengier, sincerely grateful!

It's really a good article!

Good article
Read all~~
Copy it and look at it later~

It is helpful to me, I have many thoughts after reading it, thank you!

It's really a good article!

This needs to be learned. Some habits are often made mistakes.