Slashdot Mirror


Drive-By Contributors to the Linux Kernel

eldavojohn writes "There's an interesting post over at the Kernel Trap that focuses on a man's attempt to find out how many one-time contributors Linux averages per release. Although imperfect due to some obvious unavoidable flaws, he got a few dirty numbers of 'never seen from agains' in the commits from patches 2.6.11 through 2.6.25 and the numbers are: {63, 148, 128, 92, 96, 122, 137, 140, 135, 95, 136, 153, 179, 179, 304}. This makes sense as another reader, Greg KH, pointed out that the distribution curve is tilted towards one-hit contributions, 'the distribution of all of our users are: 50% only contributed 1 patch; 25% contributed 2; 12% contributed 3; 6% contributed 4 and so on ...'"

6 of 61 comments (clear)

  1. Suggestions for evil? by Henry+V+.009 · · Score: 5, Insightful

    There doesn't seem to be a lot of room for a web of trust here. I wonder how hard it would be to inject some sort of extremely non-obvious race condition hidden in a large and useful patch that just so happens to let you execute arbitrary code?

    If you were found out, you could just claim, plausibly, that you hadn't seen the possibility of the race. Or maybe just be a one-time contributor so there is no way to track you down if the hole is discovered.

  2. Well.... by Darkness404 · · Score: 4, Insightful

    Well when you think about it, 1 patch just happens to be the number that most people will use. For example, a hardware business may put in one patch to get a device to work, a software company may put in one patch to make other things work, an individual may put in one patch to fix an obvious bug, etc. The kernel, though needed is not what the end-user generally uses, so for the most part it is in the background as a stable kernel should be, making it less of a chance someone would find many bugs to have to fix.

    --
    Taxation is legalized theft, no more, no less.
    1. Re:Well.... by taniwha · · Score: 4, Insightful

      well, as an occasional patch submitter I think you're probably right - mine have all been itches I've needed to scratch (stuff that was broken that I needed) or bugs I found while wandering thru the code for other reasons - I don't do that often and as things have gotten more mature I'm just not finding problems I need fixing

  3. They probably gave up... by Anonymous Coward · · Score: 4, Insightful

    ... whenever I've tried to submit a patch, it's a nightmare of process. Make sure you have the latest build, use the right diff tool, package it the right way, submit it to the right place, get the attention of the right person. Even then, you have to convince whomever that your patch is actually needed (are you sure you have the latest code, I'm not convinced that this is a real bug), and that your code doesn't stink -- "not invented here" is a huge problem.

  4. Yeah, that was what I had in mind by mbessey · · Score: 2, Insightful

    I was even going to call out the Debian OPENSSL debacle as an example, but I figured they'd had enough grief over it already.

  5. Ego by mqduck · · Score: 3, Insightful

    Sorry if someone already said this, but here's what I think: All you have to do is write a patch that gets in *once* and you can forever brag about how your code is in the Linux kernel.

    --
    Property is theft.