Torvalds Says It's No Picnic To Become Major Linux Coder 222
Jack Spine writes "Linus Torvalds has given an interview to ZDNet.co.uk about the trials and tribulations of becoming a Linux kernel developer. 'Torvalds said that, while it is relatively easy for coders and organisations to contribute small patches, the contribution of large patches, developed in isolation, could lead to both new and established contributors becoming frustrated.
"It's definitely not easy to become a 'big contributor'," wrote Torvalds. "For one thing, the kernel is quite complex and big, and it inevitably simply takes time to learn all the rules — not just for the code, but for how the whole development environment works. Similarly, for a new developer, it will take time before people start recognising the name and start trusting the developer to do the right things.""
Re:huh (Score:3, Interesting)
Re:huh (Score:4, Interesting)
Would you let a doctor fresh out of med school slice and dice in heart surgeries?
Would you let pilots start out flying fully loaded commercial jets?
In my limited experience, you don't let a n00b make permanent or long-lasting changes till they have gotten their training wheels off and you know that the n00b knows what the fuck they are doing or at least understand what is going on.
Not to say they couldn't be more welcoming to new developers, but a single bad line (sound familiar debian devs?) and a whole bunch of stuff could stop working.
Re:Still easier than coding the Windows Kernel (Score:2, Interesting)
What i was trying to say is that from time to time there are news that could drive to think that core dev team is full of egoes.
And with 'luck' i was trying to say that I, as a linux user, am lucky that however they organize it works, wich is the whole point of it anyway.
Comment removed (Score:5, Interesting)
Re:Andy's revenge (Score:5, Interesting)
Seriously though, the problem with microkernels is that they (in theory) help the system cope with mistakes but they don't help prevent mistakes in the first place. Each component in a microkernel is isolated from others using memory protection, but they can still corrupt themselves or crash themselves.
There's very few parts of the kernel that actually need pointer arithmetic, unsafe casts, or for that matter need to operate particularly quickly. You don't have to believe me just look at the code. Open up some random source files from the kernel and look for pointer math, unsafe casts. Figuring out what locks are held when is harder, but can be done (performance being more important when locks are held).
Microkernels are solving the wrong problem. They should be focussed on preventing the errors in the first place not on recovering from them. So, a 'safe kernel' that is mostly written in a language that prevents errors, such as Limbo/Dis or for that matter Java or C#. That would be much easier to work on and an improvement over Linux style kernels.
Re:huh (Score:1, Interesting)
I just started a new job 2 weeks ago. I haven't touched any code other than two trivial patches to some HTML. I expect it'll be another 2 weeks before I touch any actual code, and it'll be a few months before I'll touch anything that customers rely on. This is the same process that happens everywhere, the difference being that in the Linux kernel it's more open and ability based.
Well, it makes sense to keep the newly hired programmer from being able to break anything important. Learn to walk before you run and all that jazz...
Just out of curiosity; what do you do in the meantime?
Do you go through the companies application, looking for bugs? Reading up on specific APIs?
Re:huh (Score:3, Interesting)
Kernel development is actually doing just fine I think. Documented hardware gets added quickly to the Kernel and Kernel stability, performance, and security are all pretty good right now.
I would still like to see to some drivers moved out the the kernel and into the user space and a stable binary driver interface but those are political and not technical issues.
I think too many people are worried about the Kernel and not enough about the other projects that make Linux useful.
Sound still has a lot of issues. KDE and Gnome are getting better all the time but they both lack what I consider to be a really good media player.
The Kernel is the least of my worries when it comes to Linux.
BTW no there doesn't have to be a better way. Sometimes what you have is the best you can do.
Gee wiz (Score:4, Interesting)
So the Linux kernel is developed like every major software project that's ever existed.
How completely and utterly unremarkable.
Re:huh (Score:1, Interesting)
The US Senate even has a rotating term cycle so that there are always Senators with more experience to get the junior Senators acquainted with how things work.
No, the idea was to keep a corrupt party from sweeping in and taking over the Senate all at once. It would take them at least six years to do so, which would allow an exposure of their deceit.
The fact that it now works as a way to show "how things work" with lobbyists, corruption, and graft is a symptom of something entirely different.
Re:huh (Score:3, Interesting)
Nope.
It's hard because (ironically) it's easy.
It's hard because there are so many talented programmers out there, and most of the problems are already very well defined. Most of the roles for major contributions are already filled. Many new roles are filled by people who get into that position because they have early access to hardware, etc...
It's hard because it's not enough to be good (which is fairly easy), it's hard because you also have to be dedicated and political.
You were right on with #4 though.
Re:huh (Score:3, Interesting)
Well, the reasoning in my post is a bit simplistic, but it's a simple issue at its core. People trust those they know they can trust. They want everyone else to prove they can be trusted with responsibility before they grant them too much authority.
That you're a super genius nerd with a talent and affinity for writing systems-level C code doesn't mean much to kernel maintainers. All of them are super genius nerds with a talent and affinity for writing system-level C code, too. What's more is that they've proven themselves in front of the community. Being good at something difficult is wonderful. Those people reviewing and vouching for your patches can't take your word for that, though. They don't have time to review large unsolicited patches to see your awesome skills and be moved by them. Once they trust your skills from reviewing good work you've submitted in manageable chunks, they'll be more likely to look over something that takes more time to review. Being good at writing the code is just a prerequisite to getting it accepted. Proving you're willing to fix bugs, explain the changes to others on the team, and stick to the standards they team has found to be useful to the team a whole are necessary steps, too. Hit-and-run patching is fun but in the end it's not very productive when someone else has to become the maintainer on a large chunk of your code.
Re:huh (Score:3, Interesting)
Linus either rejects the patch, or there's a hoard of petty nitpicking.
Then one of the 'in crowd' of Linux developers comes up with something that does roughly the same thing (usually far more minimally). Original patch gets abandoned.
Note that there's enormous financial incentive for companies to have developers in the 'in crowd', so this is as much salary-driven as it is ego-driven.