[ic] Credit Card Info

Jason Kohles interchange-users@interchange.redhat.com
Sat Dec 15 21:44:00 2001


On Sat, Dec 15, 2001 at 05:55:18PM -0600, David xxxxxxx wrote:
> heh, I guess I was just begging for that wasn't I?  :o)
> 
Probably  =), but the short answer is 'yes, you need command line arguments',
and the long answer is that which arguments you need are spelled out quite
clearly in the documentation.


> -----Original Message-----
> From: interchange-users-admin@interchange.redhat.com
> [mailto:interchange-users-admin@interchange.redhat.com]On Behalf Of Jim
> Balcom
> Sent: Saturday, December 15, 2001 5:42 PM
> To: interchange-users@interchange.redhat.com
> Subject: RE: [ic] Credit Card Info
> 
> 
> On Sat, 15 Dec 2001, David xxxxxxx wrote:
> 
> DS>>Date: Sat, 15 Dec 2001 09:08:25 -0600
> DS>>From: David xxxxxxx <dxxxxxxx@cyber3dnet.com>
> DS>>Reply-To: interchange-users@interchange.redhat.com
> DS>>To: interchange-users@interchange.redhat.com
> DS>>Cc: music@labyrinth.net.au
> DS>>Subject: RE: [ic] Credit Card Info
> DS>>
> DS>>Hey guys,
> DS>>
> DS>>I sent this a week ago but haven't heard from anybody.  Do any of you
> know
> 
> From: http://www.tuxedo.org/~esr/faqs/smart-questions.html
> 
> How To Ask Questions The Smart Way
> Copyright © 2001 by Eric S. Raymond
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Table of Contents
> Introduction
> Before You Ask
> When You Ask
> How To Interpret Answers
> On Not Reacting Like A Loser
> Questions Not To Ask
> Good and Bad Questions
> If You Can't Get An Answer
> 
> ----------------------------------------------------------------------------
> ----
> 
> Introduction
> In the world of hackers, the kind of answers you get to your technical
> questions depends as much on the way you ask the questions as on the
> difficulty of developing the answer. This guide will teach you how to ask
> questions in a way that is likely to get you a satisfactory answer.
> 
> The first thing to understand is that hackers actually like hard problems
> and good, thought-provoking questions about them. If we didn't, we wouldn't
> be here. If you give us an interesting question to chew on we'll be
> grateful to you; good questions are a stimulus and a gift. Good questions
> help us develop our understanding, and often reveal problems we might not
> have noticed or thought about otherwise. Among hackers, "Good question!" is
> a strong and sincere compliment.
> 
> Despite this, hackers have a reputation for meeting simple questions with
> what looks like hostility or arrogance. It sometimes looks like we're
> hostile to newbies and the ignorant. But this isn't really true.
> 
> What we are, unapologetically, is hostile to people who seem to be
> unwilling to to think or do their own homework before asking questions.
> People like that are time sinks -- they take without giving back, they
> waste time we could have spent on another question more interesting and
> another person more worthy of an answer. We call people like this "losers"
> (and for historical reasons we sometimes spell it "lusers").
> 
> We're (largely) volunteers. We take time out of busy lives to answer
> questions, and at times we're overwhelmed with them. So we filter
> ruthlessly. In particular, we throw away questions from people who appear
> to be losers in order to spend our question-answering time more
> efficiently, on winners.
> 
> You don't want to be one of the losers. You don't want to seem like one,
> either. The best way to get a rapid and responsive answer is to ask it like
> a winner ^× to ask it like a person with smarts, confidence, and clues who
> just happens to need help on one particular problem.
> 
> (Improvements to this guide are welcome. You can mail suggestions to
> esr@thyrsus.com.)
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Before You Ask
> Before asking a technical question by email, or in a newsgroup, or on a
> website chat board, do the following:
> 
> Try to find an answer by reading the manual.
> 
> Try to find an answer by reading a FAQ.
> 
> Try to find an answer by searching the Web.
> 
> Try to find an answer by asking a skilled friend.
> 
> When you ask your question, display the fact that you have done these
> things first; this will help establish that you're not being a lazy sponge
> and wasting peoples' time. Better yet, display what you have learned from
> doing these things. We like answering questions for people who have
> demonstrated that they can learn from the answers.
> 
> Prepare your question. Think it through. Hasty-sounding questions get hasty
> answers, or none at all. The more you do to demonstrate that you have put
> thought and effort into solving your problem before asking for help, the
> more likely you are to actually get help.
> 
> Beware of asking the wrong question. If you ask one that is based on faulty
> assumptions, J. Random Hacker is quite likely to reply with a uselessly
> literal answer while thinking "Stupid question...", and hoping that the
> experience of getting what you asked for rather than what you needed will
> teach you a lesson.
> 
> Never assume you are entitled to an answer. You are not. You will earn an
> answer, if you earn it, by asking a question that is substantial,
> interesting, and thought-provoking ^× one that implicitly contributes to the
> experience of the community rather than merely passively demanding
> knowledge from others.
> 
> On the other hand, making it clear that you are able and willing to help in
> the process of developing the solution is a very good start. "Can someone
> provide a pointer?", "What is my example missing?" and "Is there a site I
> should have checked?" are more likely to get answered than "Please post the
> exact procedure I should use." because you're making it clear that you're
> truly willing to complete the process if someone can simply point you in
> the right direction.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> When You Ask
> Choose your forum carefully
> Be sensitive in choosing where you ask your question. You are likely to be
> ignored, or written off as a loser, if you:
> 
> 
> post your question to a forum where it is off topic
> 
> post a very elementary question to a forum where advanced technical
> questions are expected, or vice-versa
> 
> cross-post to too many different newsgroups
> 
> Hackers blow off questions that are inappropriately targeted in order to
> try to protect their communications channels from being drowned in
> irrelevance. You don't want this to happen to you.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Write in clear, grammatical, correctly-spelled language
> We've found by experience that people who are careless and sloppy writers
> are usually also careless and sloppy thinkers (often enough to bet on,
> anyway). Answering questions for careless and sloppy thinkers is not
> rewarding; we'd rather spend our time elsewhere.
> 
> So expressing your question clearly and well is important. If you can't be
> bothered to do that, we can't be bothered to pay attention. Spend the extra
> effort to polish your language. It doesn't have to be stiff or formal ^× in
> fact, hacker culture values informal, slangy and humorous language used
> with precision. But it has to be precise; there has to be some indication
> that you're thinking and paying attention.
> 
> Spell correctly. Don't confuse "its" with "it's" or "loose" with "lose".
> Don't TYPE IN ALL CAPS, this is read as shouting and considered rude. If
> you write like a semi-literate boob, you will probably be ignored. Writing
> like a l33t script kiddie hax0r is the absolute kiss of death and
> guarantees you will receive nothing but stony silence (or, at best, a
> heaping helping of scorn and sarcasm) in return.
> 
> If you are asking questions in a forum that does not use your native
> language, you will get a limited amount of slack for spelling and grammar
> errors ^× but no extra slack at all for sloppy thinking (and yes, we can
> usually spot that difference). Also, unless you know what your respondent's
> languages are, write in English. Busy hackers tend to simply flush
> questions in languages they don't understand, and English is the working
> language of the net. By writing in English you minimize your chances that
> your question will be discarded unread.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Send questions in formats that are easy to understand
> If you make your question artificially hard to read, it is more likely to
> be passed over in favor of one that isn't. So:
> 
> 
> Send plain text mail, not HTML.
> 
> Don't send mail in which entire paragraphs are single multiply-wrapped
> lines. (This makes it too difficult to reply to just part of the message.)
> 
> Don't send MIME Quoted-Printable encoding either; all those =20 glyphs
> scattered through the text are ugly and distracting.
> 
> Never, ever expect hackers to be able to read closed proprietary document
> formats like Microsoft Word. Most hackers react to these about as well as
> you would to having a pile of steaming pig manure dumped on your doorstep.
> 
> If you're sending mail from a Windows machine, turn off Microsoft's stupid
> "Smart Quotes" feature. This is so you avoid sprinkling garbage characters
> through your mail.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Use meaningful, specific subject headers
> On mailing lists or newsgroups, the subject header is your golden
> opportunity to attract qualified experts' attention in around 50 characters
> or fewer. Don't waste it on babble like "Please help me" (let alone "PLEASE
> HELP ME!!!!"). Don't try to impress us with the depth of your anguish; use
> the space for a super-concise problem description instead.
> 
> 
> Stupid:
> HELP! Video doesn't work properly on my laptop!
> 
> Smart:
> XFree86 4.1 misshapen mouse cursor, Fooware MV1005 vid. chipset
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Be precise and informative about your problem
> 
> Describe the symptoms of your problem or bug carefully and clearly.
> 
> Describe the environment in which it occurs (machine, OS, application,
> whatever).
> 
> Describe the research you did to try and understand the problem before you
> asked the question.
> 
> Describe the diagnostic steps you took to try and pin down the problem
> yourself before you asked the question.
> 
> Describe any recent changes in your computer or software configuration that
> might be relevant.
> 
> Do the best you can to anticipate the questions a hacker will ask, and to
> answer them in advance in your request for help.
> 
> Simon Tatham has written an excellent essay entitled How to Report Bugs
> Effectively. I strongly recommend that you read it.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Describe the problem's symptoms, not your guesses
> It's not useful to tell hackers what you think is causing your problem. (If
> your diagnostic theories were such hot stuff, would you be consulting
> others for help?) So, make sure you're telling them the raw symptoms of
> what goes wrong, rather than your interpretations and theories. Let them do
> the interpretation and diagnosis.
> 
> 
> Stupid:
> I'm getting back-to-back SIG11 errors on kernel compiles, and suspect a
> hairline crack on one of the motherboard traces. What's the best way to
> check for those?
> 
> Smart:
> My home-built K6/233 on an FIC-PA2007 motherboard (VIA Apollo VP2 chipset)
> with 256MB Corsair PC133 SDRAM starts getting frequent SIG11 errors about
> 20 minutes after power-on during the course of kernel compiles, but never
> in the first 20 minutes. Rebooting doesn't restart the clock, but powering
> down overnight does. Swapping out all RAM didn't help. The relevant part of
> a typical compile session log follows.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Describe your problem's symptoms in chronological order
> The most useful clues in figuring out something that went wrong often lie
> in the events immediately prior. So, your account should describe precisely
> what you did, and what the machine did, leading up to the blowup. In the
> case of command-line processes, having a session log (e.g., using the
> script utility) and quoting the relevant twenty or so lines is very useful.
> 
> If the program that blew up on you has diagnostic options (such as -v for
> verbose), try to think carefully about selecting options that will add
> useful debugging information to the transcript.
> 
> If your account ends up being long (more than about four paragraphs), it
> might be useful to succinctly state the problem up top, then follow with
> the chronological tale. That way, hackers will know what to watch for in
> reading your account.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Don't ask people to reply by private email
> Hackers believe solving problems should be a public, transparent process
> during which a first try at an answer can and should be corrected if
> someone more knowledgeable notices that it is incomplete or incorrect.
> Also, they get some of their reward for being respondents from being seen
> to be competent and knowledgeable by their peers.
> 
> When you ask for a private reply, you are disrupting both the process and
> the reward. Don't do this. It's the respondent's choice whether to reply
> privately ^× and if he does, it's usually because he thinks the question is
> too obvious or ill-formed to be interesting to others.
> 
> There is one limited exception to to this rule. If you think the question
> is such that you are likely to get a lot of answers that are all pretty
> similar, then the magic words are "email me and I'll summarize the answers
> for the group". It is courteous to try and save the mailing list or
> newsgroup a flood of substantially identical postings ^× but you have to
> keep the promise to summarize.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Prune pointless queries
> Resist the temptation to close your request for help with semantically-null
> questions like "Can anyone help me?" or "Is there an answer?" First: if
> you've written your problem description halfway competently, such tacked-on
> questions are at best superfluous. Second: because they are superfluous,
> hackers find them annoying ^× and are likely to return logically impeccable
> but dismissive answers like "Yes, you can be helped" and "No, there is no
> help for you."
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Courtesy never hurts, and sometimes helps
> Be courteous. Use "Please" and "Thanks in advance". Make it clear that you
> appreciate the time people spend helping you for free.
> 
> To be honest, this isn't as important as (and cannot substitute for) being
> grammatical, clear, precise and descriptive, avoiding proprietary formats
> etc.; hackers in general would rather get somewhat brusque but technically
> sharp bug reports than polite vagueness. (If this puzzles you, remember
> that we value a question by what it teaches us.)
> 
> However, if you've got your technical ducks in a row, politeness does
> increase you chances of getting a useful answer.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Follow up with a brief note on the solution
> Send a note after the problem has been solved to all who helped you; let
> them know how it came out and thank them again for their help. If the
> problem attracted general interest in a mailing list or newsgroup, it's
> appropriate to post the followup there.
> 
> Your followup doesn't have to be long and involved; a simple "Howdy - it
> was a failed network cable! Thanks, everyone. - Bill" would be better than
> nothing. In fact, a short and sweet summary is better than a long
> dissertation unless the solution has real technical depth.
> 
> Besides being courteous and informative, this sort of followup helps
> everybody who assisted feel a satisfying sense of closure about the
> problem. If you are not a techie or hacker yourself, trust us that this
> feeling is very important to the gurus and experts you tapped for help.
> Problem narratives that trail off into unresolved nothingness are
> frustrating things; hackers itch to see them resolved. The good karma that
> scratching that itch earns you will be very, very helpful to you next time
> you need to pose a question.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> How To Interpret Answers
> RTFM and STFW: How To Tell You've Seriously Screwed Up
> There is an ancient and hallowed tradition: if you get a reply that reads
> "RTFM", the person who sent it thinks you should have Read The Fucking
> Manual. He is almost certainly right. Go read it.
> 
> RTFM has a younger relative. If you get a reply that reads "STFW", the
> person who sent it thinks you should have Searched The Fucking Web. He is
> almost certainly right. Go search it.
> 
> Often, the person sending either of these replies has the manual or the web
> page with the information you need open, and is looking at it as he types.
> These replies mean that he thinks (a) the information you read is easy to
> find, and (b) you will learn more if you seek out the information than if
> you have it spoon-fed to you.
> 
> You shouldn't be offended by this; by hacker standards, he is showing you a
> rough kind of respect simply by not ignoring you. You should instead thank
> him for his grandmotherly kindness.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> If you don't understand...
> If you don't understand the answer, do not immediately bounce back a demand
> for clarification. Use the same tools that you used to try and answer your
> original question (manuals, FAQs, the Web, skilled friends) to understand
> the answer. If you need to ask for clarification, exhibit what you have
> learned.
> 
> For example, suppose I tell you: "It sounds like you've got a stuck zentry;
> you'll need to clear it." Then:
> 
> Here's a bad followup question: "What's a zentry?"
> 
> Here's a good followup question: "OK, I read the man page and zentries are
> only mentioned under the -z and -p switches. Neither of them says anything
> about clearing zentries. Is it one of these or am I missing something here?"
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> On Not Reacting Like A Loser
> Odds are, you'll screw up a few times, on hacker community forums -- in
> ways detailed in this article, or similar. And you'll be told exactly how
> you screwed up, possibly with colourful asides. In public.
> 
> When this happens, the worst thing you can do is whine about the
> experience, claim to have been verbally assaulted, demand apologies,
> scream, hold your breath, threaten lawsuits, complain to people's
> employers, leave the toilet seat up, etc. Instead, here's what you do:
> 
> Get over it. It's normal. In fact, it's healthy and appropriate.
> 
> Community standards do not maintain themselves: They're maintained by
> people actively applying them, visibly, in public. Don't whine that all
> criticism should have been conveyed via private mail: That's not how it
> works. Nor is it useful to insist you've been personally insulted when
> someone comments that one of your claims was wrong, or that his views
> differ. Those are loser attitudes.
> 
> There have been hacker forums where, out of some misguided sense of
> hyper-courtesy, participants are banned from posting any fault-finding with
> another's posts, and told "Don't say anything if you're unwilling to help
> the user." The resulting departure of clueful participants to elsewhere
> causes them to descend into meaningless babble and become useless as
> technical forums.
> 
> Exaggeratedly "friendly" (in that fashion) or useful: Pick one.
> 
> Remember: When that hacker tells you that you've screwed up, and (no matter
> how gruffly) tells you not to do it again, he's acting out of concern for
> (1) you and (2) his community. It would be much easier for him to ignore
> you and filter you out of his life. If you can't manage to be grateful, at
> least have a little dignity, don't whine, and don't expect to be treated
> like a fragile doll just because you're a newcomer with a theatrically
> hypersensitive soul and delusions of entitlement.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Questions Not To Ask
> Here are some classic stupid questions, and what hackers are thinking when
> they don't answer them.
> 
> Q: Where can I find program X?
> Q: I'm having problems with my Windows machine. Can you help?
> Q: I'm having problems installing Linux or X. Can you help?
> Q: How can I crack root/steal channel-ops privileges/read someone's email?
> Q: Where can I find program X?
> 
> A: The same place I'd find it, fool -- at the other end of a web search.
> Ghod, doesn't everybody know how to use Google yet?
> 
> Q: I'm having problems with my Windows machine. Can you help?
> 
> A: Yes. Throw out that Microsoft trash and install Linux.
> 
> Q: I'm having problems installing Linux or X. Can you help?
> 
> A: No. I'd need hands-on access to your machine to troubleshoot this. Go
> ask your local Linux user group for hands-on help.
> 
> Q: How can I crack root/steal channel-ops privileges/read someone's email?
> 
> A: You're a lowlife for wanting to do such things and a moron for asking a
> hacker to help you.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Good and Bad Questions
> Finally, I'm going to illustrate how to ask questions in a smart way by
> example; pairs of questions about the same problem, one asked in a stupid
> way and one in a smart way.
> 
> 
> Stupid: Where can I find out stuff about the Foonly Flurbamatic?
> This question just begs for "STFW" as a reply.
> 
> Smart: I used Google to try to find "Foonly Flurbamatic 2600" on the Web,
> but I got no useful hits. Does anyone know where I can find programming
> information on this device?
> This one has already SFTWed, and sounds like he might have a real problem.
> 
> 
> Stupid: I can't get the code from project foo to compile. Why is it broken?
> He assumes that somebody else screwed up. Arrogant of him.
> 
> Smart: The code from project foo doesn't compile under Nulix version 6.2.
> I've read the FAQ, but it doesn't have anything in it about Nulix-related
> problems. Here's a transcript of my compilation attempt; is it something I
> did?
> He's specified the environment, he's read the FAQ, he's showing the error,
> and and he's not assuming his problems are someone else's fault. This guy
> might be worth some attention.
> 
> 
> Stupid: I'm having problems with my motherboard. Can anybody help?
> J. Random Hacker's response to this is likely to be "Right. Do you need
> burping and diapering, too?" followed by a punch of the delete key.
> 
> Smart: I tried X, Y, and Z on the S2464 motherboard. When that didn't work,
> I tried A, B, and C. Note the curious symptom when I tried C. Obviously the
> florbish is grommicking, but the results aren't what one might expect. What
> are the usual causes of grommicking on MP motherboards? Anybody got ideas
> for more tests I can run to pin down the problem?
> This person, on the other hand, seems worthy of an answer. He has exhibited
> problem-solving intelligence rather than waiting for an answer to drop from
> on high.
> 
> In the last question, notice the subtle but important difference between
> demanding "Give me an answer" and "Please help me figure out what
> additional diagnostics I can run to achieve enlightenment."
> 
> In fact, the form of that last question is closely based on a real incident
> that happened in August 2001 on the linux-kernel mailing list. I (Eric) was
> the one asking the question that time. I was seeing mysterious lockups on a
> Tyan S2464 motherboard. The listmembers supplied the critical information I
> needed to solve them.
> 
> By asking the question in the way I did, I gave people something to chew
> on; I made it easy and attractive for them to get involved. I demonstrated
> respect for my peers' ability and invited them to consult with me as a
> peer. I also demonstrated respect for the value of their time by telling
> them the blind alleys I had already run down.
> 
> Afterwards, when I thanked everyone and remarked how well the process had
> worked, an lkml member observed that he thought it had worked not because
> I'm a "name" on that list, but because I asked the question in the proper
> form.
> 
> We hackers are in some ways a very ruthless meritocracy; I'm certain he was
> right, and that if I had behaved like a sponge I would have been flamed or
> ignored no matter who I was. His suggestion that I write up the whole
> incident as an instruction to others led directly to the composition of
> this guide.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> If You Can't Get An Answer
> We realize that there are many people who just want to use the software we
> write, and have no interest in learning technical details. For most people,
> a computer is merely a tool, a means to an end. We acknowledge that, and
> don't expect everyone to take an interest in technical matters.
> Nevertheless, our style of answering questions is tuned for people who do
> take such an interest.
> 
> Thus, if you can't get an answer, please don't take it personally that we
> don't feel we can help you. There are other sources of help you can go to,
> often sources better adapted to a novice's needs.
> 
> There are many online and local user groups who are enthusiasts about the
> software, even though they may never have written any software themselves.
> These groups often form so that people can help each other and help new
> users.
> 
> There are also plenty of commercial companies you can contract with for
> help, both large and small. Don't be dismayed at the idea of having to pay
> for a bit of help! After all, if your car engine blows a head gasket,
> chances are, you will take it to a repair shop and pay to get it fixed.
> Even if the software didn't cost you anything, you can't expect that
> support will always come for free.
> 
> For popular software like Linux, there are are at least 10000 users per
> developer. It's just not possible for one person to handle the support
> calls from over 10000 users. Remember that even if you have to pay for
> support, you are still paying much less than if you had to buy the software
> as well (and support for closed-source software is usually more expensive
> and less competent than support for open-source software).
> 
> 
> Compliments of
> Dan Browning <danpb@mail.com>
> 
> 
> -= Jim =-
> 
> ----------------------------------------------------------------
> Jim's Linux-Operated Underground Bomb Shelter
> 
> Tagline for Saturday, December 15, 2001 at 18:40 PM:
> Puns are bad, but poetry is verse.
> 
> ----------------------------------------------------------------
> This Linux System has been up 483 hours
> 
> My web page: http://www.idk-enterprises.com
> ----------------------------------------------------------------
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com
> http://interchange.redhat.com/mailman/listinfo/interchange-users
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com
> http://interchange.redhat.com/mailman/listinfo/interchange-users

-- 
Jason Kohles                                 jkohles@redhat.com
Senior System Architect                      (703)786-8036 (cellular)
Red Hat Professional Consulting              (703)456-2940 (office)