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
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
- Controller make, model, and type
- Symptoms of problem: noises, messages,
- 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
- 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
- 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
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
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
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
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
"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
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
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
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