{"id":340,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:25:59","modified_gmt":"2020-08-22T20:25:59","slug":"this-is-the-page-title-toplevel-173","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=340","title":{"rendered":"Calling Support"},"content":{"rendered":"\nCalling Support<\/title>\n<p>\nThe most commonly known source of help is the company’s tech support\ndepartment. With Linux, however, there is no one to call. At least, there is no\none single company or organization to call. If you bought Linux as part of a\ncomplete system or from an established distributor, they will probably be able\nto help you. Many have free e-mail support for those who can’t afford the phone\nsupport. Many also will charge you a certain amount per minute or a flat fee per\ncall. However, even if you are left with other sources, such as USENET\nnewsgroups or the mailing lists, going through “tech support” has the same basic\nprinciples, so I will <glossary>address<\/glossary> this as though you were\ngetting help directly from the company.\n<\/p>\n<p>\nTech support is like any system. You put garbage in and you’re likely to get\ngarbage out. Calling in and demanding immediate results or blaming the support\nrepresentative for the problem will probably get you one of a few responses.\nThey’ll tell you that it’s a hardware problem if you’ve called a software\ncompany, a software problem if you’ve called a hardware company, or they’ll say\nthere is “something” else on the machine conflicting with their product, but\nit’s your job to figure it out. You may even get an answer that, yes, that board\nis bad, and you can return it to the place of purchase to get a refund or\nexchange. In other words, they blow you off.\n<\/p>\n<p>\nIf the board was bad, getting a replacement solves the problem. If there is a\nconflict, however, you will probably spend even more time trying to track it\ndown. If the problem is caused by some program problem (conflicts or whatever),\nreinstalling may not fix the problem.\n<\/p>\n<p>\nRather than spending hours trying to track down the conflict or swapping\nout boards, you decide to call tech support. The question is, “Which one?” If\nthere is only one program or one board, it’s pretty obvious which tech support\ndepartment to call. If the problem starts immediately after you add a board or\nsoftware package, the odds are that this has something to do with whatever you\njust installed. If, however, the problem starts after you’ve been running for a\nwhile, tracking down the offender is not that easy. Thats why you’re going to\ncall tech support, right? So grab that phone and start dialing.\n<\/p>\n<p>\nStop! Put that phone down! You’re not ready to call yet. There’s something\nyou need to do first. In fact, you need to do several things before you\ncall.\n<\/p>\n<p>\nCalling tech support is not as easy as picking up the phone and dialing. Many\npeople who are having trouble with their systems tend to think that it is. In\nmany cases, this is true. The problem is basic enough that the tech support\nrepresentative can answer it within a few minutes. However, if it’s not, your\nlack of preparation can turn a two-minute call into a two-hour call.\n<\/p>\n<p>\nPreparation for calling tech support begins long before that first phone call\nor the first news post. In fact, preparation actually begins before you install\nanything on your system. I mean <i>anything<\/i> before you install your first\nprogram, before you make the change to .profile to change your prompt, even\nbefore you install the <glossary>operating system<\/glossary>.\n<\/p>\n<p>\nIn previous chapters, I talked about purchasing a notebook and detailing your\nsystem configuration. This kind of information is especially important when you\ncall a hardware vendor to help track down a conflict or when the software\n<i>should <\/i>work. You may never use most of this information. When you do need\nit, however, you save yourself a great deal of time by having it in front of\nyou. This is also important when you post a message to a newsgroup and someone\nasks for the details of your configuration.\n<\/p>\n<p>\nBy knowing what product and what release you have before you call, you save\nyourself time when you do call. First, you don’t have to hunt through notes or\nmanuals while the clock is ticking on your phone bill. Even if you can’t find the\nrelease, don’t guess or say “the latest.” Though you can get the release number\nfrom the installation media, this may not be exactly what was used to install.\nThe best source is to run uname -a. This tells you exactly what release the\nsystem is currently running.\n<\/p>\n<p>\nThe problem with Linux is that there is no one “official” release. There are\n“official” releases of the <glossary>kernel<\/glossary>, but that doesn’t\nnecessarily tell you everything about your system. If you purchase a complete\nLinux system (either just the software or with hardware), you should have some\ndocumentation that not only lists the kernel version but also that distributors\nversion as well.\n<\/p>\n<p>\nIf you guess, the support technical might have to guess, too. This is\nimportant because fixes are almost always release-specific. If you say “the\nlatest” and it isn’t and the “bug” you have was corrected in the latest release,\nthe analyst is not going to give you the fix because he or she thinks you\nalready have it. This wastes the analysts time, wastes your time, and in the\nend, you don’t get the correct solution. More than likely, if you guess and say\n“the latest” when posting to a newsgroup, you will get some “friendly” reminders\nthat you should provide more specific details.\n<\/p>\n<p>\nShould it be necessary to contact a support organization, at the very\nminimum, you should have the following information:<\/p><ul>\n<li>Operating system(s) and versions\n<li>Machine type: 486\/DX\n50, P6\/133, etc.\n<li>Make and model of all hardware (rarely is just the brand\nsufficient)\n<li>Controller make, model, and type\n<li>Symptoms of problem: noises, messages,\nprevious problems\n<li>An <i>exact<\/i> description of the <glossary>error message<\/glossary> you\nreceived and the context in which you received it\n<li>Drive organization:\n<glossary>partition<\/glossary> sizes, special drivers\n<li>Special devices\/drivers, such as disk\narray hardware and software\n<li>What the machine was doing when the problem\noccurred\n<li>What the sequence of events was that preceded the problem\n<li>Whether this\nproblem has occurred more than once and if so, how often\n<li>Whether you recently installed any device drivers or additional hardware\n<li>What the last thing you changed was\n<li>When you changed it\n<li>Whether this a production machine and whether you are down now\n<li>If this is related to a software product you have installed, what the exact\nversion is\n<li>What distribution of Linux your are running, whether and from\nwhere you downloaded it, copied it, or purchased it\n<li>What version of the kernel you are running and what options you are using\n<li>Whether any additional packages are not part of the standard distribution\n<li>How urgent the problem <i>really<\/i> is\n<\/ul>\n<p>\nThe last question is essential to getting you the service you need. If you\nare not clear to tech support about the urgency of the situation, you may end\nup waiting for the available support analyst or you might get the “try this and\ncall back later answer.” By explaining the urgency to everyone you contact, you\nare likely to get your answer more quickly.\n<\/p>\n<p>\nOn the other hand, most tech support is based on an honor system. The support\norganizations with which I have dealt will believe you when you call in and say\nyour system is down. (This was also the case when I worked in support.) Many\ncustomer service people are not in a position to judge the severity of the\nproblem. However, the support analyst is. Saying that your company is down\nbecause you can’t figure out the syntax for a shell script is unfair to other\npeople who have problems that are really more severe than yours. Simply turn the\nsituation around when you are the one waiting for support on a system\n<glossary>crash<\/glossary> and someone else is tying up the lines because he or\nshe can’t install a printer.\n<\/p>\n<p>\nOnce you have all the details about the problem, you are ready to call,\nright? Well, not yet. Before you actually start dialing, you must make every\neffort to track down the problem yourself. The first reason is pretty obvious.\nIf you find it yourself, there is no need to call tech support.\n<\/p>\n<p>\nThis doesn’t apply as much to newsgroups, but you do save time by listing the\nthings that you have tried. If there is no specific solution to your problem,\nother newsgroup readers will probably make suggestions. If you list what you\nhave tried, no one will suggest doing something that you have already tried.\nTelling them what you have tried applies to tech support as well.\n<\/p>\n<p>\nMany vendors have bulletin boards containing answers to commonly asked\nquestions. There may even be a <glossary>WWW<\/glossary> page for the bulletin\nboard to make access even easier. Unless your system won’t\n<glossary>boot<\/glossary> at all, this is usually a good place to look before\nyou call support. Again, it’s an issue of time. It is generally much easier to\nget into a bulletin board than to a support engineer. You may have to spend a\nlittle time becoming familiar with the particular interface that this company\nuses, but once you have learned your way around, you can not only find answers\nto your questions, but you often find treasures such as additional programs that\nare not part of the base distribution. Even if you don’t find the solution,\nknowing that you did look on the bulletin board saves the support engineer a\nstep. In addition, access a Web page or a bulletin board can keep you up-to-date\non patch releases.\n<\/p>\n<p>\nI mentioned that some companies have fax-back services. Often, answers to\ncommon questions are available this way. If you try the fax-back service, as\nwell as newsgroups or on-line services like CompuServe, you have saved time if\nyou need to call into support. Even if you don’t get the solution to your\nproblem, you may have gotten some of the suggestions that the tech support\nrepresentative would have given you. Because you already know that something\ndoesn’t work, you have saved yourself the problem of getting a “try this and\ncall back” answer.\n<\/p>\n<p>\nFrom the tech support perspective, this is very helpful. First, there is the\nmatter of saving time. If it takes 20 minutes just to get through the basic\n“sanity” checks, then that is 20 minutes that could have been used to service\nsomeone else. Why do you care if someone else gets help instead of you? Well, if\nyou happen to be the one waiting to talk to the support representative, you want\nhim or her to be done with the other customer as soon as possible to be able to\nget to you more quickly. The bottom line is that the more quickly they’re done\nwith one customer, the quicker it is for everyone.\n<\/p>\n<p>\nMake sure that any hardware you have added is supported before you call to\nsupport. If not, getting effective support is difficult at best. Tech support\nmay have to guess at what the problem is and possibly give you erroneous\ninformation. In many cases, you may be referred to the hardware vendor and\nsimply told they can’t help you. Not that they won’t try. The issue is usually\nthat they don’t have any information about that product, so the best they can do\nis go from knowledge about similar products. If the product you want to use\ndeviates from the norm, generic information is of little value.\n<\/p>\n<p>\nIf this is a software problem, make sure that the release you have is\nsupported on this release of Linux. One common problem is that the software\nmay be <glossary>ELF<\/glossary>, but your kernel only supports a.out, in which\ncase, you have a problem.\n<\/p>\n<p>\nIf a piece of equipment is not “officially” supported, the support\nrepresentative or people on the newsgroup may never have seen this before and\nmay be unaware of quirks that it has. A printer may claim to be HP\nLaserJet-compatible, but the driver may send commands to the printer that the\nclone does not have. Many people will insist that this is a problem with the\noperating system. No one never claimed that the hardware was going to work. So,\nif the hardware vendor claims it is 100 percent compatible, it is up to them to\nprove it.\n<\/p>\n<p>\nOn the other hand, because of the nature of the job in tech support and the\nnature of people using Linux, the representatives probably have encountered\nhardware that is not officially supported. If they try to get it to work and\nthey succeed, then they are in a position to try it the next time. If they have\nsuccessfully installed something similar, then many of the same concepts and\nissues apply.\n<\/p>\n<p>\nThis same thing applies to software. Make sure the software is supported by\nthe OS. It may be that the particular release of the\n<glossary>application<\/glossary> is only supported with a kernel after a\nparticular release. In that case, neither the people on the newsgroup, the Linux\ndistributor, nor the application vendor will be able to help. They know that it\nwill not work. I remember one call into tech support in which the customer was\nhaving trouble with a version of our spreadsheet product that has been\ndiscontinued for more than two years. To make things more interesting, the\ncustomer was trying to get it to work not on our OS, but someone else’s.\n<\/p>\n<p>\nAlso try to determine whether it is really an operating system problem and\nnot specific to just one application. If you call your Linux distributor with\na problem in an application that you got somewhere else, make sure the problem\nalso occurs outside of that application. For example, if you can print from the\n<glossary>command line<\/glossary> but can’t print from WordPerfect, it’s not an\noperating system problem. However, if the OS and WordPerfect both have trouble\nprinting, then it is probably not an issue with WordPerfect. The reverse is also\ntrue.\n<\/p>\n<p>\nIf the problem is with the software and deals with configuration, make\nsure that all of the associated files are configured correctly. Don’t expect\nthe distributor or the people on a newsgroup to check your spelling. I had one\ncustomer who had problems configuring his mail system. He spent several minutes\nranting about how the manuals were wrong because he followed them\n<em>exactly<\/em> and it still didn’t work. Well, all the files were set up\ncorrectly except for that he had made something plural although the manual showed\nit as being singular.\n<\/p>\n<p>\nEven after you have gathered all the information about your system and\nsoftware, looked for conflicts and tried to track down the problem yourself,\nyou are still not quite ready to call. Preparing for the call itself is another\npart of getting the answer you need.\n<\/p>\n<p>\nOne of the first questions you need to ask yourself is “Why am I calling tech\nsupport?” What do you expect? What kind of answer are you looking for? In most\ncases, the people answering the phones are not the people who wrote the code,\nalthough you will find them by subscribing to mailing lists. Due to the nature\nof Linux enthusiasts, many <i>have <\/i>spent hours digging through the source\ncode, looking for answers or creating a patch. However, this is not the same as\nwriting the <glossary>SCSI<\/glossary> hard disk driver. Therefore, they may not\nbe in a position to tell you why the program behaves in a certain way, only how\nto correct it. Despite this, Linux users may have a better overall knowledge of\nthe product than many of the developers because they deal with more diverse\nissues. Therefore, they may not be in a position to tell you why the program\nbehaves the way it does, only how to correct it.\n<\/p>\n<p>\nIf you are contacting the support representatives via fax, e-mail, or any\nother “written” media, be sure that there are no typos. Especially when\nrelating error messages, always make sure that you have written the\ntext <em>exactly<\/em> as it appears. I have dealt with\ncustomers who have asked for help and the error message they report is half of\none release and half of another. The change required is different depending on\nthe release you are running. This is also important to know when calling. Telling\nthe support representative that the message was “something like” may not do any\ngood. If there are several possible errors, all with similar content, the exact\nphrasing of the message is important.\n<\/p>\n<p>\nThis is also a problem with two systems when one is having the problem and\nthe other is not. It is not uncommon for a customer to describe the machines\nas “basically the same.” This kind of description has little value when the\nrepresentatives are trying to track down a problem. I get annoyed with people who\nuse the word “basically” when trying to describe a problem. I don’t want the basics of the\nproblem, I want the details. Often customers will use it as a filler word. That\nis, they say “basically,” but still go into a lot of detail.\n<\/p>\n<p>\nMany customers insist that the two systems are identical. If they were\n<i>identical<\/i>, then they both would be behaving the same way. The fact that\none works and the other doesn’t indicates that the machines are <i>not\n<\/i>identical. By trying to determine where the machines differ, you narrow down\nthe problem to the point at which tracking down the problem is much easier. You\ncan even find the problem yourself, thus avoiding the call to support.\n<\/p>\n<p>\nOnce you get tech support on the phone, don’t have them read the manual to\nyou. This is a waste of time for both you and the support representative,\nespecially if you are paying for it. Keep in mind that although there may be no\ncharge for the support itself, you may be calling a toll number. If this is\nduring the normal business day (which it probably is), the call could still cost\n$20-$30. However, this also depends on your support contract. Many customers will\npay tens of thousands of dollars a year for support so that they can have the\nmanual read to them. They don’t have the time to go searching for the answer, so\nthey pay someone else to do it for them. If you want a premium service, you have\nto pay a premium price.\n<\/p>\n<p>\nThe same applies to newsgroups. Don’t waste <glossary>bandwidth<\/glossary>\nby asking someone to give you the option to a command. RTFM! (Read The Friendly\nManual) Every version I have seen comes with manual-pages, as well as dozens of\ndocuments detailing how to run your system.\n<\/p>\n<p>\nIf you do read the manual and your problem still does not work out the way\nyou expect it to or you are having problems relating the doc to the software,\nensure that the doc matches the SW. One customer was having trouble changing his\nsystem name. He said the documentation was worthless because the software did\nnot work as it was described in the manual. It turned out that the doc he was\nusing was for a release that was two years old, and he never got the latest doc!\nNo wonder the doc did not match the software.\n<\/p>\n<p>\nIf you don’t know the answer to the question, tell the support representative\n“I don’t know.” Do not make up an answer. Above all, don’t lie outright. I had\na customer who was having problems running some commands on his system. They\nwere behaving in a manner I had never seen before, even on older releases. To\ntrack down the problem I had him check the release his was on. None of the\nnormal tools and files were there. After poking around a while, I discovered\nthat it was not our OS. When confronted with this, the customers response was\nthat their contract for the other operating system had run out.\n<\/p>\n<p>\nGetting information from some customers is like pulling teeth. They won’t\ngive it up without a fight. To get the right answer, you must tell the analyst\neverything. Sometimes it may be too much, but it is much better to get too much\nthan not enough.\n<\/p>\n<p>\nWhen talking to support, have everything in front of you. Have your notebook\nopen, the system running if possible, and be ready to run any command the\nsupport representative asks you. If you have a hardware problem, try to have\neverything else out of the machine that is not absolutely necessary to your\nissue. It is also helpful to try to reinstall the software before you call.\nReinstalling is often useful and several companies seem to use this method as\ntheir primary solution to any problem. If you have done it before calling and\nthe problem still persists, the tech support representative won’t get off with\nthat easy answer. I am not professing this as the standard way of approaching\nthings, though if you believe reinstalling would correct the problem and you\nhave the opportunity, doing so either solves the problem or forces support to\ncome up with a different solution.\n<\/p>\n<p>\nAnother common complaint is customers calling in and simply saying that a\nparticular program doesn’t work right. Although this may be true, it doesn’t\ngive much information to the technician. Depending on its complexity, a program\nmay generate hundreds of different error messages, all of which have different\ncauses and solutions. Regardless of what the cause really is, it is almost\nimpossible for the technician to be able to determine the cause of the problem\nsimply by hearing you say that the program doesn’t work.\n<\/p>\n<p>\nA much more effective and successful method would be to simply state what\nprogram you were trying to use, then describe the way it behaved and how you\nexpect that it should behave. You don’t even need to comment on it not working\nright. By describing the behavior, the technician will be able to determine one\nof three things. Either you have misunderstood the functionality of the program,\nyou are using it incorrectly or there really is a bug in the program.\n<\/p>\n<p>\nPeople who call into tech support very commonly have the attitude that they\nare the only customers in the world with a problem. Many have the attitude that\nall other work by the entire company (or at least, tech support) needs to stop\nuntil their problem is resolved. Most tech support organizations are on\nschedules. Some have phone shifts scattered throughout the day and can only work\non “research” problems during specific times of the day. Other organizations\nhave special groups of people whose responsibility it is to do such research. In\nany event, if the problem requires special hardware or a\nsearch through the source code, you may have to wait several hours or even days\nfor your solution. For the individual, this may be rather annoying, but it does\nwork out better for everyone in the long run.\n<\/p>\n<p>\nThe attitude that the analyst needs to stop what he or she is doing and work\non this one customers problem becomes a major issue when problems are caused by\nunique circumstances. The software or hardware company may not have that exact\ncombination of hardware available. Although the combination ought to work, no\none that has not tested it can guarantee there will be no problems. As a result,\nthe support representative may have to wait until he or she is not working on\nthe phone to gather that combination of hardware. It may also happen that the\nrepresentative must pass the problem to someone else who is responsible for\nproblems of this type. As a result, the answer may not come for several hours,\ndays, weeks, or even <em>months<\/em>, depending on the priority level of\nthe contract.\n<\/p>\n<p>\nIn addition to the priority of the contract, there is also the urgency of the\nproblem. If you have a situation in which data is disappearing from your hard\ndisk, you will be given a higher priority than your contract would imply.\n<\/p>\n<p>\nWhile I was working in support, I talked with many other support\nrepresentatives. Often a customer would have a support contract with his or\nher vendor and the vendor would have the contract with us. The vendor would call\nus if they could not solve the problem. I had a chance to ask many of them some\nof the more common problems.\n<\/p>\n<p>\nThere are several common complaints among tech support representatives.\nAlthough it may seem obvious, many people who call in are not in front of\ntheir machines. Its possible that the solution is easy enough that the support\nrepresentative can help even without you at the machine. However, I talked to a\ncustomer who had printer problems and wanted me to help him fix things while he\nwas driving down the freeway talking on his car phone.\n<\/p>\n<p>\nAnother very common issue that support representatives bring up is customers\nwho come off as thinking they know more than tech support. When they are given\nsuggestions, their response is usually “That won’t work.” Maybe not. However,\nthe behavior exhibited by the failure often does give an indication of where the\nproblem lies. If you are going to take the time to call support, you must be\nwilling to try everything that is suggested. You have to be receptive to the\nsupport representatives suggestion and willing to work with him or her. If\nnecessary, you must be willing to start the problem from scratch and go over the\n“basics.” The customers who get the best response from tech support are usually\nthose who remain calm and are willing to try whatever is suggested.\n<\/p>\n<p>\nPeople have called computer manufacturers to be told how to install batteries\nin laptops. When the support representative explains how to do this and that\nthe directions are on the first page of the manual, one person replied angrily,\n“I just paid $2,000 for this damn thing, and I’m not going to read a book.”\n<\/p>\n<p>\nAt first glance, this response sounds reasonable. A computer is a substantial\ninvestment and costs a fair bit of money. Why shouldn’t tech support tell you\nhow to do something? Think about a car. A car costs more. So, after spending\n$20,000 for a new car, you’re not going to read the book to figure out how to\nstart it? Imagine what the car dealer would say if you called in to ask how to\nstart the car.\n<\/p>\n<p>\nThe computer industry is the only one that goes to this level to support its\nproducts. Sometimes you get very naïve customers. At least, they are\nnaïve when it comes to computers. In attempting to solve a customers\nproblem, it is often essential that tech support knows what release of the\noperating system the customer is using.\n<\/p>\n<p>\nSome customers are missing some basic knowledge about computers. One customer\nwas having trouble when we needed to know the release. Although he could boot,\nhe was having so much trouble typing in basic commands, like uname. We told him\nto type uname then press Enter and it responded “dave: command not found.”\n<\/p>\n<p>\nWe then asked him to get the N1 floppy and read the release number off the\nfloppy. He couldn’t find it. Not the floppy, the release number. So after 10\nminutes of frustration, we decided to have him photocopy the floppy and fax it\nto us.\n<\/p>\n<p>\n“Wow!” he said. “You can get information from the floppy that way?”<\/p>\n<p>\n“Sure,” we said. “No problem.” (What’s so hard about reading a label?)<\/p>\n<p>\nA few minutes later a fax arrived from this customer. It consisted of a\nsingle sheet of paper with a large black ring in the center of it. We\nimmediately called him back and asked him what the fax was.\n<\/p>\n<p>\n“Its the floppy,” he said. “Im still amazed that you can get information from\nthe floppy like that. I must tell you, I had a heck of a time getting the\nfloppy out of the case. After trying to get it out of that little hole, I had to\ntake a pair of scissors to it.” (The case he mentioned was actually the plastic\njacket.)\n<\/p>\n<p>\nMany of us laugh at this because this is “common knowledge” in the computer\nindustry. However, computers are the only piece of equipment about which the\nconsumer is not expected to have common knowledge. If you drive a car, you are\nexpected to know not to fill it with diesel when it takes regular gasoline.\nHowever, trying to load a <glossary>DOS<\/glossary> program onto an\n<glossary>UNIX<\/glossary> system is not expected knowledge.\n<\/p>\n<p>\nOne customer I had was having trouble installing a <glossary>network<\/glossary>\ncard. The documentation was of little help to him because it was using a lot of\n“techno-babble” that most “normal” people couldn’t understand. The customer\ncould not even answer the basic questions about how his hardware was configured.\nHe insisted that it was our responsibility to know that because we wrote the\noperating system and he’s not a computer person. Well, I said that it’s like\nhaving a car that won’t start. You call the car dealership and tell them it\nwon’t start. The service department asks you what model you have. You say that\nthey should know that. They then ask if you have the key in the ignition. You\nsay that you are not a “car person” and don’t know this technical stuff.\n<\/p>\n<p>\nIn the past few years, many software vendors have gone from giving away their\nsupport to charging for it. Support charges range anywhere from $25 a call for\napplication software to $300 for operating systems like UNIX. As an end user,\n$300 can be a bit hard to swallow. However, in defense of the software industry,\nit really is not their <glossary>fault<\/glossary>. As more and more computers\nare being bought by people who have never used one, the number of calls to\nsupport organizations have gone up considerably. People treat computers\ndifferently than any other piece of equipment. Rather than reading the manual\nthemselves, they much prefer to call support.\n<\/p>\n<p>\nWould you ever call a car manufacturer to ask how to open the trunk? Would\nyou ever call a refrigerator manufacturer to ask how to increase the\ntemperature in the freezer? I hope not. However, computer tech support phones\nare often flooded with calls at this level, especially if their support is free\nor free for a specific warranty period.\n<\/p>\n<p>\nThe only way for a company to recover the cost of the support is either to\ninclude it with the cost of the product or to charge extra for it. The bottom\nline is that there is no such thing as a free lunch, nor is there free tech\nsupport. If you aren’t paying for the call itself, the company will have to\nrecover the cost by increasing the sales price of the product. The result is\nstill money out of your pocket. To make the situation fairest for everyone\ninvolved, companies are charging those people who use the tech support\nsystem.\n<\/p>\n<p>\nI remember watching a television program a couple of years ago on air plane\naccidents and how safe planes really are. The technology exists today to\ndecrease the number of accidents and near accidents almost to zero. Improvement\nto both airplane operations, air traffic control, and positioning could\nvirtually eliminate accidents. However, this would result in increasing the cost\nof airline tickets by a factor of 10! People won’t pay that much for safety. The\nrisk is too low.\n<\/p>\n<p>\nThe same thing applies to software. It is possible to write code that is\nbug-free. The professor who taught my software engineering\n<glossary>class<\/glossary> insisted that with the right kind of planning and\ntesting, all bugs could be eliminated. The question is, “At what cost?” Are you\nwilling to pay 10 times as much for your software just to make it bug-free? One\nsupport representative put it like this: “How can you ask us to hold up the\nentire product for an unknown length of time, to fix a single problem that\naffects few users and is not fatal? Would you expect Ford to ship their next\nyears model of Escort three months late because they found out that the\nplacement of the passenger door lock was inconvenient for people taller than\n6’9″?” As ridiculous as this seems, calls reporting bugs are often at this\nlevel.\n<\/p>\n<p>\nBecause of the nature of Linux and software in general, it is going to be\nreleased with bugs in it. Although no one organization is responsible for it,\nLinux has as good a track record as any commercial OS. One key difference is\nthat you don’t have a huge bureaucracy causing Linux 96 to come out in 98. New\nversions of the kernel come out every few months and it is literally only a\nmatter of days for patches to appear when bugs are detected.\n<\/p>\n<p>\nAfter years of tech support, I am convinced that the statement “The customer\nis always right” was not coined by some businessman trying to install a customer\nservice attitude in his employees. It must have been an irate user of some\nproduct who didn’t bother to read the manual, tried to use the product in some\nunique way, or just generally messed things up. When this user couldn’t figure\nout how to use whatever he or she bought, he or she decided it was the fault of\nthe vendor and called support.\n<\/p>\n<p>\nYou as the customer are not always right. Granted, it is the responsibility\nof the company to ensure that you are satisfied. This job usually falls on the\nshoulders of tech support because they are usually the only human contact\ncustomers have with hardware and software vendors. However, by expecting tech\nsupport to pull you out of every hole you dig yourself into or coming across\nrepresentatives as a “know-it-all” or “I-am-right,” you run the risk of not\ngetting your question answered. Isn’t that the reason for calling support in the\nfirst place?\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Calling Support 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 … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=340\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-340","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/340","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=340"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/340\/revisions"}],"predecessor-version":[{"id":515,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/340\/revisions\/515"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=340"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}