[Gllug] socket buffer overrun

Peter Grandi pg_gllug at gllug.sabi.co.UK
Wed Oct 19 19:48:03 UTC 2005


>>> On Wed, 19 Oct 2005 17:37:45 +0100, Simon Morris
>>> <simon.morris at cmtww.com> said:

[ ... ]

simon.morris> My point was that link to justfuckinggoogleit.com
simon.morris> and remarks such as "However thanks for your inner
simon.morris> confidence that people willing to help you are
simon.morris> psychic. :-)" are mildly amusing but not overly
simon.morris> helpful to anyone.

Really? Isn't that a sutble helpful hint as to ''Your question
is so sparse on details that it is almost useless, so please try
to improve it''? And I did try to improve it, by asking specific
questions.

simon.morris> It smacks of sarcasm. (Yes - I did see the smiley face)

Well, if you are inclined to see ill will even in the actions of
people who spend some of their time helping others, that's your
problem sunshine. And even if it were sarcasm, which I do use at
times, well sarcasm can be a useful device to convey an effect,
and entirely legitimate.

[ ... ]

simon.morris> The OP didn't post a question that was blatantly
simon.morris> obvious to everyone on the list..

That's a rather ridiculous switch of subject: it was not the
obviousness of the question that was the topic, it was how well
worded it was and how obvious were the relevant Google keywords.

simon.morris> [ ... ] and the question was technically well put.

That's your declamatory opinion for which as usual you offer
little argument beyond your own precious say-so. ''Thanks'' for
writing as if your arguments were self evident truths.

[ ... ]

simon.morris> Again, I don't understand. [ ... ] Without knowing
simon.morris> what you are referring to it is impossible for me
simon.morris> to comment on that paragraph.

Then don't waste those lines to say you cannot comment, get over
it, sunshine.

simon.morris> You seem unduly upset by a small amount of
simon.morris> criticism. sorry if you are actually that
simon.morris> offended.

Ah what a florid (and slightly twisted perhaps) imagination :-).

It looks instead to me that you are striving to make a mountain
out of a molehill, by creating a whole subthread about a couple
of passing lines, and it is only out of (dwindling) respect for
your declamatory opinions that I try to take them seriously this
time.

The OP himself seemed to think his remark had been seized upon
beyond the scope he meant it to have:

  «Maybe so but I don't want that to be the main point in my
   message. That was a small note [ ... ]»

and thanks for that.

simon.morris> but I simply remarked that there isn't the need to
simon.morris> tell people to google for things that aren't
simon.morris> painfully obvious.

If that's all you really meant to say then you could have said
it so in two lines instead of rabbiting on, stating without
arguing your peculiar opinions.

And then I would say that I really disagree with your bare
declamations because:

* The keywords to use were indeed in this case painfully
  obvious: it was a question about a TCP performance tuning
  issue on Linux over gigabit ethernet and I used the keywords

    "gigabit ethernet" linux tcp performance tuning

  The only legitimate reasons why such a search had not happened
  (and apparently it did not) seem to me:

    - Dire time pressure.
    - Guessing that the obvious keywords would
      not get a good set of results.

  Since I am inclined to give the benefit of doubt I did a bit
  of spoonfeeding. Pointless, because it turns out that as the
  panic was alleviated the OP ''filed them away for future
  reference''. :-)

* Virtually all the question-asking suggestions that I have
  consulted when writing my own have a much higher threshold
  than «blindingly obvious» for doing at least a Google search
  before asking a question. They normally suggest that a seeker
  of help should make some non nugatory effort to search for
  information before asking a question.

-- Warning: long set of quotes follow. --

Examples of the latter point:

  http://Reactor-Core.org/irc-help.html

   «3. Don't ask a question you haven't researched first.
       We aren't your mom. You'll have to pick up your own dirty
       laundry, but we're willing to teach you to use the
       washing machine. The important thing here is not that you
       be a superman who does everything by himself; if you were
       superman, you wouldn't be coming to a help channel for
       help. The important thing is that you be seen to be
       making an honest attempt to do it yourself.

    4. Tell us up front what research you have already done.
       If you just ask your question, we will assume you haven't
       done any research. As you may have guessed by now, a "do
       my work for me" attitude isn't looked on favorably. When
       you let us know what research you've already done, and
       that you have reached the limit of your skill level, we
       will help you from there.»

  http://Wiki.LinuxQuestions.org/wiki/Getting_help_from_IRC

   «1. Try google first. Search both Web and Groups. 80% of the
       questions people ask can be found immediately by google,
       and people might treat you unkindly, to say the least, if
       you didn't even make an effort to find out for yourself.

    2. Make it convenient for people to help. Saying "Can anyone
       help me?" turns people off, because they know they'll
       spend several minutes asking pointless followups like
       "With what?" and "What about it?". Instead, ask specific
       questions like "How can I give my ethernet card a
       specific address when I boot, instead of using DHCP, in
       Gentoo 1.4?" which will allow people to answer in a
       single line.»

  http://WWW.Catb.org/~esr/faqs/smart-questions.html

   «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 searching the Web.
    * Try to find an answer by reading the manual.
    * Try to find an answer by reading a FAQ.
    * Try to find an answer by inspection or experimentation.
    * Try to find an answer by asking a skilled friend.
    * If you are a programmer, try to find an answer by reading
      the source code.
    * 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 people's 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.

    Use tactics like doing a Google search on the text of
    whatever error message you get (and search Google groups as
    well as web pages). This might well take you straight to fix
    documentation or a mailing list thread that will answer your
    question. Even if it doesn't, saying ?I googled on the
    following phrase but didn't get anything that looked useful?
    is a good thing to be able to put in email or news postings
    requesting help.»

   «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). Provide your vendor's distribution
      and release level (e.g.: ?Fedora Core 2?, ?Slackware 9.1?,
      etc.).
    * 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.»

I don't read in any of these ''Do research only if your question
is painfully obvious, else let the suckers that reply do it for
you''.

So, I normally do no even answer questions that are mere fishing
expeditions. I did to this, because it there were some positive
elements.

In this specific case the OP while asking a vague and seemingly
underresearched questions had done some _some_ prior work (the
good and correct guess that the buffers were relevant, the less
agreeable one that a minuscule loss percentage was, the good
guess of a high setting for 'txqueuelen'), and had provided some
_minimal_ context (2.4.21 kernel for example).

I note with some sadness that hairy and contrived objections to
my sideways and humourous (or sarcastic, depending on perception)
complaints about the lack of details and research in the original
question has lead me to substantiate them, which may have been
less pleasant for the OP than if my remarks had been left alone.

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list