LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

Job opening: kernel bug manager

In the middle of the discussion on the handling of kernel bugs, Andrew Morton let it slip that the long-rumored, Google-funded kernel bug manager position is now open. It's apparently proved hard to fill: "Unfortunately the recruiting has been a bit tricky - this is not a typical job and it's a funny mixture of bureaucracy/politics/social engineering and programming. People who are skilled in both areas, are, ah, uncommon." If you are such a person this could be a great opportunity to build kernel skills while working directly with Andrew - and help the kernel process as well.
(Log in to post comments)

Job opening: kernel bug manager

Posted Apr 30, 2007 23:01 UTC (Mon) by bboissin (subscriber, #29506) [Link]

AFAIK, it's been open for a while. I've seen this particular offer months ago. It looks like it's hard to find the right person.

Job opening: kernel bug manager

Posted May 1, 2007 8:50 UTC (Tue) by xma (guest, #44981) [Link]

Or nobody is really interested in tracking bugs as usual in the free
software community :)

I am one of these people. I'd rather add code than fixing bugs :0

Job opening: kernel bug manager

Posted May 1, 2007 16:00 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]

At least in the case of GCC, we're fortunate to have a number of people who are very dedicated to doing a good job of bug tracking, including one guy who seems to have memorized the Bugzilla database (not really, but it seems that way).

Job opening: kernel bug manager

Posted May 1, 2007 17:44 UTC (Tue) by tuxchick (guest, #42009) [Link]

Why would any programmer be satisfied with releasing buggy code? I don't
understand this attitude, and it seems to be very common. What's the
point? Anyone can write bad code, right? Isn't it the mark of a skilled
professional to turn out something that is good and works right? In every
other profession it's standard procedure to have quality control and fix
problems. Writers revise; electricians don't leave wires sparking and
appliances shorting; when the kid who mows your lawn misses a spot, you
make him come back and finish it. Why do programmers think they are exempt
from basic quality control?

Reasons to ignore bugs

Posted May 1, 2007 18:51 UTC (Tue) by zlynx (subscriber, #2285) [Link]

A programmer might ignore bugs because:

It works for him. He doesn't care about some guy with a broken ACPI table or IPv6. Not his problem and he's working for free anyway.

The code knowingly ignores some complex problems in order to get something out that mostly works most of the time for most people. Better than nothing!

Programmer exhaustion. He can't reproduce the bug on his equipment, he can't find the bug by code inspection, and the two people with the bug won't run his software with enough logging to find the bug because of the 50% performance degradation and 1 TB log files it requires.

Reasons to ignore bugs

Posted May 2, 2007 18:49 UTC (Wed) by tuxchick (guest, #42009) [Link]

OK, I can understand those reasons. But none of them apply to the OP's
comments. What's the point of doing anything if you never want to progress
beyond a rough first draft? 'Dare to be shoddy'??

Reasons to ignore bugs

Posted May 3, 2007 8:25 UTC (Thu) by dark (subscriber, #8483) [Link]

Well, people enjoy different aspects of programming. For you it's probably the satisfaction of making something that works well. For xma it might be the thrill of tackling hard problems, with a corresponding lack of interest in polishing the solutions afterward. Or it might just be the joy of making things that move.

I happen to enjoy tracking down and fixing bugs, but on the other hand, when I write new code I go very slowly because I want to make sure it's perfect. I'd probably work well in a team with xma :)

To people who are in it for the hard problems, I'd say that bugs are a sign that you didn't get the solution exactly right, and sometimes the 100% solution is ten times as hard as the 99% solution. As an example, you can see that clearly in the efforts to make a kernel scheduler that works well in all cases.

Job opening: kernel bug manager

Posted Apr 30, 2007 23:09 UTC (Mon) by louie (subscriber, #3285) [Link]

Has been open for a while- at least since early this year. Good luck to them filling it; it is a hard position to fill even when you've got an active community that does very little but deal with bugs, and it doesn't seem like the kernel has that.

Job opening: kernel bug manager

Posted May 1, 2007 10:40 UTC (Tue) by rhdxmr (guest, #44404) [Link]

I wonder.. what profit would directly come by opening this job.

Job opening: kernel bug manager

Posted May 1, 2007 11:54 UTC (Tue) by xma (guest, #44981) [Link]

Maybe a reliable and stable kernel ? :) Or even to show that Google is
really helping the Free Software community ? Some people think they are
not helping but are there for profits only. GSOC is a good example of such
investment by Google.

Job opening: kernel bug manager

Posted May 1, 2007 12:15 UTC (Tue) by khim (subscriber, #9252) [Link]

Remotely exploitable security hole in kernel can cost billions for Google. Even remotely exploitable DOS-attack can cost millions! If you'll consider this you'll see that it makes perfect sense for a Google to spend a lot of resources helping kernel development. And since they don't control linux kernel development the next best thing is to participate in the process and make sure Google will have features it needs in kernel. And the number one feature is lack of bugs - all other needed features Google can develop in-house, but in-house bug fixing is just not practical.

Job opening: kernel bug manager

Posted May 1, 2007 13:49 UTC (Tue) by i3839 (subscriber, #31386) [Link]

Nice theories guys, but I think it's much simpler than that: Andrew Morton works for Google now, and I bet they asked him what's needed, or he made some noise.

That said, besides a bug manager, code reviewers seem to be scarce too.

Job opening: kernel bug manager

Posted May 1, 2007 12:42 UTC (Tue) by smitty_one_each (subscriber, #28989) [Link]

If the learning curve were less vertical, the pool of potentials might be bigger.
So maybe this job gap is a tattle-tale about some other structural changes the community might consider.
Or maybe not. Possibly the learning curve is more of a filter to winnow the weak.
Both?

Job opening: kernel bug manager

Posted May 1, 2007 14:46 UTC (Tue) by k8to (subscriber, #15413) [Link]

Do you mean a tell-tale? Or are those terms the same in your parlance?

(Not asking to be a jerk, I'm honestly both interested in and a bit murky on your meaning.)

Job opening: kernel bug manager

Posted May 1, 2007 15:44 UTC (Tue) by dlang (subscriber, #313) [Link]

see the discussion n the kernel list (a huge thread followng up the 2.6.21 release, subject 2.6.21)

many people feel that the job of noticing bugs, figuring out who to send them to, and pestering people (politely) until they get a response is something that a person with the right skills can do after only a few months of reading the kernel list to see who's involved with what.

this doesn't sound like the vertical learning curve that you are suggesting.

Job opening: kernel bug manager

Posted May 1, 2007 20:55 UTC (Tue) by louie (subscriber, #3285) [Link]

Having done exactly that for GNOME (a community which, AFAICT, is more tolerant of newbies than LKML) it isn't easy. It requires a fairly deft political sense (if you irritate people, they flip the bozo bit, and it is really hard to get them to listen to you again) as well as good technical judgment (requires good engineering taste more than actual ability to read code, I found.) The combination of both of those is rare- if you have a deaf political ear, or poor engineering sense, years of reading mailing lists won't help you.

Job opening: kernel bug manager

Posted May 3, 2007 20:12 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

You're describing a nearly horizontal learning curve, not a vertical one. A learning curve is a graph of productivity on the vertical axis against time spent doing something on the horizontal access. If it's vertical, that means you instantly have infinite productivity. Something that you slowly learn over years in order to get to maximum productivity is a long, shallow curve.

I suspect the common error of thinking that "steep learning curve" means "hard to learn" comes from a mental image of climbing a hill. But the learning curve comes from industrial engineering, where nobody cares about something being "hard." They care only about quantities of input and output.

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds