5.8. I Need Help and Am Afraid of Asking Online
I believe that Linux geeks are helpful. They'll take time that they don't have to help you with an interesting problem. They love good questions, as they can help them learn more about Linux. On the other hand, many Linux geeks are strong-willed. They are not known for social graces. In short, Linux geeks (other than yourself) can be annoying. But if you do your homework and treat the Linux community with dignity and honor, you can keep annoyances with Linux geeks to a minimum. While there are no guarantees, you'll probably get a better response from the Linux community if you follow these principles:
If you're learning to do something, read the associated HOWTO. Learn the associated manpages. If you're having a problem, read the appropriate logfiles in your /var/log directory. For example, if you're having a problem with Windows file sharing, review the newest files in the /var/log/samba directory. Examine the error messages. Use Google and Google Groups (http://groups.google.com) to search the Web and associated newsgroups for others who've had the same problem. I often search quoting the same or similar error messages. I've found at least a few others who've had similar problems almost every time. There are other sites with Linux-dedicated message boards, which may also be helpful. Be prepared. Know (and be able to cite) your relevant hardware. Have key configuration and logfiles handy.
Use your favorite Linux book! Many are available from O'Reilly and other reputable publishers. Even this author has written other Linux books with more detailed information.
If you've done your homework and still need help, there are several options:
If your Linux distribution comes with support for your problem, use it. You've paid for it!
If your Linux distribution has mailing lists or IRC channels, ask your question there, using the guidelines described in the next section.
If you're working with a specific service, there may be a mailing list or newsgroup associated with that service. For example, Samba has their own mailing lists, and there are several newsgroups focused on that service.
5.8.1. Selecting a Newsgroup or Mailing List
There are perhaps thousands of mailing lists and newsgroups available on different subjects associated with Linux. Selecting the right newsgroup or mailing list can save time and help you get the answers as quickly as possible. When looking for answers, follow these guidelines:
Look for the right group. For example, it's not a good idea to ask a question about the DEB packaging system on a Red Hat newsgroup. Most of the readers (and even many of the gurus) won't have the experience that you're looking for to answer your question. And they will not hesitate to tell you so, sometimes in less-than-polite terms.
Make sure the group is active. There are a lot of inactive newsgroups. If few people see your question, you're not likely to get a response. Review the latest newsgroup headers, and check the dates.
Read over previous messages on the newsgroup. If you're comfortable with the level of expertise, proceed with your message. See "Posting Guidelines for Newsgroups and Mailing Lists," later in this annoyance, for some posting rules of thumb.
5.8.2. Signing Up for a Mailing List
There are a substantial number of mailing lists dedicated to Linux. Many are organized by distribution (see the following table). When you sign up for a mailing list, you're getting an account on that list. Remember, these lists are by and large staffed by volunteers. If you want to unsubscribe, use your account. Alternatively, check the bottom of the message. Unsubscribe information is often also available there.
Users often get frustrated with the volume of messages on some mailing lists, such as the main Fedora Linux list. Many have asked the Fedora group, in a message to the whole list (thousands of people), for instructions on how to unsubscribe. The Fedora lists put instructions on how to "unsubscribe" at the bottom of each message. Unless you've tried and are having problems with the instructions (which may indicate a problem with a server), and cannot identify a mailing list administrator, it is bad form to ask the group to unsubscribe you from any mailing list.
Almost as annoying are the mailing-list subscribers who inadvertently send their vacation messages to the entire mailing list. Without the proper settings, a user's vacation message is sent as a reply to every mailing-list message. Don't get caught with this problem.
5.8.3. Organizing a Newsgroup or Mailing-List Message
Linux users and geeks ask for help all the time. It is axiomatic; the only stupid question is the one that is not asked. However, there are unhelpful ways to ask a question, many of which will irritate the average Linux geek. Some (sanitized) examples include:
These are examples of unspecific generic questions, which make it difficult for others to help. If they're peeved enough, a likely answer is an admonishment to "Do your homework before asking another question!" Less chastising would be a link to standard documents such as the Sound and CD-Writing HOWTOs, available from http://www.tldp.org. The thought of a Linux beginner who wants to pass the Red Hat Certified Architect (RHCA) exams might lead to derisive laughter, or a link to the Red Hat home page for this newest and most advanced certification.
There are correct ways to ask a question on a newsgroup or mailing list. What I cite certainly isn't the only way. You may already be experienced with newsgroups. But remember, there are a whole army of Linux geeks who have trouble with newsgroups and commonly end up in flame wars.
When you have a new problem, start a new thread. Direct your message directly to the mailing-list address.
Stay focused on one topic. For example, if you ask unrelated questions about Samba and DVD movies on one thread, it will be more difficult for others to respond.
Summarize your topic or problem in the subject line. Keep it short. Subject lines that are too long are more likely to be deleted.
Provide a brief description of your problem. If there's a service involved, include key lines from the appropriate configuration file. Don't overdo it. For example, the contents of /var/log/syslog would overwhelm most readers with irrelevant info; most will avoid your message. And if you have personal information and/or encrypted passwords, do leave them out of your message.
List the versions of the applicable software or services. Others need to know what you're working with.
State what you've done to try to solve the problem.
List the resources that you've readsuch as HOWTOs, FAQs, and documentsin your efforts to solve the problem.
If you're seeing errors, include key lines from logfiles. Boot messages can be found in the dmesg output. Service messages are normally listed in specific logfiles or directories. Other errors can be found in /var/log/messages. Don't include the entire output of your /var/log/messages file; mine are typically text files with tens of thousands of lines (which corresponds to several MB of data).
There is also a right way to answer questions on a newsgroup or mailing list. As a Linux geek, you are part of a community. You have a responsibility to share what you know. It's like participating in a democratic society. If you can help someone who needs help with Linux, you're contributing to the success of this operating system:
Just as you should keep your questions as short as possible, keep your responses short. If you know that the answer is available in another document, such as a HOWTO, it's appropriate to cite that document.
Don't feel obligated to answer all questions associated with the message. If you only know the answer to one of the questions, it's OK to just answer that question. Edit out the other issues, and include your answer inline or after the end of the message.
By convention, Linux users post responses at the bottom of a message. This allows others to read archived messages with the problem at the top and the solution at the bottom.
5.8.4. Posting Guidelines for Newsgroups and Mailing Lists
There are a number of basic guidelines that can help you cope in the world of Linux geeks. Some are well known, such as avoiding the use of caps so others don't think you're shouting. Here are some additional guidelines:
Don't post in HTML. A number of Linux geeks use text-based messaging solutions. HTML email can foul up such clients.
Don't hijack the threads of others. Mailing lists are organized in threads. When you have a new topic, it's best to start with a new message. For example, new messages to the main Fedora mailing list should be sent directly to firstname.lastname@example.org. As an example, assume there's a current thread on sound cards, and you want to ask the group about graphics settings. If you use the "Reply" function on an email client such as Kmail, Evolution, or (heaven forbid!) Outlook Express, your reply will show up as part of the sound card thread, even if you change the subject line.
Avoid cross-posting where possible. Cross-posting is when someone posts the same message on multiple mailing lists. Many Linux gurus often subscribe to a large number of mailing lists. If they see your message multiple times, they're less likely to help.
Limit the length of your lines. More than 72 characters per line can make it difficult for some to read your message in their email readers.
When you answer a message, edit it and leave the relevant questions. This minimizes the size of the email. Answer the message inline. This makes it easier for the reader to associate your answer with the question at hand.
If you must have a signature line, keep it short. Start them with a delimiter; a standard is a couple of dashes followed by a space (-- ). Many newsreaders take this delimiter to strip out the signatures.
5.8.5. Flame Wars
A flame war is when deliberately hostile messages are posted on a mailing list or discussion board. It's easy to say "Don't get involved in flame wars." It can be difficult to put into practice, especially if you feel passionate about a topic. And many Linux geeks are passionate about their beliefs. There are several principles you can follow that can help keep a flame war from becoming personal:
Don't be afraid to step away. Online discussions move quickly, and anything that you may have said is usually quickly forgotten.
Focus on the subject. Do not attack the person.
Keep looking at how to solve the problem at hand.
State your opinions clearly. Experiences differ. You can speak to your own experience. Do not try to speak for others.
Avoid discussions beyond your expertise or experience. For example, it's usually not helpful to say "copying this software breaks the law" unless you are a lawyer with expertise in that particular area of the law. And if you do have that kind of expertise, you should know that expressing such opinions could get you into a different kind of trouble.
And again, don't be afraid to step away from a flame war. There are more important things in life.
Not all flame wars are bad. Many become serious academic discussions about softwarefor example, the important discussions between Andrew Tannenbaum (the creator of Minix) and Linus Torvalds on the use of microkernels and monolithic kernels in the operating system. If you get involved in a flame war expecting a serious academic discussion, be careful. Not everyone can conduct a debate like Tannenbaum and Torvaldsor, for those of you familiar with U.S. history, Lincoln and Douglas.
Abraham Lincoln and Stephen Douglas conducted a series of debates in the mid 1800s, a few years before the American Civil War, that stand in the annals of political history. Each of their debates lasted several hours and held the interest of the many thousands who watched it live (and out of doors). Even though they were vigorous political rivals, they remained friends throughout. Douglas supported Lincoln after he became president of the United States in his efforts to keep the U.S. together. If you think you can manage a debate like Lincoln or Douglas . . . .
5.8.6. Posting in Bugzilla
If you are a Linux geek, there will be times where nobody will be able to answer your question. If the previous steps have failed, it's time to post a bug report, more commonly known as a Bugzilla. A Bugzilla is a single bug or feature request, documented on an appropriate list of bugs for a Linux distribution, application, or service. There are guidelines to Bugzilla reports as well:
Check the current Bugzilla database. Someone may have already reported the problem.
Make sure your problem is reproducible. A hacker can't help you if he can't reproduce the problem on his own PC. Document the steps you took when you encountered the problem.
Report the issue to the proper developers. If you're having a problem with the functionality of OpenOffice.org Writer, it's generally less helpful to report it on the Debian bug list. The people who need to see it are the developers of OpenOffice.org Writer.
Note the distribution and packages in question. Linux distributions are large. Different developers have responsibility for different packages. Bugzilla procedures often prompt you in this process.
Some Bugzilla reports are feature requests. If you want action, be realistic. Don't ask for a service that creates world peace. Do ask for features that can improve a product. One simple example of a feature request that I made was to Red Hat's X Configuration tool. I asked that the associated configuration file note whether it was created by Anaconda (the Red Hat Installation tool) or the post-installation configuration tool (system-config-display).