Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
There is less than 12 hours left to vote in the 2015 LinuxQuestions.org Members Choice Awards. Click here to go to the polls. Vote now and make sure your voice is heard!
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
By Simon Bridge at 2010-06-13 07:25
How to answer a Linux question.
After you've been asking questions and getting answers for a while, you will start to feel the need to put something back. However, deliberately setting out to answer questions can be daunting.
Don't be put off
So you are not a guru or anything - never mind. We all had to start some-place. Dive right in. You can start by answering to the newbie forums, or those that apply to your distro. Non-gurus can often answer installation questions and usually have more patience with and understanding of the newbies than the gurus will. So you are a vital resource: freeing up the experienced members for the really hard questions.
On the other hand, chances are you have some experience with troubleshooting by now. This is a general skill which needs to be practised or it goes stale. you can practice by applying your skills to problems you don't know about. You have experience making searches that newbies often lack - go use them. You will be amazed what else you will learn.
The thread lists have a useful feature - if you mouse-over the titles, you get a preview of the contents. This is useful for making sure a question is really you.
Do what you can.
If you are serious about deliberately seeking questions to answer, then you need to put time aside. If it is just a quickie bit of exercise, then do not worry about missing some questions - just take the low hanging fruit. Members answer questions for all sorts of reasons and in all sorts of situations. We understand.
Don't have an answer but:
You may be sure you can help, but not right now, or you want to wait a bit to see what other answers crop up. You may even find the question interesting and you want to know the answer yourself. So - subscribe to the thread without posting. (Thread Tools > Subscribe)
Zero Reply Threads
There is a slight issue with a zero reply (ZR) thread, that the second it is answered, it stops being a ZR. So there will be some anxiety that the OP will miss out on someone with a better answer. OTOH: if you don't reply, it may be that nobody will - maybe everyone who looks at it today comes to the same conclusion.
The answer here is to read the question anyway, not just the preview. Open a search page in another tab - and look to see if there really is anyone with a better answer. If there is, then it has almost-certainly been given before.
If you find one quickly, post a link to the solution.
If you don't, then give your reply.
If you are uncertain - err on the side of posting a reply. You don't really need to worry about giving the best possible answer. Besides, the first reply is usually just to ask a load of questions about the question - in which case, at worst, you are saving the next person some time.
It is acceptable to avoid the bad titles you see in ZR threads. There is a type of person who is drawn to these ones, so they will get answered.
If you are new to giving answers, these can be instructive, and you'll be saving someone else the bother. Mouse-over the title to see if they put something helpful in the first paragraph.
If you are not first to reply, read the other replies before you comment on how bad the title was.
Replying to your own threads
Practice what you preach.
Many boards seem to push newly replied threads back to the top of the stack, encouraging people to post "bump" or something else to their own thread. LQ automatically "bump"s ZR threads after a few days. Replying to it only removes you from this process.
Do not make the first reply to your own thread - unless you have found the answer before anyone else.
In which case: do not erase your original question - no matter how stupid you feel. Instead, mark the post "[solved]" (thread tools top right of post #1) and reply to your own question as if you were replying to someone else's.
This is related to thinking about the wider issues (below) - some other poor sod could Google to your thread: don't leave them in the same hole you just crawled out from.
Anyway: being prepared to look stupid in order to help others will earn you more respect in the long run.
However - it is all right to post a solution right off. This happens when you figure out the answer before you post, and you have not found another question to use the answer on.
Read the other answers
If you are not first, read what has gone before to see if your answer has already been included. This can be tough for very long threads. If OP seems to ignoring a particular answer, point it out and ask them what was wrong with it. Especially, check to see if anyone else has posted a rebuke before you do.
Consider the wider issues too
... when you are being paid to provide support, there is a financial pressure on you to provide solutions of the sort the user wants and expects. In LQ, all your support is gratis. This means that you are in a position to provide answers that the OP needs instead.
Very often, OP wants to do something that is better achieved another way. They may even hide information from you to avoid you telling them something they don't want to hear. Learn to recognize the signs, and listen around the question. Tailor your responses to those which will best help both the questioner and the community.
Assumption of Intelligence
Many posts look moronic - no matter how thick you secretly believe the OP, keep it that way: a secret. Treat the OP as a friend who happens to have missed a vital bit of information.
It is a tricky balance, though, and it is far better to be understood than clever. If anyone complains that you are talking down to them, step up your game but remind them that they are not the only ones who have to understand your reply. If they complain that you are too hard to understand, adjust and apologise. You'll soon pick it up.
There is a myth in LQ that we do not answer homework questions - this is not correct. We just provide a different kind of answer. If you suspect a homework question, then put in your reply "looks like homework to me" - even if it actually isn't, someone asking a homework-style question will probably still benefit from the homework-style of reply (next). So you can afford to err on the side of suspecting homework.
(Spot the diplomacy: you are only saying that it looks like homework so you are not accusing anyone of cheating. This goes with the assumption of intelligence (above).)
How to tutor someone in gnu/Linux is outside the scope of this howto - there is a lot of documentation and research on 1-1 teaching techniques if you want to get really good at this. The basic method is as follows:
Think about the process you use to discover the answer to this type of question yourself, then attempt to guide, patiently, the poster through those steps.
This is a special type of teaching called "guided inquiry". It is part of an overall skill-set usually called "information literacy" (IL).
In NZ it takes a 4-year university course + 1 year probation, to become a teacher - similar in other countries - and even then you could be better. Don't sweat it if you are only a so-so tutor.
Ask questions in reply
It is very unusual that a user will tell you everything you need to know to be sure of figuring out what is wrong. Try not to guess what may be wrong. Ask about error messages, what do they say exactly? Ask for common info not given, even if you suspect it is not needed - it is good for the user to get in the habit of supplying it anyway.
Use the search function
You search LQ and Google for answers because OP probably hasn't - or has yet to acquire your level of skill with it (IL). When you find them, post the link.
Pay attention to post flow
When you reply, it will not always be clear which post you are replying to - or which part. Even if you are the first responder, another member may beat you with a shorter post. You can easily establish the context of your answer by quoting part of the question.
Bear in mind that the first part of your answer will be emailed to everyone subscribed to the thread - so put an important part of the answer at the top.
Answer from a position of advocacy Linuxmanship has a great set of guidelines including how to answer questions in a way which also highlights the power of gnu/Linux and free software.
In addition, since this is text, try to add the rational behind the solution. People who want to listen to their music or watch DVDs usually do not understand why they often have to install additional codecs - they will see this as "inferior". There are many situations where something the user has been trained to think of as a "useful feature" is actually not, in some important way, so we don't do it. Or it may be a consequence of something else which is an advantage. They need to know.
Being familiar with the issues and paradigms surrounding our community, the politics and philosophy, allows you to write authoritatively rather than emotionally about them when they come up. Even when that is not really your cup of tea.
Users will often not follow the question guidelines, correcting peoples posting style is an educational process which improves our community as well as overall literacy. Familiarize yourself with the tutorials section, particularly the bits about asking questions, they apply to you too.
Do not waste time replying to someone only to tell them how badly they've written their question. Many questions titled "URGENT" have a dozen replies from people telling OP how they won't get any replies.
If a post actually breaks rules, don't reply at all - just hit the "inform moderator" button.
If someone thinks you've been unfair - don't get bogged down in recriminations: inform the moderator about your own post and ask for a reality check. As you correct others, be prepared to be corrected in turn.
Rewrite the question
Users may not know the right words to describe a problem. Part of your job is to parse what they have written then reflect it back to them to make sure you have understood what they are asking.
That's it: I'm going back to Windows!
In other words: do not feed the trolls. If someone wants to give up, the appropriate reply is: "LOL: good luck." Resist the temptation to tell them the error of their ways. Either they will rediscover why they left windows in the first place, or they were never really interested.
The same goes for anything provocative: learn to recognise the signs. Another example is "linux is not ready for the desktop". Answer: "LOL: good one."
Create stock replies
If you find yourself writing the same thing repeatedly, write it in a text file in your system. When you next see the need for it, you can cut and paste and get away.
Format your replies
Even the quick ones - familiarize yourself with the BB code markup.
OPs do not always realise that they are expected to provide feedback by replying to posts. If you do not get feedback in 48 hours, post "How did you get on with this?" - that question will appear in the email notification and prompt a reply.
Reward the questioner
When a user finds an answer, congratulate them. Even if it was like pulling teeth.
We all do this at some stage - but these should be avoided.
Users do not read the manual, we know this. But even when they do, they do not always understand it. That is what you are here for.
If the information is available in the manual, assume intelligence: they missed it. Reply "man command" and follow up by pointing out the section that contains the information needed.
Related to this is:
Same advice as RTFM, but this is not as bad. If you did a Google and got lots of hits which would help, then post a link to the first one with GIYF - and a smiley.
Note: while GIYF is most commonly expanded to "Google Is Your Friend", some people expand it differently as in: "Get It Yourself, Faardwark" or worse. The smiley is essential.
Don't use that distro - use distro xyz instead.
... it does not matter how ill informed you believe the users choice of distro is, if their choice is not directly appropriate to their problem do not suggest changing it. If you want to convince people which distro is best, there is a thread for you.
"cannot use usb in redhat 7.2"
- in which case, changing distro is the only sane response. Even in this case, ask why they have chosen that distro as well as suggest a distro which is as close as possible to their original choice. Some people run legacy systems for special reasons, you need to respect that.
"need to install xyz in RHEL"
- someone is asking for support for a commercial distro which you know the vendor sells. If OP does not want to pay for support, they should use a non-commercial distro. Say so, but also point to how to solve the issue - they may have a good reason to do what they are doing.
It is quite common for ex-proprietary software users to believe that a "pro" or "commercial" version of software is better than "non-commercial" or "community supported". This is because of extensive marketing to justify antifeatures in common non-free software.
It is also common for users to believe they have an unauthorized copy the commercial software and that is commercial but free (libre) and that they are seeking support from fellow copyright infringers.
If you identify these attitudes, feel free to tell them the good news.
The most common place for a distro suggestion in the answer is when the question includes: "which distro should I use" or some variation. It is still best to avoid actually suggesting one. Instead, explain how any suggestion is too subjective to be useful, and direct OP to a distribution chooser.
After writing all that, if you still feel compelled to support a particular distro - treat it as an aside ("I use aybabtu gnu/linux myself") and put it at the end.
Keep it cool and don't sweat the small stuff.