Drive-By Contributors to the Linux Kernel 61
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 ...'"
won't something think of the children? (Score:4, Funny)
Re: (Score:1, Offtopic)
Re:won't something think of the children? (Score:4, Funny)
Re: (Score:2)
Re: (Score:1)
also someone needs to add a "butt to jokes" section on wikipedia and add this to jack's
Suggestions for evil? (Score:5, Insightful)
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.
Re: (Score:2)
Re:Suggestions for evil? (Score:5, Funny)
Representatives of the NSA: if you're reading this, you know who I am and how to get in touch with me. And probably what I'm doing at exactly this moment.
Re:Suggestions for evil? (Score:5, Funny)
Re: (Score:1)
Stop touching yourself!
Re: (Score:3, Informative)
I'm pretty sure submitted code is reviewed, so you'd have to be pretty clever.
It has been tried before. [kerneltrap.org] In this case, someone attempted to use the common C programming mistake of using the assignment operator instead of the comparison operator to backdoor the kernel.
Not the way to do it (Score:3, Interesting)
As the parent poster mentioned, you'd ideally want to submit a fairly large patch that does something useful (fixes a bug, adds a minor feature), but whicvh itself contains an exploitable bug.
The trick would be in making the submission large enough and the bug subtle enough that it just skates past review. Of course, it'd be *m
Re: (Score:3, Interesting)
Yeah, that was what I had in mind (Score:3, Insightful)
Re: (Score:1, Informative)
Re: (Score:2)
Re: (Score:2)
Also patches get rejected all the time, even useful ones because they aren't up to standard.
Why put it in one patch? (Score:4, Interesting)
Alternatively, accomplish the same thing via 2+ patches to 2+ projects which are likely to be used together. One patch against httpd + one patch against php = potential for a lot of mischief. Its not hard to fit a key to a lock when you're allowed to modify both the key and the lock to suit your tastes.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Funny)
Well.... (Score:5, Insightful)
Re:Well.... (Score:5, Insightful)
Drive-by (Score:5, Interesting)
What if there were a bifurcation or distribution of the bug-fixing/feature-adding problem? This may be really stupid, but I imagine a situation where testers go through finding things that are wrong or where they go wrong, then submit that bit of code.
On top of this, there is a system which grabs the trace and shows the bit of code where everything got derailed, and in other panes the stuff it called to, so anybody could look over the "offending" code, without having to be intimately familiar with the kernel or the library or whatever, since it is all laid out for them. Then, people can tinker with the code and submit them for (automatic, since you know what to look for) testing, maybe leave comments on the ticket to help others' or as a group try to figure it out.
I don't have time to wade through mountains of kernel code looking for bugs, but I would be more than willing to look over a (relatively) small bit of code in a collaborative fashion to see if I pick up on something others had missed.
Re: (Score:2)
Really good idea (Score:3, Interesting)
Quite frankly, I'd love to see professors assign this sort of thing as homework to their students. Grab a piece of OSS, and squash a bug. Or give them a reasonable size chunk of code and have them review it.
Re: (Score:2)
I'm one! (Score:5, Interesting)
I submitted a workaround for a buggy USB device [kvance.com] a few months ago, which was my first patch after using linux for more than 10 years. Usually when I find a problem in the kernel it's either already been fixed in a later version, or it looks too complicated for me to risk wasting my time on. I would bet that a lot of my one-off colleagues have had the same experience.
Re: (Score:2, Flamebait)
While stuck in the Manchester, NH airport, I've just had my first bootable 2.6.26-rc4 compile.
With my Intel ICH7 drive, the ata_piix module apparently wasn't initializing things, and I had no
Everything is easy when you know how to do it, but the make menuconfig options had change enough from my previous bootable 2.6.25.x image that I was hating life for a while.
Documentation? Stuff that
They probably gave up... (Score:4, Insightful)
Re: (Score:2, Interesting)
They prob. had good reasons to refuse your patches (Score:4, Interesting)
Re: (Score:2)
Maybe not straight into the kernel tree, but if a person can only contribute 25% of what needs doing and do so, shouldn't inherently prevent a patch from being accepted.
I'm not sure about that. Arguably, if you're not experienced enough to follow good coding procedures and have proper tests and documentation, you have no business to be messing about with the kernel. Same if you don't have knowledge of the concepts behind low level OS code.
As a user of the Linux kernel, I expect it to perform reliably. Having a high code quality standards helps ensure that. In the open source model you only get an opportunity to have your code included, not a right.
Anonymous Cowards (Score:3, Funny)
Re: (Score:3, Funny)
#include "small_patch_preempted_by_fascist_Filter_error_ hmm_wonder_what_that_means_WRT_popularity_of_once_great_site as_I_break_this_up_to_work_around_yet_another_asinine_error.c"
Re: (Score:1, Funny)
--- filetable.c.orig
+++ filetable.c
+//
+// You must be new here!
+//
exit(1);
}
I've been thinking of doing this myself. (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
As opposed to say a link in /usr/src, which may or may not be correct? Yes, it's not perfect, but it would be better than what is used today. And, as for "updating the sources" -- the point is that when you want to run one of these scripts that needs to know where the kernel sources are, it doesn't want to know
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Of course, chances are if you're patching kernels and such then the source at that path will change, and you'll forget about it.
The reason that, e.g., /proc/config.gz is useful, is that that config file is actually built in to the running kernel image. So it's pretty hard for it to get out of sync with the running kernel. But few people are going to want the entire
I'm... (Score:1)
How many contributed 0 patches? (Score:5, Interesting)
I think that would be a very interesting statistic.
G.
Re: (Score:2)
It is the old principal of 'stupid' managers, anything someone is still trying to explain to you after 15 minutes is probably worth paying attention to
If someone can actually be bothered to go through the process of submitting a patch and do it correctly then they the code they are submitting is much more likely to be useful....
Ego (Score:4, Insightful)
Re: (Score:2)
Re: (Score:1)
another reader, Greg KH ??? (Score:1)
Obvious flaw (Score:2)
The most obvious flaw I can think of is that the newer releases have fewer follow-up releases with which to submit extra patches. This doesn't seem to be mentioned in the article. For instance the 2.6.25 release is the most current. Of course all 'new' submitters to the 2.6.25 release will not have submitted any more patches. All 'new' submitters to the 2.6.24 release will have had the chance to also submit a patch for 2.6.25.
Let's assume that each release has 100 'new' submitters and that the chanc