Getting Help

Getting Help

If you’re like me, you think the manual is for cowards. Any good computer hacker should not be afraid to open up the box and start feeding in disks without any regard for the consequences. You tear open the box, yank out the floppies, pop the first one in the drive, and start up the Software Manger and happily go through the thankless task of installing the software. After everything has been installed and your desktop icons have been created, you double-click the icon and start your new multimedia Web viewer. But wait! It doesn’t work right. No matter how much you point and click and click again, nothing happens. In frustration, you get on the phone and frantically dial the 800-number from the back of the manual (making this the first time you opened it).

When you finally get through to support after waiting for two hours (it was actually only five minutes), you lash out at the poor tech support representative who was unlucky enough to get your call. You spend more time ranting about poorly written software than you spent on hold. When you finally finish insulting this persons ancestry, he or she calmly points out that on page 2 in the manual, where it describes the installation procedure, it says that to get the Web to work correctly, you have to have a network installed. Because you decided not to install TCP/IP when you first loaded the system, there is no way for the Web browser to work. You’re embarrassed and the whole situation is not a happy thing.

Some people might want to say that things are not the same with Linux support as you don’t have the same kind of support as with “commercial” products. Well, many Linux vendors offer 30 day installation support, as well as have fee-based support afterwards. So the issues are the same. Furthermore, just because you are posting to a “free” mailing list instead of calling support. There are a a number of things to do before you go looking for help.

One important aspect of solving problems yourself is actually trying to solve the problem yourself. This might seem too obvious to mention, but what really is not obvious is the extent to which you really should go to before turning to others for help. This is not because others are annoyed with “stupid questions”, but rather the time is better spent working on the hard problems and not the ones that people should be able to solve on their own.

A way to do that is to read the HOWTOs and other documentation before, during, and after the installation. Doing so tends to limit the embarrassing calls to tech support or posts to newsgroups, but the world is not perfect and eventually something will go wrong. Programs are (still) written by human beings who can make mistakes, which we users call bugs. Perhaps the QA technician who was checking your SCSI host adapter sneezed at the very moment the monitor program reported an incorrect voltage. Maybe the manufacturer never tested that one, rare set of circumstances that causes the program to freeze the way it did on your machine. The end result is that you’ve read the manual, checked and rechecked the hardware, and it still does not behave the way it is supposed to. You can’t solve the problem yourself, so you need help.

If you ever find yourself in a situation where you cannot solve the problem yourself and need to access any of the various resources on the Internet, there are a few ground rules that you need to adhere to. These are called “Netiquette” (net-etiquette). For a detailed discussion on netiquette, I would suggest the Netiquette Home Page. This is essentially the online version of the book Netiquette by Virginia Shea.

There are, however, a few important points that I would like to make. First, do your own research. In the sections on Linux documentation and Other linux resources we discussed many different places you can look for answers to your questions. You should always try these first before you go to a newsgroup or mailing list. Most of the time you will find the answer yourself. This is much more beneficial to your understanding of Linux than simply having someone spoon feed you your answer. Also, if you do not find your answer, or the answer is hard to understand, telling others where you look and what you found, keeps others from giving you the exact same answer, thereby saving time for everyone.

What problems a person should be able to solve on their own is not as easy to define as you might think. For example, I have read posts to mailing lists describing problems and quote the error message they are getting. The user has never used the program before and so the error is pretty meaningless (other than saying “something” is misconfigured or not found).It might be reasonable to post such a question to news group. However, I remember one case where the person posted the problem for the third time and no one had answered. He was indignant that no one had a solution for him. Well, I took the exact error message he was getting and did a search on Google for it. The very first post was someone else who posted months before and the reply was very specific steps to solve the problem. Had this person searched google before the first post, they would have had a solution already.

I cannot tell you enough that Google is your friend. It might take a little practice on phrasing your search text properly to get the answer you are looking for. However, it is worth it. First, you may not always get the specific answer you want, but you find a lot of cool and useful sites. I cannot begin to count the sites I have stored in my booksmarks that I stumbled across when looking for something else. Second, there is a great chance you will find something that will help, particularly if you have a specific error message. Third, it’s a great way of finding information, whether you have a problem or just want to find more information.

If you don’t find an answer on Google or any other search engine, try searching an online forum for the answer. On linuxnewbie.org is a great forum with tens of thousands of posts. They have a search mechanism to dig through old posts. Maybe there is something there that will help. If if is a common problem, you will probably find an answer. If it is uncommon, then at least you have tried all the common solutions.

When you finally do post, list not only what you are trying to do, but how you expect it to behave. Don’t simply say “it doesn’t work right.” While working in tech support, I have numerous calls from customers who assumed that something was not working correctly, when it actually was. They had incorrect assumptions about the way things were “supposed” to work. Since their assumptions were wrong, the expected behaviour was not what was “correct”.

Also, make sure you tell people what you have already tried and what the results were, even if what you tried couldn’t be correct. For example, I had trouble connecting my DSL card because the instructions from my ISP talked about an DSL modem and not an expansion card. Plus, I already had an existing ISDN connection and a switch-box to which all of my phones connected. When I posted to a mailing list, I listed the various combinations and locations of the cables and various boxes, indicating why I though each one was incorrect. This got me more detailed answers than in I simply asked “How do I connect my card?”. Less than 20 minutes later I was on-line.

Whether you post to a newsgroup, mailing list, forum or to the owner of sites like mine, remember that no one owes you an answer. We will do our best to help, but sometimes we cannot. Maybe we don’t have any experience with a particular issue or maybe we just don’t have the time at the moment. Also, people will often simply ignore messages when the answer is listed in a HOWTO, the man-page or some other obvious place.

You may end up with someone who simply replies “man whatever”, where “whatever” is some command. Don’t be annoyed at terse answers like that. If you already looked at that man-page, then you should have already said so in your post. If not, then there is probably something in that man-page which will help. Don’t expect people to hand you the answer on a silver platter, especially if you don’t do any work yourself.

If the reponse does not answer your question, then be polite when telling them, even if you feel that the response would “obviously” not answer your question. Sometimes people respond based on pre-conceptions that you do not have. I find this to especially be the case when someone does not provide details of the problem, like error messages, things that were changed recently, and so on.

Another very polite (and useful) thing is to thank people for their efforts, even if they did not solve your problem. If you get a reputation for someone who simply asks the questions and never responds to the solutions, you may find that people stop answering you. Also, if the reponse solves your problem, reply back to the newsgroup or mailing list and add (SOLVED) (or something similar) to the end of the subject. That way other people will know that the issue has been solved.

Also, when you reply, you should reply to the group and not to the individual and certainly not to both the group and individual. Since the person replied to your post, there is no need to reply to both as he or she will certainly see your message. If you reply just to the person, then others in the group do not have the benefit of knowing if the solution worked or any other information that was exchanged.

Depending on what program you use when replying to a mailing list or news group, you need to pay attention to the default behaviour when you simply click “Reply”. Some reply to the group and some reply to the sender. I have been convinced that the proper behaviour is to reply just to the individual. This is because it is less dangerous to make a mistake and reply to a single person when you wanted to reply to the group, as compared to replying to the group when you ment to only reply to the individual. Either way, you need to be aware of the behaviour of your mail or news reader.

When starting a new subject (also called a “thread”), do not simply reply to an existing message. The advanced mail and news readers that come with Linux keep track of the messages and can display them hierarchically, based on who replied to whom. These are called “threaded” readers as they properly manage the various threads. They typically allow you to collapse or expand individual threads, giving you a much better overview than if each message was listed individually. If you start a new topic by replying to an existing message, you defeat the whole purpose of threaded readers and may end up having your question go unaswered because people simply do not see it.