there’s no such thing as a stupid…

Actually, sometimes there are stupid questions.

Especially if you keep asking your question, hearing an answer you don’t like, and then re-asking your question hoping to hear a different answer.

The Linux kernel mailing list has a reputation for being somewhat unfriendly, but for the most part, it’s actually quite civil. The experienced folks often bend over backwards to help out the new kids on the block. But when a new kid isn’t very good at listening, a lot of time gets wasted which just annoys everyone, and then the flame throwers come out.

I’m not really into schadenfreude, but this little mail exchange was too precious not to share. I admit, I’m a mean person and sometimes laugh at other people’s problems (yeah, you know me).

DRAMATIS PERSONAE

• FNG: the new guy, trying to understand a fundamental concept of Linux programming and how to hook into a key piece of infrastructure
• greg: the guy who wrote the infrastructure

FNG send a mail for help, asking his question.

greg responds with the answer, basically saying “your approach is wrong for these x,y,z reasons; don’t do that”

FNG responds with, “no really, I want to do this frobnitz in spite of x,y, z. look, here’s some code that let’s me ignore prominent reason x! even though the infrastructure complains specifically about x when I try to do it, here’s what I’m doing!”

In response to the code, greg writes:

WTF!!!

Ugh, if I see one more person try to “trick” the kernel from reporting
this error by providing a “dummy” release function, I’m going to go find
a kitten to kick.

Seriously, why are you blatantly ignoring the warning that the kernel is
trying to be nice and give to you? Do we just invent messages that need
to be worked around?

Fifteen minutes later, we see a followup email from greg. An unexperienced observer might think that greg is publicly following up to apologize for being mean to FNG. The experienced observer knows quite differently.

Oh, and before anyone thinks that I’m being too harsh here, again, refer
to Documentation/kobject.txt:

        Note that the kernel will warn you if you forget to provide a
        release() method.  Do not try to get rid of this warning by
        providing an "empty" release function; you will be mocked
        mercilessly by the kobject maintainer if you attempt this.

Hence my mocking.

thanks,
greg

It was documented that you would get mocked if you did something silly, and lo and behold, the system behaved exactly as documented.

[nb, I know greg in real life, and he's actually quite a nice guy. some days just really try your patience.]