The most commonly known source of help is the company’s tech support department. With Linux, however, there is no one to call. At least, there is no one single company or organization to call. If you bought Linux as part of a complete system or from an established distributor, they will probably be able to help you. Many have free e-mail support for those who can’t afford the phone support. Many also will charge you a certain amount per minute or a flat fee per call. However, even if you are left with other sources, such as USENET newsgroups or the mailing lists, going through “tech support” has the same basic principles, so I will address this as though you were getting help directly from the company.

Tech support is like any system. You put garbage in and you’re likely to get garbage out. Calling in and demanding immediate results or blaming the support representative for the problem will probably get you one of a few responses. They’ll tell you that it’s a hardware problem if you’ve called a software company, a software problem if you’ve called a hardware company, or they’ll say there is “something” else on the machine conflicting with their product, but it’s your job to figure it out. You may even get an answer that, yes, that board is bad, and you can return it to the place of purchase to get a refund or exchange. In other words, they blow you off.

If the board was bad, getting a replacement solves the problem. If there is a conflict, however, you will probably spend even more time trying to track it down. If the problem is caused by some program problem (conflicts or whatever), reinstalling may not fix the problem.

Rather than spending hours trying to track down the conflict or swapping out boards, you decide to call tech support. The question is, “Which one?” If there is only one program or one board, it’s pretty obvious which tech support department to call. If the problem starts immediately after you add a board or software package, the odds are that this has something to do with whatever you just installed. If, however, the problem starts after you’ve been running for a while, tracking down the offender is not that easy. Thats why you’re going to call tech support, right? So grab that phone and start dialing.

Stop! Put that phone down! You’re not ready to call yet. There’s something you need to do first. In fact, you need to do several things before you call.

Calling tech support is not as easy as picking up the phone and dialing. Many people who are having trouble with their systems tend to think that it is. In many cases, this is true. The problem is basic enough that the tech support representative can answer it within a few minutes. However, if it’s not, your lack of preparation can turn a two-minute call into a two-hour call.

Preparation for calling tech support begins long before that first phone call or the first news post. In fact, preparation actually begins before you install anything on your system. I mean anything before you install your first program, before you make the change to .profile to change your prompt, even before you install the operating system.

In previous chapters, I talked about purchasing a notebook and detailing your system configuration. This kind of information is especially important when you call a hardware vendor to help track down a conflict or when the software should work. You may never use most of this information. When you do need it, however, you save yourself a great deal of time by having it in front of you. This is also important when you post a message to a newsgroup and someone asks for the details of your configuration.

By knowing what product and what release you have before you call, you save yourself time when you do call. First, you don’t have to hunt through notes or manuals while the clock is ticking on your phone bill. Even if you can’t find the release, don’t guess or say “the latest.” Though you can get the release number from the installation media, this may not be exactly what was used to install. The best source is to run uname -a. This tells you exactly what release the system is currently running.

The problem with Linux is that there is no one “official” release. There are “official” releases of the kernel, but that doesn’t necessarily tell you everything about your system. If you purchase a complete Linux system (either just the software or with hardware), you should have some documentation that not only lists the kernel version but also that distributors version as well.

If you guess, the support technical might have to guess, too. This is important because fixes are almost always release-specific. If you say “the latest” and it isn’t and the “bug” you have was corrected in the latest release, the analyst is not going to give you the fix because he or she thinks you already have it. This wastes the analysts time, wastes your time, and in the end, you don’t get the correct solution. More than likely, if you guess and say “the latest” when posting to a newsgroup, you will get some “friendly” reminders that you should provide more specific details.

Should it be necessary to contact a support organization, at the very minimum, you should have the following information:

• Operating system(s) and versions
• Machine type: 486/DX 50, P6/133, etc.
• Make and model of all hardware (rarely is just the brand sufficient)
• Controller make, model, and type
• Symptoms of problem: noises, messages, previous problems
• An exact description of the error message you received and the context in which you received it
• Drive organization: partition sizes, special drivers
• Special devices/drivers, such as disk array hardware and software
• What the machine was doing when the problem occurred
• What the sequence of events was that preceded the problem
• Whether this problem has occurred more than once and if so, how often
• Whether you recently installed any device drivers or additional hardware
• What the last thing you changed was
• When you changed it
• Whether this a production machine and whether you are down now
• If this is related to a software product you have installed, what the exact version is
• What distribution of Linux your are running, whether and from where you downloaded it, copied it, or purchased it
• What version of the kernel you are running and what options you are using
• Whether any additional packages are not part of the standard distribution
• How urgent the problem really is

The last question is essential to getting you the service you need. If you are not clear to tech support about the urgency of the situation, you may end up waiting for the available support analyst or you might get the “try this and call back later answer.” By explaining the urgency to everyone you contact, you are likely to get your answer more quickly.

On the other hand, most tech support is based on an honor system. The support organizations with which I have dealt will believe you when you call in and say your system is down. (This was also the case when I worked in support.) Many customer service people are not in a position to judge the severity of the problem. However, the support analyst is. Saying that your company is down because you can’t figure out the syntax for a shell script is unfair to other people who have problems that are really more severe than yours. Simply turn the situation around when you are the one waiting for support on a system crash and someone else is tying up the lines because he or she can’t install a printer.

Once you have all the details about the problem, you are ready to call, right? Well, not yet. Before you actually start dialing, you must make every effort to track down the problem yourself. The first reason is pretty obvious. If you find it yourself, there is no need to call tech support.

This doesn’t apply as much to newsgroups, but you do save time by listing the things that you have tried. If there is no specific solution to your problem, other newsgroup readers will probably make suggestions. If you list what you have tried, no one will suggest doing something that you have already tried. Telling them what you have tried applies to tech support as well.

Many vendors have bulletin boards containing answers to commonly asked questions. There may even be a WWW page for the bulletin board to make access even easier. Unless your system won’t boot at all, this is usually a good place to look before you call support. Again, it’s an issue of time. It is generally much easier to get into a bulletin board than to a support engineer. You may have to spend a little time becoming familiar with the particular interface that this company uses, but once you have learned your way around, you can not only find answers to your questions, but you often find treasures such as additional programs that are not part of the base distribution. Even if you don’t find the solution, knowing that you did look on the bulletin board saves the support engineer a step. In addition, access a Web page or a bulletin board can keep you up-to-date on patch releases.

I mentioned that some companies have fax-back services. Often, answers to common questions are available this way. If you try the fax-back service, as well as newsgroups or on-line services like CompuServe, you have saved time if you need to call into support. Even if you don’t get the solution to your problem, you may have gotten some of the suggestions that the tech support representative would have given you. Because you already know that something doesn’t work, you have saved yourself the problem of getting a “try this and call back” answer.

From the tech support perspective, this is very helpful. First, there is the matter of saving time. If it takes 20 minutes just to get through the basic “sanity” checks, then that is 20 minutes that could have been used to service someone else. Why do you care if someone else gets help instead of you? Well, if you happen to be the one waiting to talk to the support representative, you want him or her to be done with the other customer as soon as possible to be able to get to you more quickly. The bottom line is that the more quickly they’re done with one customer, the quicker it is for everyone.

Make sure that any hardware you have added is supported before you call to support. If not, getting effective support is difficult at best. Tech support may have to guess at what the problem is and possibly give you erroneous information. In many cases, you may be referred to the hardware vendor and simply told they can’t help you. Not that they won’t try. The issue is usually that they don’t have any information about that product, so the best they can do is go from knowledge about similar products. If the product you want to use deviates from the norm, generic information is of little value.

If this is a software problem, make sure that the release you have is supported on this release of Linux. One common problem is that the software may be ELF, but your kernel only supports a.out, in which case, you have a problem.

If a piece of equipment is not “officially” supported, the support representative or people on the newsgroup may never have seen this before and may be unaware of quirks that it has. A printer may claim to be HP LaserJet-compatible, but the driver may send commands to the printer that the clone does not have. Many people will insist that this is a problem with the operating system. No one never claimed that the hardware was going to work. So, if the hardware vendor claims it is 100 percent compatible, it is up to them to prove it.

On the other hand, because of the nature of the job in tech support and the nature of people using Linux, the representatives probably have encountered hardware that is not officially supported. If they try to get it to work and they succeed, then they are in a position to try it the next time. If they have successfully installed something similar, then many of the same concepts and issues apply.

This same thing applies to software. Make sure the software is supported by the OS. It may be that the particular release of the application is only supported with a kernel after a particular release. In that case, neither the people on the newsgroup, the Linux distributor, nor the application vendor will be able to help. They know that it will not work. I remember one call into tech support in which the customer was having trouble with a version of our spreadsheet product that has been discontinued for more than two years. To make things more interesting, the customer was trying to get it to work not on our OS, but someone else’s.

Also try to determine whether it is really an operating system problem and not specific to just one application. If you call your Linux distributor with a problem in an application that you got somewhere else, make sure the problem also occurs outside of that application. For example, if you can print from the command line but can’t print from WordPerfect, it’s not an operating system problem. However, if the OS and WordPerfect both have trouble printing, then it is probably not an issue with WordPerfect. The reverse is also true.

If the problem is with the software and deals with configuration, make sure that all of the associated files are configured correctly. Don’t expect the distributor or the people on a newsgroup to check your spelling. I had one customer who had problems configuring his mail system. He spent several minutes ranting about how the manuals were wrong because he followed them exactly and it still didn’t work. Well, all the files were set up correctly except for that he had made something plural although the manual showed it as being singular.

Even after you have gathered all the information about your system and software, looked for conflicts and tried to track down the problem yourself, you are still not quite ready to call. Preparing for the call itself is another part of getting the answer you need.

One of the first questions you need to ask yourself is “Why am I calling tech support?” What do you expect? What kind of answer are you looking for? In most cases, the people answering the phones are not the people who wrote the code, although you will find them by subscribing to mailing lists. Due to the nature of Linux enthusiasts, many have spent hours digging through the source code, looking for answers or creating a patch. However, this is not the same as writing the SCSI hard disk driver. Therefore, they may not be in a position to tell you why the program behaves in a certain way, only how to correct it. Despite this, Linux users may have a better overall knowledge of the product than many of the developers because they deal with more diverse issues. Therefore, they may not be in a position to tell you why the program behaves the way it does, only how to correct it.

If you are contacting the support representatives via fax, e-mail, or any other “written” media, be sure that there are no typos. Especially when relating error messages, always make sure that you have written the text exactly as it appears. I have dealt with customers who have asked for help and the error message they report is half of one release and half of another. The change required is different depending on the release you are running. This is also important to know when calling. Telling the support representative that the message was “something like” may not do any good. If there are several possible errors, all with similar content, the exact phrasing of the message is important.

This is also a problem with two systems when one is having the problem and the other is not. It is not uncommon for a customer to describe the machines as “basically the same.” This kind of description has little value when the representatives are trying to track down a problem. I get annoyed with people who use the word “basically” when trying to describe a problem. I don’t want the basics of the problem, I want the details. Often customers will use it as a filler word. That is, they say “basically,” but still go into a lot of detail.

Many customers insist that the two systems are identical. If they were identical, then they both would be behaving the same way. The fact that one works and the other doesn’t indicates that the machines are not identical. By trying to determine where the machines differ, you narrow down the problem to the point at which tracking down the problem is much easier. You can even find the problem yourself, thus avoiding the call to support.

Once you get tech support on the phone, don’t have them read the manual to you. This is a waste of time for both you and the support representative, especially if you are paying for it. Keep in mind that although there may be no charge for the support itself, you may be calling a toll number. If this is during the normal business day (which it probably is), the call could still cost $20-$30. However, this also depends on your support contract. Many customers will pay tens of thousands of dollars a year for support so that they can have the manual read to them. They don’t have the time to go searching for the answer, so they pay someone else to do it for them. If you want a premium service, you have to pay a premium price.

The same applies to newsgroups. Don’t waste bandwidth by asking someone to give you the option to a command. RTFM! (Read The Friendly Manual) Every version I have seen comes with manual-pages, as well as dozens of documents detailing how to run your system.

If you do read the manual and your problem still does not work out the way you expect it to or you are having problems relating the doc to the software, ensure that the doc matches the SW. One customer was having trouble changing his system name. He said the documentation was worthless because the software did not work as it was described in the manual. It turned out that the doc he was using was for a release that was two years old, and he never got the latest doc! No wonder the doc did not match the software.

If you don’t know the answer to the question, tell the support representative “I don’t know.” Do not make up an answer. Above all, don’t lie outright. I had a customer who was having problems running some commands on his system. They were behaving in a manner I had never seen before, even on older releases. To track down the problem I had him check the release his was on. None of the normal tools and files were there. After poking around a while, I discovered that it was not our OS. When confronted with this, the customers response was that their contract for the other operating system had run out.

Getting information from some customers is like pulling teeth. They won’t give it up without a fight. To get the right answer, you must tell the analyst everything. Sometimes it may be too much, but it is much better to get too much than not enough.

When talking to support, have everything in front of you. Have your notebook open, the system running if possible, and be ready to run any command the support representative asks you. If you have a hardware problem, try to have everything else out of the machine that is not absolutely necessary to your issue. It is also helpful to try to reinstall the software before you call. Reinstalling is often useful and several companies seem to use this method as their primary solution to any problem. If you have done it before calling and the problem still persists, the tech support representative won’t get off with that easy answer. I am not professing this as the standard way of approaching things, though if you believe reinstalling would correct the problem and you have the opportunity, doing so either solves the problem or forces support to come up with a different solution.

Another common complaint is customers calling in and simply saying that a particular program doesn’t work right. Although this may be true, it doesn’t give much information to the technician. Depending on its complexity, a program may generate hundreds of different error messages, all of which have different causes and solutions. Regardless of what the cause really is, it is almost impossible for the technician to be able to determine the cause of the problem simply by hearing you say that the program doesn’t work.

A much more effective and successful method would be to simply state what program you were trying to use, then describe the way it behaved and how you expect that it should behave. You don’t even need to comment on it not working right. By describing the behavior, the technician will be able to determine one of three things. Either you have misunderstood the functionality of the program, you are using it incorrectly or there really is a bug in the program.

People who call into tech support very commonly have the attitude that they are the only customers in the world with a problem. Many have the attitude that all other work by the entire company (or at least, tech support) needs to stop until their problem is resolved. Most tech support organizations are on schedules. Some have phone shifts scattered throughout the day and can only work on “research” problems during specific times of the day. Other organizations have special groups of people whose responsibility it is to do such research. In any event, if the problem requires special hardware or a search through the source code, you may have to wait several hours or even days for your solution. For the individual, this may be rather annoying, but it does work out better for everyone in the long run.

The attitude that the analyst needs to stop what he or she is doing and work on this one customers problem becomes a major issue when problems are caused by unique circumstances. The software or hardware company may not have that exact combination of hardware available. Although the combination ought to work, no one that has not tested it can guarantee there will be no problems. As a result, the support representative may have to wait until he or she is not working on the phone to gather that combination of hardware. It may also happen that the representative must pass the problem to someone else who is responsible for problems of this type. As a result, the answer may not come for several hours, days, weeks, or even months, depending on the priority level of the contract.

In addition to the priority of the contract, there is also the urgency of the problem. If you have a situation in which data is disappearing from your hard disk, you will be given a higher priority than your contract would imply.

While I was working in support, I talked with many other support representatives. Often a customer would have a support contract with his or her vendor and the vendor would have the contract with us. The vendor would call us if they could not solve the problem. I had a chance to ask many of them some of the more common problems.

There are several common complaints among tech support representatives. Although it may seem obvious, many people who call in are not in front of their machines. Its possible that the solution is easy enough that the support representative can help even without you at the machine. However, I talked to a customer who had printer problems and wanted me to help him fix things while he was driving down the freeway talking on his car phone.

Another very common issue that support representatives bring up is customers who come off as thinking they know more than tech support. When they are given suggestions, their response is usually “That won’t work.” Maybe not. However, the behavior exhibited by the failure often does give an indication of where the problem lies. If you are going to take the time to call support, you must be willing to try everything that is suggested. You have to be receptive to the support representatives suggestion and willing to work with him or her. If necessary, you must be willing to start the problem from scratch and go over the “basics.” The customers who get the best response from tech support are usually those who remain calm and are willing to try whatever is suggested.

People have called computer manufacturers to be told how to install batteries in laptops. When the support representative explains how to do this and that the directions are on the first page of the manual, one person replied angrily, “I just paid $2,000 for this damn thing, and I’m not going to read a book.”

At first glance, this response sounds reasonable. A computer is a substantial investment and costs a fair bit of money. Why shouldn’t tech support tell you how to do something? Think about a car. A car costs more. So, after spending $20,000 for a new car, you’re not going to read the book to figure out how to start it? Imagine what the car dealer would say if you called in to ask how to start the car.

The computer industry is the only one that goes to this level to support its products. Sometimes you get very naïve customers. At least, they are naïve when it comes to computers. In attempting to solve a customers problem, it is often essential that tech support knows what release of the operating system the customer is using.

Some customers are missing some basic knowledge about computers. One customer was having trouble when we needed to know the release. Although he could boot, he was having so much trouble typing in basic commands, like uname. We told him to type uname then press Enter and it responded “dave: command not found.”

We then asked him to get the N1 floppy and read the release number off the floppy. He couldn’t find it. Not the floppy, the release number. So after 10 minutes of frustration, we decided to have him photocopy the floppy and fax it to us.

“Wow!” he said. “You can get information from the floppy that way?”

“Sure,” we said. “No problem.” (What’s so hard about reading a label?)

A few minutes later a fax arrived from this customer. It consisted of a single sheet of paper with a large black ring in the center of it. We immediately called him back and asked him what the fax was.

“Its the floppy,” he said. “Im still amazed that you can get information from the floppy like that. I must tell you, I had a heck of a time getting the floppy out of the case. After trying to get it out of that little hole, I had to take a pair of scissors to it.” (The case he mentioned was actually the plastic jacket.)

Many of us laugh at this because this is “common knowledge” in the computer industry. However, computers are the only piece of equipment about which the consumer is not expected to have common knowledge. If you drive a car, you are expected to know not to fill it with diesel when it takes regular gasoline. However, trying to load a DOS program onto an UNIX system is not expected knowledge.

One customer I had was having trouble installing a network card. The documentation was of little help to him because it was using a lot of “techno-babble” that most “normal” people couldn’t understand. The customer could not even answer the basic questions about how his hardware was configured. He insisted that it was our responsibility to know that because we wrote the operating system and he’s not a computer person. Well, I said that it’s like having a car that won’t start. You call the car dealership and tell them it won’t start. The service department asks you what model you have. You say that they should know that. They then ask if you have the key in the ignition. You say that you are not a “car person” and don’t know this technical stuff.

In the past few years, many software vendors have gone from giving away their support to charging for it. Support charges range anywhere from $25 a call for application software to $300 for operating systems like UNIX. As an end user, $300 can be a bit hard to swallow. However, in defense of the software industry, it really is not their fault. As more and more computers are being bought by people who have never used one, the number of calls to support organizations have gone up considerably. People treat computers differently than any other piece of equipment. Rather than reading the manual themselves, they much prefer to call support.

Would you ever call a car manufacturer to ask how to open the trunk? Would you ever call a refrigerator manufacturer to ask how to increase the temperature in the freezer? I hope not. However, computer tech support phones are often flooded with calls at this level, especially if their support is free or free for a specific warranty period.

The only way for a company to recover the cost of the support is either to include it with the cost of the product or to charge extra for it. The bottom line is that there is no such thing as a free lunch, nor is there free tech support. If you aren’t paying for the call itself, the company will have to recover the cost by increasing the sales price of the product. The result is still money out of your pocket. To make the situation fairest for everyone involved, companies are charging those people who use the tech support system.

I remember watching a television program a couple of years ago on air plane accidents and how safe planes really are. The technology exists today to decrease the number of accidents and near accidents almost to zero. Improvement to both airplane operations, air traffic control, and positioning could virtually eliminate accidents. However, this would result in increasing the cost of airline tickets by a factor of 10! People won’t pay that much for safety. The risk is too low.

The same thing applies to software. It is possible to write code that is bug-free. The professor who taught my software engineering class insisted that with the right kind of planning and testing, all bugs could be eliminated. The question is, “At what cost?” Are you willing to pay 10 times as much for your software just to make it bug-free? One support representative put it like this: “How can you ask us to hold up the entire product for an unknown length of time, to fix a single problem that affects few users and is not fatal? Would you expect Ford to ship their next years model of Escort three months late because they found out that the placement of the passenger door lock was inconvenient for people taller than 6’9″?” As ridiculous as this seems, calls reporting bugs are often at this level.

Because of the nature of Linux and software in general, it is going to be released with bugs in it. Although no one organization is responsible for it, Linux has as good a track record as any commercial OS. One key difference is that you don’t have a huge bureaucracy causing Linux 96 to come out in 98. New versions of the kernel come out every few months and it is literally only a matter of days for patches to appear when bugs are detected.

After years of tech support, I am convinced that the statement “The customer is always right” was not coined by some businessman trying to install a customer service attitude in his employees. It must have been an irate user of some product who didn’t bother to read the manual, tried to use the product in some unique way, or just generally messed things up. When this user couldn’t figure out how to use whatever he or she bought, he or she decided it was the fault of the vendor and called support.

You as the customer are not always right. Granted, it is the responsibility of the company to ensure that you are satisfied. This job usually falls on the shoulders of tech support because they are usually the only human contact customers have with hardware and software vendors. However, by expecting tech support to pull you out of every hole you dig yourself into or coming across representatives as a “know-it-all” or “I-am-right,” you run the risk of not getting your question answered. Isn’t that the reason for calling support in the first place?