On Mon, Dec 31, 2012 at 12:24 PM, Paul D. Fernhout
<[email protected]> wrote:
> On 12/31/12 2:32 AM, BGB wrote:
>>
>> in this case, I think Torvalds was right, however, he could have handled
>> it a little more gracefully.
>>
>> code breaking changes are generally something to be avoided wherever
>> possible, which seems to be the main issue here.
>
>
> While many people posting in the slashdot thread would agree with both your
> points, it seems that this particular kernel patch had problems for other
> reasons, and that distinction has been ignored by most commenters. According
> to the submitter of the patch being criticized, it seems like the patch was
> intended to move towards unifying the error codes issued by a set of related
> drivers. What seems to have happened was that the patch submitter by (IMHO
> poor) design used an error code internally to indicate an error condition
> that was not meant to leak out back the the user of the driver. The error
> code was supposed to be transformed as it passed the driver boundary, but
> was not in this case. So the error code leaked out of the driver (where the
> meaning of the specific numerical value would thus change as it passed the
> driver boundary), and then Linus interpreted this situation as an intent by
> the programmer's or maintainer's to provide an unexpected and inappropriate
> error codes (thus the strong language). But it was more like there was some
> sloppy programming on top of a problematical design choice (problematical
> because exactly this sort of thing could happen) on top of the maintainer
> not seeing that. Granted, that provides plenty of room for complaint, but it
> is questionable if Linus saw this when he replied. More specifics on that in
> a comment I posted with a link to supporting posts on the kernel list:
> http://slashdot.org/comments.pl?sid=3346421&cid=42417029
>
> But here are direct links to related kernel mailing list posts by the patch
> submitter and the kernel maintainer:
> https://lkml.org/lkml/2012/12/23/89
> https://lkml.org/lkml/2012/12/24/125
>
> So, the human emotions are on top of an issues that seemed incompletely
> understood. Psychological studies, like of novice vs. expert fire fighters,
> have shown that where the novice generally tries to use reason to solve a
> problem ("What is going on here based on thinking about the details? What
> will be the consequences of various choices?"), the expert tends to use
> pattern matching ("I've seen this situation before and here is what we
> should do.") So, that is why experts can make quick judgements and prescribe
> successful strategies. The experts work in bigger "chunks". Still, a
> downside to that sort of expert reasoning through pattern matching is that
> it is easy to leap to a conclusion and incorrect prescription when the
> underlying situation is very close to a common one but has some unexpected
> twist (as seems to be the case here).
>
> Anyway, good to see this sparked some interesting discussion.
>
>
> --Paul Fernhout


Thank you for elucidating the situation like you have. Your evaluation
agrees with my own, which I find gratifying, but even if it didn't I
am excited to see the social process happen publicly and
transparently.  (As opposed to the kind of primate politics that an
incident like this might trigger in, for example, a tradition
corporation or other institution.)

I see it as a "win" for open methods even if Torvalds might have a bit
of egg on his face.

~Simon Forman

-- 
http://twitter.com/SimonForman
http://www.dendritenetwork.com/

"The history of mankind for the last four centuries is rather like
that of an imprisoned sleeper, stirring clumsily and uneasily while
the prison that restrains and shelters him catches fire, not waking
but incorporating the crackling and warmth of the fire with ancient
and incongruous dreams, than like that of a man consciously awake to
danger and opportunity."  --H. P. Wells, "A Short History of the
World"
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to