Slashdot Mirror
Torvalds Says It's No Picnic To Become Major Linux Coder
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.""
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.
In other words, it's hard because I make it hard.
Who is this No Picnic fellow? I don't believe there is a new major Linux contributer.
FTFA: "Nonetheless, Torvalds said the patching process in Linux was more about human interaction than a quantifiable set of steps, such as those listed in official international standards processes."
Summarizes the interview pretty much. Most of the rest is there in the kernel Documentation folder anyways.
I cant stop being amazed by Linus's software 'management' skills.
This suites everyone that uses it pretty fine, except for the purist "it's got to be in the mainline" folks. Realists just pull it from a public cvs and apply it with minimal effort.
Although I might consider mainlining it again, for the moment the effort just is not worth it. The current model is workable for those that use it.
Engineering is the art of compromise.
Kernel development is hard! Film at 11.
I like to think of online DRM as something akin to a college -- you pay for lessons until you learn something.
And considering the widespread usage plus amount of people that rely on the Linux kernel to be stable and not explode in a horrible firestorm I can certainly understand that Linux kernel development requires a Stalinist approach.
perpetually dwelling in the -1 pits
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
What happens if:
1. Batman is more or less responsible for a big chunk of the kernel, e.g. the scheduler.
2. Torvalds knows Batman, and knows that Batman is employed by Redhat to work on the scheduler.
3. The Joker writes a new improved scheduler which has the potential to replace the old one.
Now, how does Torvalds react? It would be hard to tell Batman that he's no longer in charge of the scheduler. Batman's job might be on the line - why would Redhat keep paying Batman if he suddenly had a lot less work to do? Maybe Torvalds met Batman a few times and had a beer with him, making it even harder to replace his work because it becomes personal. Torvalds could harm Batman's career.
Surely this makes it hard to become a big new contributor? All the existing contributors already know eachother and they won't want to dump eachother's work.
Am I right or am I right?
Qualify "luck". It seems to me that any large distributed development effort is going to require some sort of process - the anarchic development model isn't terribly successful.
With that in mind, developing the Windows kernel requires you to be employed by Microsoft etc, whereas developing for the Linux kernel just requires you to follow some established open processes.
What's the problem with that?
If that's the problem, wouldn't it be easier to work on it if it was a microkernel?
Circumcision is child abuse.
Surely you only need to know a bunch of C keywords and you should be set. Here's the bunch I know
malloc
free
<<
>>
++
--
That star thingy I see every now and again.
I might have a look at this so called complicated kernel later :)
Summation 2
I have to agree with Linus on this one.
It's no picnic to become a major anything. Major people are people who have differentiated themselves from minor people. The means by which they've done that is to do something that's more difficult, which the other people cannot do. This is a tautology masquerading as wisdom.
StoneCypher is Full of BS
"Linus Torvalds has given an interview to ZDNet.co.uk about the trials and tribulations of becoming a Linux kernel developer"
Yeah, the word kernel in the first sentence was kind of a dead giveaway there.
Although I've heard that things are just as tightly controlled on the Firefox project, for example. Honestly, I think any successful open source project is going to have to tightly control submissions from random people, because there are way too many people out there with a "good idea" and varying concepts of what "quality" means.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Just walk in, sit down, and lurk. Don't write code, just read code. Analyze what patches do. Start small.
You don't have to be friends with developers, but you shouldn't be trying to make enemies. You're dealing with highly rational people here, so keep a level head. Don't bug a developer about what a piece of code does until you study it thoroughly, and don't be surprised if they'd rather tell you about what it's supposed to do instead of what it currently does.
~ C.
~ C.
It is likely Not Sure's brother. So he must be pretty smart.
Of course it's no picnic to become a major Linux coder. It takes two luncheons, a dinner date, three nonconsecutive brunches, and an order of take-out to do that!
Demanding constant attention will only lead to attention.
Actually, the parent was slightly overgenerous, because he mentioned only the case of Batman being a wholly nice guy (implied).
The bigger problem occurs when Batman is a regular human with a large ego and a dislike for NIH code (or worse, Not Invented By Me code), rather than an objective engineer fully willing to accept that another developer has come up with something better.
Although we heard about one high-profile case recently where this happened, with an outcome that was more political than based on engineering merits, in a project that receives patches from thousands of developers on every release this must be happening *A LOT*. Developers with egos are fairly common after all.
It's a sad indictment of people, and while "F/OSS can take care of itself" is a common response, it doesn't really address the fact that some good ideas are being lost or marginalized by lead developers' occasional small-mindedness, and that as a result, overall kernel progress is less good than it might be. "Stability" is a very worthwhile goal and can be a good reason for rejecting a contribution, but sometimes the same word is used to hide a very ugly personal failing of the assessor.
Although coming up to speed technically can involve a lot of work, it is at least a fairly predictable process. The larger and more mysterious challenge is figuring out how to get things done within a project's culture and bureaucracy. This entails figuring out who the powers-that-be are for different aspects of the project, what their preferences are (whether justified or capricious whim), and what kinds of submissions they will accept.
Recall, for example, the Linux CML2 fiasco. Eric Raymond is a bit on the obnoxious and arrogant side, IMO, but even without looking closely at CML2, I'm ready to believe that it was probably a worthy improvement to the Linux kernel. But nonetheless it got nixed, and apparently not for technical reasons. I'm sure he found this quite frustrating.
In my experience with Open Source projects, I notice that I often have luck getting patches that fix clearcut bugs in. Patches that fix broken design points, even exceedingly minor ones, are more problematic, perhaps because they're not seen as worth the bother, or because the PTB are simply used to the way things are, NIH syndrome, etc.
Major changes are even worse, as they present a serious challenge to the self-evaluation of the people that created the system being changed. I'm reminded of a quote: Don't worry about people stealing your ideas. If your ideas are any good, you'll have to shove them down people's throats.
"Not an actor, but he plays one on TV."
Can you explain your point of view with a car analogy, please?
The summary says Major Coder, but I thought this was about the wannabe Colonel Coder? Makes more sense to be Major Geek or General Failure, than Major Coder. Could even be Private Variable, but that guy doesn't get much exposure since he's always out of scope.
Firstly, this applies to any project out there. Secondly, it applies to people already in the team. I run a project and have persuaded the main contributors (ie those with CVS write access) tp prefre many small changes to one big blob. It's easier to follow what has happened in CVS for one thing, and it's easier for other devs to scan through the auto-diffs on the mailing list.
SJW n. One who posts facts.
Simply Photoshop yourself into a few choice picts with Linus and start blathering on about "spin locks" or some such stuff...
It must have been something you assimilated. . . .
Call me a "purist", but I just don't have the time or inclination to re-compile my kernel. I did it many years ago to save a few kilobytes of memory when it was at a premium, but these days, why?
It's not just about memory, disabling build of unneeded functionality improves stability and security.
Why building Linux?
The fastest answer I could get was
- because we can.
Even if windoz users would like to compile their kernel to diminish bloatware, they cannot.
I thought 4 out of 5 serial killers prefered using Reiser FS...
Wouldn't that make it's overwhelming acceptance in teh lunix community almost a fiat accompli?
So in other words, your reputation is more important than your actual work -- doesn't matter how good you are, if you haven't kissed the right asses, it won't matter. Just like PHB-land.
You couldn't say it better.
Too bad most people don't understand how opensource software development works.
to pick up both the knife and the fork...
MS is taking notes. Expect next attack from MS satellites and business partners real soon.
Although in some cases I've seen code that's more or less like this
So the Linux kernel is developed like every major software project that's ever existed.
How completely and utterly unremarkable.
bah humbug! i say fork the kernel and use whatever suits you. not whatever suits the torvalds guy.
disabling build of unneeded functionality improves stability and security.
I'd have to disagree here. It only improves stability and security if you're willing to keep up with all the endless patches and devote a lot of time towards understanding each patch (and possibly back porting it yourself). Do YOU want read every single kernel patch and decide if it's relevant to you? I don't. That job is best left to people devoted to kernel maintenance, like a team of people at (insert distribution).
AccountKiller
Relativistic physics "quite difficult" claims Stephen Hawking.
Rocket Science "harder than you might think" says NASA chief.
"It doesn't cost enough, and it makes too much sense."
Astro-physics is hard
There are very few newbies who will outright need to bug Linus for answers. There are sufficient people that will give "good enough" answers for most newbies on the many newsgroups/lists. Most people will be starting in the shallow end of will start there.
Engineering is the art of compromise.
I wonder if they even want to make it any easier.
McCain/Palin '08. Now THAT's hope and change!
I'd have to disagree here. It only improves stability and security if you're willing to keep up with all the endless patches and devote a lot of time towards understanding each patch (and possibly back porting it yourself).
How long don't you build Linux?
I was talking about enabling/disabling kernel features using kconfig. Every Linux feature (symbol) has a nice description about it, you can easily choose if you want it or not. If the description is not explicit, you can always have a look at Documentation/
If I don't use KEXEC, why would it be builtin?
This is the correct place for my quote:
- disabling build of unneeded functionality improves stability and security -
Do YOU want read every single kernel patch and decide if it's relevant to you? I don't. That job is best left to people devoted to kernel maintenance, like a team of people at (insert distribution).
Why read every single patch?
When you upgrade your kernel, new features are marked with *NEW*. A quick look at the changelog will also give you an idea about what happened.
I'm sorry, but spending 10 minutes building Linux in every version bump is not a *huge* effort.
"Grow up, kid, and learn how we grownups do stuff, and then later when you've built yourself a name and a reputation, and you can be trusted to write code for the masses, we'll let you play in our sandbox."
I guess what goes around comes around.
Any reason it's not just a .ko? If there's some other code that can't be extracted, then maybe you can submit that separately so you can just plug in your module when you need it.
the feature that Linus complains about being missing in that link (configuring alt+right click to resize the window) is still unavailable today, and it's also the "tipping point" that made me decide not to use Gnome at all on my own computers.
Perhaps Linus will change his mind about monolithic vs micro kernels. He's basically making Tannenbaum's case for him.
How the hell is Reiser posting from prison?
rather than just blindly compete or individualism
that's make his success
we don't need one super-human
we want a dream team
Making it easy to contribute to an open source software project is really important. The Linux kernel is veering further and further from that goal: it's highly complex, with lots of coupling between modules, it's written in a language with almost no abstractions, and it has almost no runtime checks.
woosh.
'scuse me, but does this have to be said? You don't come into a new project and take the lead of a critical component. Duh. Really? Usually I hand the guy of who I know nothing but some nickname the responsibility of making-or-breaking my project...
Is that some sort of consultant thing? Everyone knows that it's right, but it has no merit until His Holyness blessed it?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
There are third party patches to vanilla kernel which increases stability (and maybe security). Almost all mainline distros have changes to vanilla kernel of their own. Also there're patches which are quick fixes for some problems and take weeks to land in vanilla kernel. These after proper testing goes to distro repos as a new revision increased kernel. I guess that's what P meant about reading patches.
The free BSDs have had this problem from day one - they're much more clique-oriented, and even the contributors on the fringes are people sufficiently willing to lick the boots of the cadre of heroes.
My main experience has been with FreeBSD, where you're lucky if you even find adequate documentation for some of the kernel interfaces. The secret, in case it's not already obvious, is to know someone who already knows, who in turn learnt from someone else... this worked adequately before humans had invented the written word, but we've moved on, ok? Before I get "the best documentation is the source" - no, you amateur egoists, it isn't, because:
(1) That ruins the strict separation between interface and implementation - i.e. what I should be allowed to assume and what may change.
(2) Documentation doesn't just tell you what functions take what parameters, it provides a thorough workout on motivation, concepts, good practice, gotchas, optimisation, etc.
(3) It's time-consuming an error-prone. Taking the approach ad absurdum, one should learn assembler by looking at a Core2Duo circuit diagram.
If you have to look at the source to understand something, then there is a documentation deficiency. So, it's the required last resort, but any time you've had to do this, you should be requesting/supplying a documentation update.
The lack of good documentation and the consequent strict separation of interface/implementation is what makes it increasingly harder for new and existing coders, and it's a gross deficiency. Everyone ends up having to understand and keep track way more than they should need to. I've run Linux since 1995, NetBSD since 1994, and while the latter was already a complex mess of history, it's really sad to have seen the former had its barrier to entry raise year on year, even though good practice could have prevented this.
Every Linux feature (symbol) has a nice description about it, you can easily choose if you want it or not.
Yes, I've built a kernel before, many in fact. I gave it up after deciding that understanding how each kernel piece goes together and understanding all the dependencies was just too much work.
Why read every single patch?
Because it just might be a critical security patch? Or maybe it's a critical stability patch? Or maybe it's just a patch that might DECREASE stability and security? Who knows? People who's job it is to know (which isn't me, and from what it sounds like isn't you either)
When you upgrade your kernel, new features are marked with *NEW*
And are the new features compatible with the rest of the OS? It's not going to say in the release notes.
I'm sorry, but spending 10 minutes building Linux in every version bump is not a *huge* effort.
You're right, spending 10 minutes on building a kernel isn't a *huge* effort. But 10 minutes is also going to get you a very poor understanding of what went into this release. People who maintain kernels for a distribution will have an in-depth understanding of the kernel, the relevant patches, and which releases are "good" releases (and compatible with the distribution). They also do testing testing testing. That's what you need to do to compete with a distribution built kernel. I'd call that a *huge* effort.
If you like doing it, great. Just don't try to tell me you're going to get some greater stability and security without going through a lot of effort.
AccountKiller
...to pay your $699 licensing fee you cock smoking teabaggers!