This page has been robot translated, sorry for typos if any. Original content here.

How to ask questions?


There are translations of this document into Chinese , Czech , Danish , Estonian , French , German , Hebrew , Hungarian , Italian , Japanese , Polish , Russian , Spanish , Swedish and Turkish . If you want to copy, support the mirror, translate or quote this document, please read my copying rules .


On the sites of many projects, sections on how to turn for help provide links to this document. This is good, it is intended for this, but if you are a web-master who is going to add such a link on the page of your project, please indicate next to the link in a prominent place that we are not a support service for your project!

We have learned through bitter experience that, in the absence of such a warning, idiots will constantly torment us, believing that the publication of this document obliges us to solve all technical problems in the world.

If you read this document because you need help, and in the end it seems to you that you can get it directly from the authors, then you are one of these same idiots. Do not ask questions to us . We will simply ignore them. Our goal is to show you how to get help from those who are familiar with the software or hardware with which you work, but in 99% of cases, these are not we who are knowledgeable. If you don’t know for sure that one of the authors is an expert in what you are dealing with, leave us alone, and this will make everyone feel better.


In the world of hackers , the style of answers that you get to the technical questions asked depends on the method of asking questions no less than on their complexity. This guide will teach you how to ask questions so that you are more likely to get a satisfactory answer.

Now that open source software has become widespread, you can often get answers from other, more experienced, users, not hackers. It's good; users are usually a little more tolerant of the mistakes that newbies often make. But, if you turn to experienced users as hackers, in accordance with the recommendations presented here, then this will be the most effective way to get useful answers from them.

First of all, you need to understand that hackers really like complex problems and good questions that can stir up the brain, questions about these problems. If we didn’t like it, we would not be hackers. If you ask us an interesting question that requires lengthy reflection, we will be grateful for it; good questions are an incentive and a gift. Good questions help to better understand the subject and often reveal problems that were not previously noticed or that were not thought of. From the mouth of the hacker: "Good question!" - This is a big and sincere compliment.

Despite this, it is believed that hackers relate to simple issues rather hostile or arrogant. Sometimes it seems that we are rude enough to beginners and ignore them. But actually it is not.

We, no doubt, are hostile towards people who are supposedly unwilling to think or learn before asking questions. Such people kill time - they take without giving anything in return, they take away time that we could devote to another question, more interesting, and to another person more worthy of an answer. We call such people "losers" (for historical reasons, this word is sometimes written as "lusers" - loser users).

We understand that many people just want to use the software we create, and are not going to study the technical details at all. For most, a computer is just a tool, a means to an end; they have more interesting activities and other problems in life. We recognize this and do not expect everyone to be interested in the technical nuances that are so attractive to us. Nevertheless, our style of answering questions is suitable for people who are really interested in this and who want to be active participants in the problem-solving process. This will not change. Yes and should not change; otherwise, we cannot effectively do what we are best at.

We (mostly) are volunteers. We devote time to our difficult life to answer questions, and at times we cannot cope with a flurry of questions. Therefore, we have to ruthlessly "filter the market." In particular, to throw away the questions of potential losers in order to spend the time allotted for answers more efficiently, devoting it to the winners.

If this position seems funny, arrogant or arrogant to you, you are mistaken. We do not ask you to pray for us - in fact, most of us would like to communicate with you on an equal footing and accept you in our culture if you make the effort necessary for this. But for us it is simply inefficient to try to help people who do not want to help themselves. Being rude is fine, but pretending to be an idiot is not.

So, although it is not at all necessary to be technically competent in order to be worthy of our attention, it is necessary to demonstrate the qualities that enable us to become competent - attentiveness, thoughtfulness, observation, a desire to actively participate in developing a solution. If you can’t put up with this kind of discrimination, it makes sense to pay someone for commercial support, rather than ask hackers to help you personally for free.

If you decide to contact us for help, do not become a loser. And don't act like a loser. The best way to get a quick and sensitive answer is to ask how a person is smart, confident and knowledgeable, who just needed help in solving one specific problem.

(Additions to this guide are welcome. Suggestions can be sent to . Please note, however, that this document was not created as a general guide to network etiquette , and I usually ignore suggestions not directly related to receiving useful answers in the technical forum .)

Before asking ...

Before asking a technical question by e-mail or in a discussion group, chat or forum, do the following:

  1. Try to find the answer using a search on the Web.
  2. Try to find the answer in the manual.
  3. Try to find the answer in the list of frequently asked questions (FAQ).
  4. Try to find the answer through tests or experiments.
  5. Ask an experienced friend.
  6. If you are a programmer, try to find the answer by analyzing the source code.

When asking a question, indicate from the very beginning that you have already done all this; this will help to understand that you are not some idler, squandering someone else’s time. Better yet, show what you learned from your searches. We like to respond to people who have demonstrated their ability to perceive answers.

Use tricks such as searching on Google for the text of the error message you receive (also look for discussion groups - Google groups, not just Web pages). This can lead either directly to the documentation on how to fix this error, or to a discussion on the mailing list where you can find the answer. Even if there is no answer, the phrase: “I searched on Google for the following query, but did not find anything useful” is useful when contacting for help by e-mail or in a discussion group.

Prepare a question. Think it over. You will receive superficial answers to superficial questions, or you won’t get any answers at all. The more you do to show your thoughts and efforts to solve a problem before asking for help, the more likely you are to get this help.

Do not ask the wrong questions. If the question is based on erroneous assumptions, any hacker (in the original - J. Random Hacker, approx. Translator ) will most likely give a useless, literal answer, thinking at the same time “Silly question ...”, and hoping that getting one about what you asked, instead of what you really need, will teach you something.

Do not think that you should be answered. Nobody owes you anything; you, in the end, did not pay for these services. You will get the answer if you deserve it by asking a significant, interesting and thought-provoking question - a question that implicitly gives the community a new experience, and not just passively requires others to share knowledge.

On the other hand, it’s nice to immediately make it clear that you can and want to help in the decision-making process. To questions like "Can someone tell me?", "What is not taken into account in my example?" and "Is there a site worth looking at on this topic?" a response is more likely to be received than a requirement to send an exact sequence of actions to solve a problem, since you have clearly shown that you will solve the problem yourself if someone points you in the right direction.

When you ask ...

Choose the right forum

Think carefully about where to ask the question. You are most likely to be ignored or dismissed as a failure if you:

  • send a question to a forum that is not relevant on the topic (off topic)
  • send the most basic question to a forum where complex technical issues are discussed, or vice versa
  • send the question at the same time (cross-post) to many different discussion groups
  • send a private message by e-mail to a stranger who is not personally responsible for solving your problems

Hackers ignore questions directed to the wrong address so as not to download their communication channels with irrelevant information. Do not fall into this category of questions.

Therefore, you must first find the appropriate forum. The Google search engine and other Web search tools will help you with this again. Use them to find the project page that is most closely related to the equipment or software that you are having difficulty with. Usually this page will contain links to a list of frequently asked questions (FAQ, Frequently Asked Questions), mailing lists of the project and their archives. It is there that you need to ask for help if your own efforts (including reading these, discovered by you FAQ) were unsuccessful. The project page may also describe the error reporting procedure or provide a link to it. In this case, use the recommended procedure.

Sending a message to a person or to a forum with which you are not familiar is at least a risky enterprise. For example, do not think that the author of an informative web page wants to become your free consultant. Do not make optimistic assumptions that your question will be welcome - if you are not sure, send it to another address or refuse to send it at all.

When choosing a Web forum, discussion group, or mailing list, do not make decisions solely on the basis of name; Read the list of frequently asked questions (FAQ) or the rules to make sure that the question is relevant. Read the messages for a while before sending questions to feel how and what is being done here. In fact, before submitting a question, it’s worth it to search for the keywords related to your problem in the archives of a discussion group or mailing list. As a result, you can find the answer, and if not, such a search will help to better formulate the question.

Do not use all available help channels at the same time. It is like screaming and outraging people. Address them alternately.

Identify the topic correctly! One classic mistake is to ask a question about the Unix or Windows programming interface in a forum about a language, library, or tool that runs on both platforms. If you do not understand why this is a gross mistake, it is better not to ask questions at all until you understand.

In general, the probability of getting answers to questions in a correctly selected public forum is higher than in a private one. There are several reasons for this. One of them is the number of potential responders. Another is the size of the audience that finds out the answer; hackers with great pleasure answer questions that may interest many than questions that are useful only to a few.

It is clear that experienced hackers and creators of popular programs already receive a lot more irrelevant issues than they would like. By increasing this flow, in some cases you can become the last straw - occasionally, participants in popular projects stop supporting them because they no longer endure the problems that accompany it in the form of a stream of useless e-mail messages to their personal addresses.

Web and IRC forums for beginners often provide an answer as quickly as possible.

Your local user group or your Linux distribution may support a Web forum or IRC channel designed to help beginners. (In non-English speaking countries, beginner forums are still most likely organized as mailing lists.) These are good places to ask questions first, especially if you are suspected of having a relatively simple or typical problem. The publicly advertised IRC channel is an explicit invitation to ask questions, and often the ability to receive real-time responses.

In fact, if the program with which you are having problems is taken from the distribution kit (which is typical for today), it might be better to first ask the corresponding distribution kit in the forum / mailing list before contacting the program’s forum / mailing list. Hackers working on a project can simply answer: "Use our assembly."

Before asking a question in any Web forum, check to see if it has a search feature. And if there is one, look a couple of times for keywords to discuss a problem like yours; this can help. If before that you did a general search on the Web (what you had to do), search the forum anyway; Your search engine may not have indexed this forum for a long time.

There is an interesting tendency to carry out user support for projects through a Web forum or IRC channel, leaving email for communication between developers. Therefore, if you need help with a project, first contact these sources of information.

As a second step, use the project mailing lists

If the project has a mailing list for developers, send questions to this mailing list, and not to individual developers, even if you are sure that you know exactly who can best answer your question. Find the project mailing list address in the documentation or on the project website, and send a question to this address. There are several good reasons to do just that:

  • Any question that is good enough to be addressed by a single developer will be valuable to the whole group. On the contrary, if it seems that the question is too primitive for the mailing list, this is not a reason to fool the heads of individual developers.
  • If the question is asked on the mailing list, the load is distributed among all developers. A particular developer (especially if he is a project manager) may be too busy to answer your questions.
  • Most mailing lists are archived, and archives are indexed by search engines. Someone will be able to find your question and answers online, and will not ask it again on the mailing list.
  • If specific questions are asked frequently, developers can use this information to improve documentation or the software product itself so that they become more understandable. But if these questions are asked personally, no one has a big picture - what is most often asked.

If the project has separate mailing lists or Web forums for "users" and for "developers" (or "hackers"), and you do not parse (hacking) the code, ask a question in the list / forum for "users". Do not count on a warm welcome on the developer mailing list, where your question is likely to be classified as "noise" that interferes with the exchange of information on the development progress.

However, if you are confident in the non-triviality of your question and have not received an answer in the mailing list / forum for "users" within a few days, contact the developers. It makes sense before that to follow the corresponding mailing list or forum for several days to study its traditions (in fact, it makes sense to do this before contacting any private or semi-closed mailing list).

If you cannot find the address of the project mailing list, but the address of the person managing the project is known, send your question to the moderator. But in this case, do not think that there is no mailing list. In your message, indicate that you tried, but could not find the appropriate mailing list. Mention also that it is not against sending your message to other recipients. (Many people think that personal correspondence should remain personal, even if there is nothing secret in it. By allowing you to forward your message, you give people the choice.)

Set meaningful, specific message topics

When sending a message to a mailing list or discussion group, the message subject is a great opportunity to attract the attention of qualified experts with a string of up to 50 characters. Do not waste them on babble like "Help me please" (not to mention the topics "PLEASE HELP ME !!!!"; messages with such topics are thrown reflexively). Do not try to impress us with the depth of your suffering; better use the space provided for a brief description of the problem.

A good agreement on the design of message topics used by many technical support services is to use the object-reject template. The “object” part defines what exactly the problem is, and the “deviation” part describes the deviation from the expected behavior.


HELP! The video card on my laptop is not working properly!


Wrong mouse cursor shape in XFree86 4.1, video on the Fooware MV1005 chipset

Even better:

XFree86 4.1 mouse cursor on the Fooware MV1005 chipset - irregular shape

The process of writing a topic using the "object-deviation" template will help to more thoroughly understand the problem. What exactly is not working correctly? Is there only a mouse cursor or other graphics too? Is the problem only in XFree86? Only in version 4.1? Does this problem only occur on video cards with the Fooware chipset? Only in the model MV1005? A hacker, having received a message with a similar topic, can, in general terms, understand what exactly you were having a problem with and what kind of problem it is.

In general, imagine that you are viewing a list of questions in an archive that contains only subject lines. Make sure that the subject line reflects the essence of the question well enough and the next reviewer looking for an answer to a similar question could find a discussion leading to the answer, rather than sending the question again.

If you ask a question in response, do not forget to change the subject line so that it is clear on it - the question is asked. A topic line of the form "Re: test" or "Re: new bug" will not attract enough attention. In addition, keep citing previous posts to a minimum sufficient for new users to understand what was being discussed.

Do not just send a response to the message on the mailing list if you intend to discuss a new topic (start a thread of discussion). This will narrow the circle of responders. Some mail readers, such as mutt , allow the user to sort messages by topic, and then hide messages by topic, folding the thread of discussion. Those who use this opportunity will never see your message.

Changing the topic is not enough. Mutt, and possibly other email readers, take into account not only the subject line, but also other information in the message headers when linking them to a discussion thread. Create a brand new message.

In Web forums, discussion rules are slightly different, as posts are usually more closely related to specific discussion threads and often invisible outside of those threads. Changing the topic when asking a question in response is not significant (not all forums even allow you to indicate topics in the answers, and if you can ask them, almost no one reads them). But, asking a counter-question in response in itself is a dubious practice, since this question will be seen only by those who follow the corresponding thread of discussion. Therefore, if you are not sure that you want to appeal specifically to those who participate in the discussion of the topic, start a new topic.

Simplify sending a response

The completion of the question with the phrase “Answer, please send to the address ...” makes the receipt of the answer very unlikely. If you don’t have a couple of seconds to correctly set the Reply-To header in your email program, then we don’t have a couple of seconds to think about your problem. If your mail program does not allow this, drop it. If your operating system does not support mail programs that allow you to do this, look for a better operating system.

Asking for email responses in Web forums is extremely impolite unless you are sure that the information may be confidential (and someone, for some unknown reason, wants to tell you personally, not the entire forum). If you want to receive a notification by mail that someone replied to a topic in the forum, request this notification in the interface of the Web forum; this feature is supported almost everywhere in the form of options "watch this thread" ("watch the discussion"), "send email on answers" ("notify by mail"), etc.)

Write in clear language, following the rules of grammar and vocabulary

It has been experimentally established that people who write inattentively and carelessly are usually just as inattentive and careless in the thoughts and code of created programs (at least often enough to say so confidently). To answer the questions of people who are inattentive and carelessly thinking is a thankless task; we better spend our time on something else.

Therefore, the clarity and correctness of the wording of the question matters. If you don’t want to fool yourself with this, we don’t want to fool yourself, paying attention to such issues. Try to formulate the question in the correct language. It should not be heavy and formal - in fact, in an hacker culture, an informal, full of slang and humor language that is used correctly is appreciated. But thoughts must be expressed clearly; it is necessary to demonstrate at least some signs of thoughtfulness and attention.

Follow the rules for syntax, punctuation, and capitalization. Do not confuse "its" with "it's", "loose" with "lose" or "discrete" with "discreet". DO NOT WRITE EVERYTHING IN UPPER REGISTER - this is perceived as a scream and is considered rude. (If everything is written in lower case, it is not much better, because it is so difficult to read. Alan Cox is forgiven, but not for you.)

In the general case, if you write at the level of baby talk or crazy nonsense, your question will most likely be ignored. The scribble in the style of juvenile "hackers" (in the original - l33t script kiddie hax0r - approx. Translator ) - is absolutely hopeless, and guarantees in response - silence (or, at best, a portion of neglect and sarcasm).

If you ask questions in a forum where a language that is not native to you is used, then some lexical and grammatical errors will be forgiven - but do not expect elementary laziness (yes, we are usually able to understand the difference). In addition, if you do not know exactly which languages ​​for the recipient are native, write in English. Busy hackers usually just skip questions in languages ​​they don’t understand, and English is the working language of the Internet. By asking a question in English, you reduce the likelihood that it will be missed without reading.

Send questions in all understandable formats

If you artificially make it difficult to read a question, the likelihood that they will answer a question that is not difficult to read instead increases. Therefore:

  • Send the message in plain text, not HTML. ( Disabling HTML is not that difficult.)

  • MIME applications are usually quite acceptable, but only if they have real content (for example, the source text or a patch file is attached), and not just automatically generated by the mail client (representing, for example, another copy of the letter, but in HTML format).

  • Do not send messages in which paragraphs are represented by one line that visually wraps to the next line on the client. (This complicates the response to the part of the message.) Assume that the recipients will read messages on text terminals with 80-character lines, and configure the insertion of hard line breaks accordingly, ending the line at the 80th position.

  • At the same time, however, do not split data into several lines at a fixed position (for example, log dumps or session records). The data must be included in the messages as they are, so that the recipients are sure that they see exactly what you saw.

  • Do not send MIME Quoted-Printable messages to the English forum. This encoding may be needed when sending a message in a language that is not covered by ASCII encoding, but many user mail agents do not support it. Reading messages with control characters scattered throughout the text of the form = 20 is inconvenient and unpleasant.

  • Do not even think that hackers can read documents in proprietary, proprietary formats such as Microsoft Word or Excel. Most hackers respond to them in much the same way you would if you had smeared piggish shit at the front door. Even when they can read them, the need to tinker with these formats outrages them.

  • When sending a message from a machine running Windows, disable the moronic Microsoft support for Smart Quotes. This will get rid of a lot of garbage characters scattered throughout the message.

  • In Web forums, do not abuse the "emoticons" and the "html" insertion capabilities (if provided). One or two emoticons is usually normal, but colorful funny text makes people think that you are a lamer. Excessive use of emoticons, colors and fonts presents you as a funny teenage girl, which makes no sense, unless of course you are interested in answers, not sex.

When using an email client with a graphical interface (for example, Netscape Messenger, MS Outlook and the like), remember that it may violate these rules when using standard settings. Most of these clients have a menu command such as "View Source". Use it to check one of the sent messages that plain text is being sent, without unnecessary garbage.

Describe the problem accurately and in detail

  • Carefully and clearly describe the symptoms of a detected problem or error.

  • Describe the environment in which it occurs (machine, OS, application, etc.). Specify the distribution and release (for example: "Fedora Core 2", "Slackware 9.1", etc.).

  • Describe your research when trying to understand a problem before asking a question.

  • Describe your own steps to diagnose and isolate the problem before asking a question.

  • Describe recent changes to your computer or software configuration that may be relevant.

Do your best to predict potential hacker questions and answer them in advance in your appeal for help.

Simon Tatham wrote a great essay entitled How to Report Bugs Effectively . I highly recommend reading it.

Volume doesn't mean accuracy yet

Be accurate and informative. To do this, it is not enough just to insert a large amount of code or data into the request. If there is a large, complex test case that leads to an error in the program, try to minimize it.

This is useful for at least three reasons. First: the demonstrated efforts to simplify the question increase the likelihood of a response. Second: simplifying the question increases the likelihood of a useful answer. Third: when refining the error message, you yourself can find a solution or a workaround.

Do not claim to have found a mistake

If you encounter problems with a particular software, do not claim that you found a mistake, unless you are absolutely sure of it. Hint: if you cannot provide a source code fix that solves the problem or a test case for the previous version that demonstrates incorrect behavior, you are most likely not sufficiently confident in your statement.

Remember that many other users have not encountered such a problem. Otherwise, you would already know about this when reading the documentation or when searching the Web (you did it before you made such statements, right ?). This means that, most likely, it is you who are doing something wrong, and not the software.

The creators of the software make great efforts to make it work as best as possible. If you claim that you found a mistake, then you assume that they did something wrong, and they almost certainly will not like it - even if you are right. Especially non-diplomatic will be to write “bug” in the subject line of the message.

When asking a question, it is better to describe the problem on the basis of the assumption that you are doing something wrong, even if you are personally absolutely sure that you found a mistake. If this is really a mistake, you will read about it in the answer. Try to act in such a way that people who support the program want to apologize to you if a real mistake is found, and not to make you apologize for your stupidity.

Public humiliation does not replace homework

Some, having realized that it is not necessary to behave rudely or arrogantly, extorting an answer, choose the opposite extreme - self-humiliation. "I know, I'm a beginner, a loser and a complete teapot, but ...". This is distracting from the essence and does not make sense. Especially in combination with the uncertainty in the description of the actual problem.

Do not waste your time, and ours, hoping for pity. Present your facts and your question as clearly as possible. So you declare yourself much better than by self-humiliation.

Sometimes there are separate places for beginner questions in Web forums. If you feel that only a novice user can ask such a question, ask it there. But there is no need to humiliate themselves.

Describe the symptoms of the problem, not your assumptions

It is useless to tell hackers their opinion on the causes of the problem. (If your diagnostic theories are so valuable, do you need to turn to others for help?) Therefore, be sure to communicate the actual symptoms of what is happening, and not your interpretations and theories. Let the respondents take care of the interpretation and diagnosis.


I constantly get SIG11 errors when compiling the kernel, and I suspect that the cause is a microcrack on the motherboard. What is the best way to check this?


On a K6 / 233 computer I built on a FIC-PA2007 motherboard (VIA Apollo VP2 chipset) with 256MB Corsair PC133 SDRAM memory, SIG11 errors often start to occur about 20 minutes after turning on the power, during kernel compilation, but they do not occur in the first 20 minutes. Rebooting does not lead to anything, but disconnecting at night helps. Replacing the entire memory did not help. The corresponding part of the results of a typical compilation is attached.

Describe the symptoms of the problem in chronological order

The most important information for determining the causes of what is happening is often associated with events immediately preceding this situation. Therefore, it is necessary to accurately describe what you did and what the machine did until the problem arose. In the case of working with the command line interface, recording a session (for example, using the script utility) and including a couple of dozens of corresponding lines in a message can help a lot.

If the program in which the failure occurred has diagnostic options (for example, -v - detailed informing), try to select options that add useful debugging information to the "transcript" of the session.

If the record is long enough (more than a page), it makes sense to formulate the problem in advance at the beginning, and then indicate the chronological sequence of actions leading to it. In this case, hackers will know what to look for when reading a session.

Describe the goal, not a single step

If you're trying to figure out how to do something (rather than reporting an error), start with a description of the goal. And only then describe a specific step on the path to it that you could not perform.

Often people who need technical assistance have a high-level goal in mind and become attached to one of the possible, in their opinion, ways to achieve it. They ask for help to take one step, not realizing that they have chosen the wrong path. It can take a lot of effort to figure this out.


How to make the color picker dialog in FooDraw accept a hexadecimal RGB value?


I am trying to replace the color table in the image with the values ​​I need. Now I see only one way to do this - editing each slot in the table, but I can not set the hexadecimal RGB value in the color selection dialog of the FooDraw program.

The second version of the question is reasonable. It allows you to get an answer in which a tool will be offered that is more suitable for solving the problem.

Do not ask to reply to your personal email address

Hackers believe that solving problems should be a public, transparent process, during which the first attempt to find an answer can and should be fixed if someone who knows more knows that this answer is incomplete or incorrect. In addition, respondents are partly rewarded by the fact that their competence and knowledge will be noticed by colleagues.

When you ask for a personal answer, you interfere with both the decision-making process and the receipt of rewards. Do not do this. To answer personally is the choice of the respondent , and if he does, it is usually because he considers the question too poorly worded or obvious to be interesting to others.

There is one small exception to this rule. If you expect that you will receive a lot of similar answers to your question, do not forget the magic words "send an answer to me, and I will summarize the answers in an article for a discussion group." Trying to keep the discussion group or mailing list out of the flow of essentially identical messages is very kind, but you must keep your promise and send a summary.

Ask clear and concise questions.

Unlimited questions usually require unlimited time to answer. The people most likely to be able to give you a useful answer are also the busiest people (also because most of their work is done by themselves). Such people are jealous of their time, and therefore often do not perceive unlimited questions.

The likelihood of receiving a useful answer increases if you clearly make it clear what you want from the respondents (provide links, send a code, check your decision, etc.). This will concentrate the efforts of the respondents and implicitly set a time limit and the efforts that the responder will have to spend in order to help you. It's good.

To understand the world in which experts live, one must treat the knowledge of experts as an abundant resource, and by their time - as a very limited resource. The less time you implicitly require, the more likely it is to get a response from a really good and busy expert.

Therefore, it makes sense to limit the issue in order to minimize the time required by the expert to solve it. But often this is not the same as simplifying the matter. So, for example, the question: "Can you give me a link to a good description of X?" - usually much more reasonable than asking: "Explain X to me, please." If you have a problem with broken code, it would be wiser to ask for an explanation of what is wrong with it, rather than asking for a fix.

Do not ask questions from homework

Hackers are good at answering questions from homework - most of us did them on our own. These questions are asked to work for you so that you can learn from your own experience. You can ask for a hint, but not for a complete solution.

If you suspect that you were prompted with a question from your homework, but still cannot give an answer, try to ask a question in the user group forum or (in extreme cases) in the "user" mailing list / forum of the corresponding project. Although hackers "recognize" him, some of the advanced users may at least give you a hint.

Avoid meaningless requests

Resist the temptation to conclude your request with meaningless questions of the form: "Will someone help me?" or "Is there an answer at all?" Firstly, if you have at least some competent description of your problem, such additional questions are at least superfluous. Secondly, since they are redundant, they seem annoying to hackers - and in response they are encouraged to write a logically impeccable reply such as: “Yes, you can help” or “No, there’s nothing you can do to help.”

In the general case, yes-no answers are best not to be asked, unless you want a yes-or-no answer .

Do not mark your question as "Urgent", even if it’s just for you

This is your problem, not ours. Mentioning urgency is often counterproductive: most hackers simply delete messages such as rude and selfish attempts to urgently draw special attention to themselves.

There is one partial exception to this rule. Mentioning urgency may make sense if you use the program in a serious organization that might interest hackers; in this case, if you do not have enough time and politely report it, people may be interested enough to respond quickly.

Doing this, however, is extremely risky, because the hacker's point of view on seriousness and his interests are likely to differ from yours. The question from the international space station, for example, will arouse interest, but the question on behalf of a prosperous charitable foundation or political party is almost certainly not. In fact, the question with the topic "Urgent: Help me save the furry seals!" will be ignored or viciously commented even by those hackers who believe that the life of furry seals matters to them.

If this surprises you, re-read the rest of the document until you understand, and before that refrain from sending questions at all.

Courtesy never hurts and sometimes helps

Be polite. Use the phrases "Please" and "Thank you in advance." Let us know that we are grateful to people who devote their time to you for free.

To be honest, this is not so important as the absence of errors in the text of the question, clarity, accuracy and detail of the description, the use of open formats, etc. (and does not replace all of the above); hackers, in general, would rather receive rude but technically accurate error messages than polite verbiage. (If this surprises you, remember that we value the question for what it teaches us.)

However, at the normal technical level of the question, politeness does increase the likelihood of a useful answer.

(It should be noted that the only serious objection to this document from veterans of the hacker movement is related to the recommendation to use the phrase “Thank you in advance.” Some hackers see it as reluctance to thank anyone after the problem has been resolved. We recommend give thanks both in advance and after receiving the response, or express your gratitude in another way, say, with the phrase “Thank you for your attention” or “Thank you for your consideration.”)

Send a brief description of the solution

After the problem is solved, send a message to everyone who helped you; let them know how it ended and thank you again for your help. If the problem has caused general interest in the mailing list or discussion group, it makes sense to send such a message there.

It will be optimal to answer in the thread of discussion that began with the original question by adding the mark 'FIXED', 'RESOLVED', 'SOLUTION' or another no less obvious sign of a solution to the subject of the message. On mailing lists with a large number of messages, a potential responder looking at the thread of the discussion "Problem X", ending with the message "Problem X - SOLUTION" understands that he does not need to waste time even reading messages (if he personally does not find Problem X interesting) , and therefore can spend time solving another problem.

Such a message does not have to be long and detailed; simple: "Hello! The problem was connected with a break in the network cable! Thanks to everyone. Bill," is already better than nothing. In fact, a short and polite resume is better than a long dissertation, unless the decision touches on serious technical aspects. Write down what actions allowed to solve the problem, but the entire sequence of the search for a solution does not need to be re-described.

For serious problems, you can send a resume with a history of finding their causes. Describe the final statement of the problem. Describe what the solution turned out to be and indicate the deadlocks that should be avoided. Name everyone who helped you: so you will find friends.

In addition to being polite and informing, this kind of brief message will help others when they search the mailing list / discussion group / forum in the archive to find out exactly which solution helped you, and therefore can help them.

Last, but not least, this kind of message helps everyone involved in the discussion to get a feeling of satisfaction from the fact that the problem is closed. If you yourself are not a technical expert or a hacker, just trust us that this feeling is very important for the gurus and experts you have contacted for help. Descriptions of problems that, as a result, have not been resolved are a complete disappointment; hackers crave to see them solved. The good karma that arises when you satisfy this thirst will help you a lot when asking a question next time.

Think about how you can prevent other users from having the same problem in the future. Ask yourself if a change in the documentation or the FAQ list will help, and if so, send the appropriate change to those who support these documents.

Among hackers, such behavior is, in fact, considered more important than ordinary politeness. This is how they earn a reputation as a good team player, which is a very valuable quality.

How to interpret the answers

RTFM and STFW: how to understand that you are seriously screwed up

There is an ancient and sacred tradition: if you get the answer " RTFM ", then the respondent thinks that you should read the manual ( Read The Fucking Manual ). He is almost certainly right. Read.

The RTFM response has a younger counterpart. If you get the answer " STFW ", then the respondent thinks that you should look for the answer online (Search The Fucking Web). He is almost certainly right. Search.

In Web forums, you may still be offered to search the forum archives. In fact, the responder may be so kind as to give a link to the previous discussion in which this problem was resolved. But do not rely on it; search the archives yourself before asking.

Often, the one who sends one of these answers has at hand a manual or a web page with the information you need, and looks at it when it types the answer. These answers mean that, in his opinion, firstly, the information you need is easy to find and, secondly, you will learn more when searching for information than if you are presented with it under the nose on a plate.

This should not disturb you; by hacker standards, he showed you enough respect already by not ignoring the question. You must thank the person responsible for his paternal kindness.

If you do not understand ...

If you do not understand the answer, do not immediately send a demand to explain it. Use the same sources of information as when searching for the answer to the original question (manuals, FAQ, Web, experienced colleagues) to understand the answer. If after this you need clarification, show what you yourself have learned.

For example, suppose I answered you: "It looks like you have a zentry; you need to check." Then a bad clarifying question would be: "What is zentry"? A good one : "OK, I read the manual page, and about zentry it is mentioned only in the -z and -p options. None of them say how to reset a frozen zentry. Do I have to use one of these options, or am I misunderstood? "

Rude reaction

Most of what may seem rude in hacker circles is not used to insult. Rather, it is a consequence of the direct, without blunts, communication style that is natural for people trying to solve problems, and not seem soft and fluffy to others.

When meeting rudeness, try to respond calmly. If someone really goes beyond what is acceptable, it is likely that the host of the mailing list, discussion group or forum will put him in his place. If this does not happen and you lose your temper, it is likely that the person who caused this behavior behaves within the framework of the norms of the hacker community, and everyone will assume that it is you who are wrong. This will significantly reduce the chances of getting the necessary information or help.

On the other hand, one can sometimes encounter rudeness and a challenge that have no apparent basis. The flip side of this coin is that such a reaction is a perfectly acceptable form of putting real snappers in place - we cut off their unworthy behavior with a sharpened verbal scalpel. However, you must be very confident in your position before trying to do this. The line between indicating impolite and the beginning of a meaningless "bazaar" (in the original - flamewar - approx. Translator ) is so thin that hackers themselves often cross it. If you are a beginner or just an occasional reader, there is little chance of avoiding such a blunder. If you are interested in information and not entertainment, it is better to remove your hands from the keyboard and do not risk engaging in such discussions.

(Some insist that many hackers suffer from a mild form of autism, or Asperger’s syndrome , and they simply don’t have the part of the brain that is responsible for the “normal” social interaction between people. Perhaps this is true, or maybe not. If you - not a hacker, the idea of ​​hackers as patients on your head can help you come to terms with our oddities. Think what you want. We don’t care; we like to be just like that, and we treat skepticism with healthy skepticism.)

In the next section, we will talk about another problem; about a kind of "rudeness" that you can meet when it’s you who are wrong.

Do not react like a loser

It is likely that you have screwed up several times in hacker forums - as described in this article, or similarly. And you have already been explained exactly how you screwed up, possibly in the colors. With all honest people.

When this happens, the most unfortunate reaction is to complain about what happened, consider yourself verbally offended, demand an apology, yell, choke with anger, file lawsuits, complain to the employers of the offenders, do not lower the toilet seats, etc. Instead of all this, do the following:

Come to terms. This is normal. In fact, it is good and appropriate.

Social norms do not support themselves - they are supported by people who actively, openly, publicly apply these norms. Do not think that they should criticize only in personal correspondence - this is not so. It does not make sense to accept as a personal insult someone’s comment that one of your statements is wrong, or that he has a different opinion. So losers act.

There were hacker forums where, based on incorrectly understood hypertrophied politeness, participants were forbidden to send error messages in other people's messages. They were told: "If you do not want to help the user, be silent." The outflow of knowledgeable participants to other forums led to their degeneration into meaningless chatter and to complete futility from a technical point of view.

Choose: exaggerated "friendliness" (of this kind) or usefulness.

Remember: when this hacker writes that you screwed up, and (no matter how rude) asks you not to do this anymore, he does this, taking care, firstly, of you, and secondly, of his community. It would be much easier for him to ignore you and cross out of his life. If you are lacking in gratitude, preserve your dignity - do not complain, and do not think that you will be treated like a fragile doll just because you are a beginner with a theatrically hypersensitive soul and illusions about your own significance.

Sometimes people will become personal, engage in dirty polemics for no apparent reason, etc., even if you haven't screwed up (or screwed up only in their imagination). To be indignant in this case is a way to really screw up.

These "scandalists" are either lamers who do not understand anything, but consider themselves experts, or potential psychologists who check whether you screw up or not. Other readers will either ignore them or find ways to deal with them on their own. The behavior of brawlers creates problems for themselves, which should not bother you.

Do not let yourself drag yourself into a useless "bazaar". It is better to ignore such discussions, having figured out first that this is really a useless "bazaar", and not hints on why you really screwed up, and not finely encrypted answers to your actual questions (this also happens).

Questions not to be asked

Here are a number of classic silly questions and what hackers think about when they are not answered.


Where can I find program or resource X?


In the same place, where I took it, moron, to find it on the Internet. God, don’t everyone know how to use Google ?


How can I make Y with X?


If you want to make Y, you should ask like that, without suggesting in advance the use of a method that may not be suitable at all. Questions of this kind are often asked by those who not only know nothing about X, but are confused by the problem Y being solved and are too focused on the details of their specific situation. It is usually best to ignore such people until they formulate their problem better.


How to configure a shell prompt?


If you are smart enough to be interested in this, you will be smart enough to independently search for an answer.


Can I convert an AcmeCorp document to a TeX file using the Bass-o-matic file conversion program?


Try and find out. So, firstly, you will find out the answer, and secondly, you will stop wasting my time.


My {program, configuration, my SQL statement} does not work


This is not a question at all, and I am not going to ask a dozen more leading questions to find out what your problem really is - I have things to do and more interesting. When I see such questions, I usually send one of the following answers:

  • You have nothing more to add to this?

  • Oh, this is very bad. I hope you have already fixed this.

  • And what does this have to do with me personally?


I have problems with a windows machine. Could you help me?


Yes. Throw out this Microsoft garbage and put yourself an open source operating system such as Linux or BSD.

Note: you can ask questions related to Windows machines if they relate to a program that has an official version for Windows or that interacts with machines under Windows (for example, Samba). Just don’t be surprised at the answer that the problem is in Windows, and not in the program itself, because Windows is so “crooked” as a whole, that often it just happens.


My program is not working. I think the problem is in the X system component.


Although it is possible that it was you who first discovered the obvious mistake in system calls and libraries that are intensively used by hundreds or thousands of developers, it is much more likely that you simply did not understand. Serious allegations require serious evidence; if you make such statements, they must be supported by a clear and comprehensive description of the situation in which the failure occurs.


I'm having trouble installing Linux (or X). Could you help me?


Not. To solve this problem, I need direct access to your machine. Ask a local Linux user group who can personally help. (A list of user groups can be found here .)

Note: Linux installation questions may be appropriate in a forum or mailing list dedicated to a particular distribution, if the problem is related to that distribution, or in forums of local user groups. In this case, be sure to accurately describe the details of the failure. But first, search the Web carefully for the keywords “linux” and any suspicious hardware components.


How to crack root user password / get extended privileges / read someone else's email?


Yes, you're just a jerk, since you want to do this, and you idiot, just ask the hacker to help you.

Good and bad questions

Finally, I’m going to show with examples how to ask questions correctly. I will present a couple of questions about the same problem, one is asked stupidly, and the second is correct.

Silly: Where can I find information about Foonly Flurbamatic?

This question just begs for the answer "STFW" .

That's right: I tried to search the Web using Google for the query "Foonly Flurbamatic 2600", but I didn’t get any useful links. Does anyone know where to find programming information for this device?

This questioner has already searched the Web and seems to have a real problem.

Stupid: I can't compile the foo project code. Why is it incorrect?

He thinks someone else screwed up. Self-confident type.

Correct: The foo project code does not compile on Nulix OS version 6.2. I read the FAQ, but there is nothing about problems with Nulix. Here is a compilation session record; What did I do wrong?

He pointed out the environment, read the frequently asked questions, showed the error message, and he does not think that the cause of his problem is someone else’s error. This guy can be given a little attention.

Stupid: I have problems with the motherboard. Can anyone please help?

Any hacker will answer such a question in his mind, most likely: “Good. Maybe you can also help to burp and change the diaper?”, And press the Delete key.

That's right: I tried X, Y, and Z on the S2464 motherboard. When it didn’t work, I tried A, B and C. Pay attention to a strange symptom when trying to make C. Obviously this garbage doesn’t rattle, but the results are unpredictable. What usually leads to the fact that multiprocessor motherboards with Athlon fail? Does anyone have any ideas for additional tests that will help isolate the problem?

This comrade, on the contrary, seems worthy of an answer. He demonstrated the ability to solve problems, and not just wait until the answer falls to him from heaven.

In the last question, pay attention to the small but important difference between “Give me an answer” and “Please help me figure out what additional diagnostic steps you can take to clarify the situation.”

In fact, the form for asking the last question is very similar to the one actually used in August 2001 on the linux-kernel mailing list. I (Eric) then asked this question. I observed strange freezes on the Tyan S2464 motherboard. The members of the mailing list provided valuable information that allowed me to get rid of these hangs.

By asking a question in the way I did, you give people food for thought; I made participating in the solution of the problem simple and attractive for them. I demonstrated respect for the abilities of my colleagues and invited them to discuss on an equal footing. I also demonstrated that I value their time by describing which dead-end branches I have already passed.

In the end, when I thanked everyone and emphasized how well the process of solving the problem went, one of the members of the mailing list drew attention to the fact that, in his opinion, it didn’t work out because I was a "famous person" on this list, but because of the correct form of posing the question.

Hackers, in a certain respect, are a very cruel intellectual elite (in the original - meritocracy . Approx. Translator ). I am sure that he is right, and if I screwed up , I would be criticized or ignored, regardless of previous merits. His suggestion to describe the situation as a guide for everyone else was the immediate reason for writing this guide.

If no response is received

If you do not receive an answer, do not take it personally, as our refusal to help you personally. Sometimes forum participants simply do not know the answer. The absence of an answer is not tantamount to ignoring, although it is difficult to notice the difference from the outside.

In general, re-submitting a question is not a good idea. This will be perceived as meaningless annoyance.

There are other sources of help that you can turn to, often more adapted to the needs of beginners.

There are many user groups online and locally enthusiastically involved in software, although many of their members have never written a single serious program. These groups are often formed so that participants help each other and new users.

There are also many commercial companies with which you can conclude a support contract, both large and small (some of the most famous are Red Hat and Linuxcare, but there are many others). Don’t be afraid of the idea of ​​paying for support! In the end, if overhaul of the car engine is needed, you will give it to the workshop and pay for the repair. Even if the software was worthless, you can’t expect that it will always be supported for free.

Popular software like Linux has at least 10,000 users per developer. One person simply can not cope with the support of 10,000 users. Remember that even if you have to pay for support, it still costs much less than when you have to buy the software itself (and support for proprietary software is usually more expensive and performed by less competent specialists than in the case of open source software code).

How to give good answers.

Be generous. Stress related to the problem can make people who are not impolite or stupid.

Indicate the first error privately. There is no need to publicly humiliate a person who may be honestly mistaken. A novice user may not know how to search the archives or where a list of frequently asked questions is located or published.

If you're not sure, say so! An erroneous, but authoritatively sounding answer is worse than no answer. Do not direct people on the wrong path simply because you are pleased to be in the role of an expert. Be humble and honest; Set a good example for askers and colleagues.

If you can’t help, do not bother. Don’t joke about procedures that can ruin the user's environment - this blockhead can take your jokes as a guide to action.

Ask more questions to get more information. If you do it right, the asker will learn something, and so will you. Try to turn a bad question into a good one; remember - we were all beginners.

Although the simple answer of RTFM can be justified when given simply to a lazy person, a link to the documentation (even if it is a set of keywords for searching on Google) is still better.

If you are already answering the question, let's get the answer in essence. Do not suggest hastily invented workarounds if you use the wrong tool or the wrong approach. Offer good funds. Reformulate the question.

Help the public benefit from the issue. When you come across a good question, ask yourself: "How do I change the relevant documentation or the FAQ list so that no one else asks this question?". Then send the appropriate supplement to the one who supports these documents.

If you had to conduct a study to answer a question, share your experience, and do not write as if the answer has fallen on you from heaven. To answer one good question is how to feed a hungry one time, but setting out a research methodology using an example means learning to get food for life.

Additional sources of information

If you need information on the basics of personal computers, Unix, and the Internet, see The Unix and Internet Fundamentals HOWTO .

When creating software or releasing software fixes, try to follow the principles outlined in the Software Release Practice HOWTO .


Evelyn Mitchell offered to comment on a number of silly questions and inspired to write the section "How to give good answers." Mikhail Ramendik made a number of valuable suggestions for improving the document.