Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Torvalds Says It's No Picnic To Become Major Linux Coder

CmdrTaco posted about 6 years ago

Operating Systems 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.""

cancel ×

222 comments

Sorry! There are no comments related to the filter you selected.

first post (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#24644953)

cowboy neal has tips on being a big developer!

First Post (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#24645015)

Looks like the First Post. Does the NEW Kernel run on linux? j/k, It would be great to get inot helping the OSS More with donating my time to development, but i feel that im not a good enough programmer to even handle that. Im mean sure, Ive done some C/C++, and some OpenGL. Right now All I do is ASP .Net and C#.
Hey Torvalds: What IDE do you use for writting Code? Or are you hard core and use the vi?

Re:First Post (-1, Flamebait)

Anonymous Coward | about 6 years ago | (#24645487)

It would be great to get inot helping the OSS More with donating my time to development, but i feel that im not a good enough programmer to even handle that.

Then shut up, give up life, and become a MacFag(tm) because you're good at being chatty.

huh (3, Insightful)

nomadic (141991) | about 6 years ago | (#24645055)

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.

Re:huh (3, Interesting)

Carlos Matesanz (1344447) | about 6 years ago | (#24645179)

I Agree. Coding a kernel is not trivial, we all know that. But sometimes it seems that core devs in Linux kernel are so self-sufficient they don't want anyone else really involved in the project. Or at least that's the opinion i've extracted along the years from mailing lists, interviews and whatnot. It's a luck they have been doing a good job until now.

Still easier than coding the Windows Kernel (4, Insightful)

fictionpuss (1136565) | about 6 years ago | (#24645361)

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?

Re:Still easier than coding the Windows Kernel (2, Interesting)

Carlos Matesanz (1344447) | about 6 years ago | (#24645689)

That's not a problem.
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.

Re:Still easier than coding the Windows Kernel (4, Insightful)

cervo (626632) | about 6 years ago | (#24646511)

As further evidence of the egos, remember when Linus attempted to contribute the patches to Gnome as part of the Linus versus Gnome war?

http://www.desktoplinux.com/news/NS8745257437.html [desktoplinux.com]

Anyway he didn't start small at all. Go Ego :)

Re:Still easier than coding the Windows Kernel (1)

x2A (858210) | about 6 years ago | (#24646595)

"I've fixed my scheduler so it does blah-blah... include it?"

*tap* *tap* *tap*

"ah it's okay, I see your improvement ideas, and I've added it to my schedular instead..."

I do have to say I agree - sometimes that does appear to be the case.

Re:Still easier than coding the Windows Kernel (2, Insightful)

Poltras (680608) | about 6 years ago | (#24645721)

By the time you are working on the Linux kernel as a contributor, you'd have accumulated enough knowledge/experience to get employed at Microsoft. I think at that point, it's more a matter of ideology.

At Microsoft, working on the kernel pays as a fulltime job, while you still have to find a way to get money if you're just working on the Linux kernel as a hobby. And if you can get employed by some corp to get paid working on the Linux kernel, I'd think their employment standards would be comparable to MS's.

Re:Still easier than coding the Windows Kernel (5, Funny)

Anonymous Coward | about 6 years ago | (#24646397)

At Microsoft, working on the kernel pays as a fulltime job

They pay monkeys to bash keys nowadays?

Re:Still easier than coding the Windows Kernel (1)

x2A (858210) | about 6 years ago | (#24646631)

only named monkeys, not AC's unfortunately for ya :-(

Re:huh (1, Flamebait)

Swizec (978239) | about 6 years ago | (#24645221)

In other words the Linux kernel is opensource merely on paper. In practice it's developed by a close group of developers who don't let anybody in and write code practically nobody but them understands.

I'm certain it's easier to become a major Microsoft developer because they'll at least give your resume a read, the linux guys blow you off a priori.

Re:huh (5, Insightful)

dutchd00d (823703) | about 6 years ago | (#24645541)

Bullshit. You can download the source code, make any changes you want and publish your own version without restrictions. That's the definition of open source, so the Linux kernel most definitely qualifies. The fact that it's hard for you to get your changes into Linus' kernel tree has nothing to do with it.

Re:huh (4, Insightful)

Skreems (598317) | about 6 years ago | (#24645613)

While I don't agree with your current flamebait mod (you bring up a very common criticism of open source) I do think you're wrong.

Nothing in open source has ever guaranteed that you get to contribute directly to a specific project. When a specific group of developers is maintaining a release (Linus et al, in this case) it's absolutely up to them what code gets in and what doesn't, and who they will accept contributions from. What open source guarantees is that when they make that release, you're free to take the source code they've created and modify it in any way you choose. You're free to fork the project and maintain releases just as strictly as they did, or open it up to all newcomers.

I think you'll find, though, that opening it up to any unknown person right off the bat will trash your project pretty quickly. The problem is, there are hugely varying ideas of what constitutes "correct" code and architecture, and it's just a fact that it takes time to prove that you understand what that means in terms of a large project such as this.

Re:huh (-1, Troll)

Anonymous Coward | about 6 years ago | (#24647319)

Open Source is largely ego driven. Assholes like Torvalds and Stallman should make that clear to you.

Re:huh (5, Insightful)

mea37 (1201159) | about 6 years ago | (#24645617)

I disagree. I think you have the wrong idea about what "open source" means.

Open source pertains to the code base, not to any particular repository of the code. You are quite free to read, modify, and redistribute (with modifications) the code. You cannot compell Linus to incorporate your changes into his version, any more than he can compell you to revert a change from your version.

That Linus has a widely-respected "official" version is a moot point. It really just means he has an audience for his product (i.e. the version of the code he/his team host), and you may not have one for yours (a modified version you create but which isn't accepted as part of his product).

Much like free (as in speech) speech, open source doesn't guarantee you that anyone will listen (where "listen" in this context means "run your version of the code").

As for MS -- well, getting a job at MS isn't the same as getting a job that lets you make major modifications to the Windows kernel. I'd say the sitaution with regard to the high-profile products (i.e. Windows on oen hand, the "official" Linux kernel on the other) is about the same. The difference is that you can't modify Windows without being part of the official team. Not to distribute (even if you can find an audience for your work). Not even for your own personal use. That's the difference between open and closed source.

Re:huh (3, Informative)

BPPG (1181851) | about 6 years ago | (#24647353)

http://janitor.kernelnewbies.org/ [kernelnewbies.org]

Maybe this will answer some of your questions. But yes, and it's good that the linux kernel doesn't operate like wikipedia, for obvious reasons.

Re:huh (5, Insightful)

LWATCDR (28044) | about 6 years ago | (#24645403)

Nope.
It is hard because.
1. Programming is hard.
2. System's programming is even harder.
3. Kernel code is mission critical code which is really hard.
4. When you are the new person it takes time before people trust that you know what you are doing.

In other words it is just like everything else. The difference is that if you want to make changes to your Kernel you can. If you want to put up a site with your patches you can.
If you want your code adopted in the "official" kernel you have to play by the rules and write good code.
So it works exactly as it should and really can not work any other way.

I have two words for you, sir: (-1, Offtopic)

doti (966971) | about 6 years ago | (#24645547)

A-fucking-MEN!

mod this up ^^^^

Re:huh (5, Insightful)

mr_mischief (456295) | about 6 years ago | (#24645697)

One additional point: don't try to take over a whole subsystem in one rewrite. Contribute small patches that are easily reviewed to get your feet wet and get noticed. Then, as you're better known and respected within the community, start scaling up your contributions.

It works the same way in any open source community. The new guy who rewrites half the code all at once isn't going to get a review of his code. Show that you can do the small changes right first.

Actually, it works this way in almost any cooperative group. You don't show up to your first meeting at Kiwanis, the Jaycees, or the Lions and start making resolutions. You don't sit in on drums once for a band and start telling them how to write songs. 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.

People who think they should suddenly be in charge of a large portion of an established organization they've just joined are showing signs of detachment from society or megalomania. If you've never contributed anything worthwhile, you're nobody special compared to the people who have been doing the work. Don't expect to be a big part of a group without being a small part first. Some people move up the ranks faster than others through skill and hard work, but everyone pays some dues.

Re:huh (4, Insightful)

LWATCDR (28044) | about 6 years ago | (#24645991)

And the honest truth is that.
Unless you are some kind of super prodigy or have years of experience writing systems code odds are your complete subsystem rewrite is total junk.
It takes time to be good at anything.

Re:huh (1, Insightful)

Anonymous Coward | about 6 years ago | (#24646571)

I was going to mod you up but I thought you'd appreciate it more if I just replied. As simplistic and common sensical as what you said is, you have really given this socially stunted nerd reason to pause. Your post rings so true in my experience that I'm almost literally stunned. Often I've wondered why people don't just "shut up and do it my way". I mean, I know better right? I'm the genius nerd here right? Well, yeah, all of that may be true but people don't work like that. As you've said, you have to establish yourself, you can't just come in and start calling the shots day one even if it is something related to your core competency. I have made a note of your post, paraphrased a little, so that I can refer reflect on it at length. Just wanted to say thanks.

Ladies and gentlemen, this is why I read Digg for the articles and Slashdot for the comments.

Sadly, logging in AC due to the irrepressible sappiness of my post.

Re:huh (-1, Flamebait)

Anonymous Coward | about 6 years ago | (#24646159)

It's hard because the code is a poorly designed mess. Massive egos and flamefests discourage others from wasting their time.

Re:huh (4, Insightful)

v(*_*)vvvv (233078) | about 6 years ago | (#24646407)

I am no kernel developer, but I think Linus is getting at why "it works exactly as it should and really can not work any other way" has some demerits, and that it not being able to work any other way is why we are in a fix.

In other words, it works as it should, but it is very slow, so how can we improve the process and make better patches faster?

If the answer is that there is no better way, then that is a sad awakening for a lot of us, because it means precisely that Linux isn't going anywhere sooner than it has since the current state has been established.

But there has to be a better way, and I think Linus is trying to find it, as are many others.

Re:huh (2, Interesting)

LWATCDR (28044) | about 6 years ago | (#24646909)

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.

Re:huh - You said it all. (0)

Anonymous Coward | about 6 years ago | (#24647251)

You couldn't say it better.

Too bad most people don't understand how opensource software development works.

Re:huh (3, Interesting)

Seakip18 (1106315) | about 6 years ago | (#24645515)

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:huh (4, Informative)

fishbowl (7759) | about 6 years ago | (#24646131)

>Would you let a doctor fresh out of med school slice and dice in heart surgeries?

Yes, if that was their residency specialty. Do you know much about med school matriculation?

Re:huh (1)

Seakip18 (1106315) | about 6 years ago | (#24646253)

Just what little I've gleaned off my 3rd year friend. The reference isn't literal. I just figure you don't let a recent graduate start removing and inserting hearts into patients, kinda like "Oh..So how long have you been doing this? Ah...this is my first time."

Re:huh (1)

jahudabudy (714731) | about 6 years ago | (#24646917)

Completely off-topic, but that is exactly how it works. I mean, the doctor hopefully wouldn't mention it to the patient, but OF COURSE all surgeons have a first time they perform any surgery. And for a lot of things, the only way to "practice" is on humans. So if we want there to be experienced surgeons in the future, we have to let inexperienced surgeons "practice" on someone today...

Re:huh (5, Insightful)

moderatorrater (1095745) | about 6 years ago | (#24645645)

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.

Re:huh (1, Interesting)

Anonymous Coward | about 6 years ago | (#24646551)

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 (5, Funny)

b4dc0d3r (1268512) | about 6 years ago | (#24645677)

Mod parent down. I don't recognize him, therefore he can't know what he's talking about.

Haven't heard of him. (4, Funny)

Neuroelectronic (643221) | about 6 years ago | (#24645079)

Who is this No Picnic fellow? I don't believe there is a new major Linux contributer.

Re:Haven't heard of him. (4, Funny)

Barsteward (969998) | about 6 years ago | (#24645243)

Me neither but maybe he's one sandwich short of a picnic to want to become a major kernel developer, i heard it helps

Re:Haven't heard of him. (0)

Anonymous Coward | about 6 years ago | (#24645353)

I think he's related to the Slashdot user New Here [slashdot.org] .

(Exactly what I thought, too. Why do the /. editors always make the titles so friggin' hard to parse? e.g. MagLev, Ruby VM on Gemstone OODB, Wows RailsConf [slashdot.org] )

Re:Haven't heard of him. (1, Funny)

Anonymous Coward | about 6 years ago | (#24645993)

That isn't so hard to parse. MagLev, which is a Ruby Virtual Machine running on Gemstone Object Oriented Database, impresses people at the Rails Conference.

Wow! I R SMART!

Re:Haven't heard of him. (0)

Anonymous Coward | about 6 years ago | (#24645593)

He's the guy who made the new PCI subsystem...

Not Sure's brother (1)

dunc78 (583090) | about 6 years ago | (#24646009)

It is likely Not Sure's brother. So he must be pretty smart.

Re:Haven't heard of him. (2, Funny)

jonaskoelker (922170) | about 6 years ago | (#24646231)

Who is this No Picnic fellow?

I found some old army personnel files, containing references to a Sgt. Linux Coder. I think No Picnic is his new codename.

"No Picnic to Anthill. No Picnic to Anthill! Come in, Anthill! I've spotted several enemy pointers, sir! They're marching rank and file system straight to our intelligence page table. Shall I noexecute them, sir?"

Re:Haven't heard of him. (3, Funny)

jonaskoelker (922170) | about 6 years ago | (#24646549)

It has been said that:

TFA is a wholly remarkable book. It's already supplanted Operating Systems: Design and Implementation as the standard repository of all knowledge and wisdom, for two important reasons. First, it's slightly cheaper; and secondly it has the words DON'T PICNIC printed in large friendly letters on its cover.

;)

Wow (1)

kraemate (1065878) | about 6 years ago | (#24645091)

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.

I gave up a few times (5, Informative)

EmbeddedJanitor (597831) | about 6 years ago | (#24645153)

I considered, and once tried, pushing a file system into Linux. Unfortunately the fs does not have the right coding style and a few other things which make it hard to put into mainstream. Instead it just sits independently as a big patch which is pretty easy to apply by running a simple script.

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.

Re:I gave up a few times (3, Insightful)

Vellmont (569020) | about 6 years ago | (#24645379)


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.

It sounds like your FS serves mostly a niche that isn't served by the mainline FSs. 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? If you don't care about keeping up on kernel patches and have some specific needs that aren't supplied by the mainstream kernel, then re-compiling is fine. But if not, then the mainstream kernels (vendor provided) wind up being a lot easier to work with.

Re:I gave up a few... - Build Linux because we can (1)

miknix (1047580) | about 6 years ago | (#24647069)

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.

Re:I gave up a few times (1)

x2A (858210) | about 6 years ago | (#24647407)

meh, depends how you work. I run stuff that's out of tree. Changing a few settings and recompiling takes no time at all, cuz I have source code for everything in place. With a binary distro installed (as in, without all the dev packages / srpms) yeah, recompiling stuff is a PITA, which is why I avoid them like the plague. Whether it's getting vmware-any-any to work, using clustered block devices, out of tree graphics drivers, or changing configuration to stop some random locking problem from cropping up and grinding all the cpu's to a halt during ext3 writes, it's -real- easy, because everything's in place to do it.

If you run a system with seperated dev packages that may or may not all be installed then naturally things like that are gonna be complicated.

Re:I gave up a few times (1, Informative)

Anonymous Coward | about 6 years ago | (#24645963)

I considered, and once tried, pushing a file system into Linux. Unfortunately the fs does not have the right coding style and a few other things which make it hard to put into mainstream. Instead it just sits independently as a big patch which is pretty easy to apply by running a simple script.

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.

Honestly, you don't sound like a developer who just developed this great file system that everybody needs. If it doesn't follow the kernel coding style, it was most likely developed for a completely different operating system, and you just tried to get it merged after it was open sourced. And a script is needed to merge it? Nope, not even trying to get it merged. If you're doing development outside the kernel tree, people really need to be able to "git pull" your latest updates. People doing development "in-tree" can get away with regular patches (not scripts!), but for a file system, that's simply not going to work. Look at Reiser FS. The kernel was always behind, and often far behind. Because it came as big chunks.

Re:I gave up a few times (2, Funny)

SpooForBrains (771537) | about 6 years ago | (#24646227)

Although I might consider mainlining it again

Don't! A recent study found that kernel hacking is fifty time worse than heroin.

Re:I gave up a few times (1)

TheRaven64 (641858) | about 6 years ago | (#24646485)

Out of interest, have you tried getting it accepted in any other kernels (*BSD, Solaris, and so on)? If not, have you ported it to use FUSE?

Core demographic? (0)

Anonymous Coward | about 6 years ago | (#24647109)

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?

Re:I gave up a few times (0)

Anonymous Coward | about 6 years ago | (#24647159)

FUSE???

In other news... (4, Funny)

Dorkmaster Flek (1013045) | about 6 years ago | (#24645159)

Kernel development is hard! Film at 11.

This goes for every OS/FOSS project out there. (5, Insightful)

scenestar (828656) | about 6 years ago | (#24645169)

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.

Re:This goes for every OS/FOSS project out there. (0)

Anonymous Coward | about 6 years ago | (#24645493)

Hey, who you callin a Stalinust??

Re:This goes for every OS/FOSS project out there. (4, Interesting)

houghi (78078) | about 6 years ago | (#24645781)

I am sure this goes for closed source as well. If the rookie comes in, he will also have to prove himself. The same goes for every other aspect in life.

If are new into a group, it is to be expected that you have to prove yourself. Whether this is with your local gang, a family you are married into or a bunch of coders is irrelevant.

Even Neo had to prove himself first. Each group will have its own rules and speed of how fast you are accepted. A group of drunk people in a bar might have a lower standard, but if you do not fit in, they will not accept you and will not listen to your sugestions, no matter how wise they are. (Stop drinking? Why? This is FREE BEER)

Re:This goes for every OS/FOSS project out there. (1)

rdavidson3 (844790) | about 6 years ago | (#24646975)

I think this would even be harder with closed source. You haven't seen the code prior to doing any work with it, whereas you can read the open source at any point before working on it.

Re:This goes for every OS/FOSS project out there. (1)

dedazo (737510) | about 6 years ago | (#24646351)

Actually this is true for any non-trivial code base, enough of which exist in the commercial software world. There's nothing particularly specific here to the Linux kernel or open source for that matter.

Re:This goes for every OS/FOSS project out there. (0)

Anonymous Coward | about 6 years ago | (#24647245)

Linux kernel development requires a Stalinist approach

Er, no. Stalin didn't give his "team" a choice in whether or not to "participate". This is truly a case of apples and oranges.

You cannot logically compare a voluntary project (initiated out of free will, not coercion), with government of ANY type (let alone one of the most unjust, murderous regimes in history).

Learning the rules (4, Funny)

Fnord666 (889225) | about 6 years ago | (#24645291)

"...and it inevitably simply takes time to learn all the rules..."

  1. Linus is always right
  2. If in doubt, see rule #1

Re:Learning the rules (4, Insightful)

Chris Mattern (191822) | about 6 years ago | (#24645399)

Yes, but trick is that since you can't constantly be bugging Linus for all the answers, you have to know what his opinion is without asking him. That's the tough part.

Re:Learning the rules (4, Funny)

SlipperHat (1185737) | about 6 years ago | (#24646741)

Yes, but trick is that since you can't constantly be bugging Linus for all the answers, you have to know what his opinion is without asking him. That's the tough part.

Skills required in Linux kernel development:
...
Mindreading
...

Allegiances (5, Insightful)

Anonymous Coward | about 6 years ago | (#24645323)

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?

Re:Allegiances (4, Insightful)

fictionpuss (1136565) | about 6 years ago | (#24645517)

Am I right or am I right?

You're a tautology.

But let's take your unproven hypothetical as given for a second. If these sorts of decisions are being made, which provide technically inferior solutions for the Linux kernel.. then over time it will become obsolete.

But way before then we'll all be using the nuLinux kernel which has all of "The Joker"s fancy code.

In other words, F/OSS can take care of itself; we're just the dumb monkeys hitting random keys.

Batman sometimes has an ego (3, Insightful)

Anonymous Coward | about 6 years ago | (#24646061)

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.

Re:Allegiances (1)

Spatial (1235392) | about 6 years ago | (#24646669)

You're a tautology.

I think it's more like an excluded middle, except he just thought "What the hell," and excluded the the sides too while he was at it. :)

Re:Allegiances (0)

Anonymous Coward | about 6 years ago | (#24647475)

I think the correct (or expected) answer is:

Batman reads Joker's code and rewrites it Batman-ish, while modifying some parts "for greater goods" (he's Batman, after all!).
Commits (t)his new lovely Completely Batman Sheduler and lives happily till death (or until new Mr. Freeze comes).

Re:Allegiances (5, Funny)

KasperMeerts (1305097) | about 6 years ago | (#24645671)

You forgetting these are full-time kernel developers. They would offer their firstborn son in exchange for a 0.049% better scheduler if they could ever have partners.

Re:Allegiances (1)

russotto (537200) | about 6 years ago | (#24645811)

What happens if:

1. Batman is more or less responsible for a big chunk of the kernel, e.g. the scheduler.

  No fair using a counterfactual which is actually factual. That incident certainly shows that the process is broken. Just how many years do you have to work on a major kernel section and have your code out there being run by actual users in favor of the mainline before you're trusted?

Re:Allegiances (4, Funny)

bigstrat2003 (1058574) | about 6 years ago | (#24645849)

3. The Joker writes a new improved scheduler which has the potential to replace the old one.

when (process.wantsToRun) {
retort(process, "Why so serious!?");
kill(process);
}

Very efficient. I like it.

I don't get it (5, Funny)

papabob (1211684) | about 6 years ago | (#24646569)

Can you explain your point of view with a car analogy, please?

Re:I don't get it (1)

Neuroelectronic (643221) | about 6 years ago | (#24647149)

GM

Andy's revenge (5, Funny)

Stormwatch (703920) | about 6 years ago | (#24645451)

For one thing, the kernel is quite complex and big

If that's the problem, wouldn't it be easier to work on it if it was a microkernel?

Re:Andy's revenge (1, Insightful)

Anonymous Coward | about 6 years ago | (#24645533)

Short answer: no

Re:Andy's revenge (4, Funny)

gardyloo (512791) | about 6 years ago | (#24645685)

Long answer: Fuck no.

    (From Stephen Fry)

Re:Andy's revenge (0)

Anonymous Coward | about 6 years ago | (#24645551)

You, sir, have converted me. I am going to go work on the HURD.

Re:Andy's revenge (4, Interesting)

0xABADC0DA (867955) | about 6 years ago | (#24646313)

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:Andy's revenge (3, Insightful)

serviscope_minor (664417) | about 6 years ago | (#24647031)

If that's the problem, wouldn't it be easier to work on it if it was a microkernel?

Yes. Fortunately linux is half way to being a microkernel now. I can personally attest that writing a user-space file system (eg in FUSE) is vastly easier and quicker than hacking (let alone writing) a filesystem in the kernel.

The evidence is on my side. Look at how many filesystems Linux supports, and count how many are in FUSE, versus how many are in the kernel.

The Kernel or Applications? (-1, Redundant)

Zombie Ryushu (803103) | about 6 years ago | (#24645491)

Just for the sake of discussion, we are talking about the Kernel, not Applications.

Re:The Kernel or Applications? (0)

Anonymous Coward | about 6 years ago | (#24645607)

"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.

Re:The Kernel or Applications? (1)

Skreems (598317) | about 6 years ago | (#24645663)

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.

It can't be THAT hard (4, Funny)

Rik Sweeney (471717) | about 6 years ago | (#24645505)

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 :)

Re:It can't be THAT hard (4, Funny)

howlingmadhowie (943150) | about 6 years ago | (#24645577)

he's heard of 'free'! quick! someone offer him a job!

Re:It can't be THAT hard (1)

Yetihehe (971185) | about 6 years ago | (#24646119)

It's not so funny when you have 10 programmers surprised to know that they really need to clean after themselves...

Re:It can't be THAT hard (4, Funny)

joss (1346) | about 6 years ago | (#24646273)

at mozilla

Re:It can't be THAT hard (0)

Anonymous Coward | about 6 years ago | (#24646027)

malloc and free are not C keywords!
They're identifiers used in libc. Try again.

Re:It can't be THAT hard (2, Informative)

One Louder (595430) | about 6 years ago | (#24646067)

Too bad "malloc" and "free" aren't C keywords.

Re:It can't be THAT hard (1)

Taagehornet (984739) | about 6 years ago | (#24647067)

Are you thereby implying that ">>", "<<", "++", and "--" are?

Linus is absolutely right (0)

Anonymous Coward | about 6 years ago | (#24645563)

I have to agree with Linus on this one.

mod do3n (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#24645569)

and arms and dick In the s!un. In the a child knows Nearly two years

Wisdumb (5, Insightful)

stonecypher (118140) | about 6 years ago | (#24645591)

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.

It's easy to get involved. (2, Informative)

MostAwesomeDude (980382) | about 6 years ago | (#24646003)

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.

No picnic (2, Funny)

Captain Spam (66120) | about 6 years ago | (#24646015)

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!

and remember (3, Funny)

Fallen Andy (795676) | about 6 years ago | (#24647369)

to pick up both the knife and the fork...

Matching culture is a serious challenge (2, Informative)

mkcmkc (197982) | about 6 years ago | (#24646321)

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.

Kernel Coder? (1, Funny)

Anonymous Coward | about 6 years ago | (#24646603)

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.

It applies more widely. (1)

serviscope_minor (664417) | about 6 years ago | (#24646703)

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.

No problemo. (4, Funny)

fahrbot-bot (874524) | about 6 years ago | (#24646787)

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.

Simply Photoshop [slashdot.org] yourself into a few choice picts with Linus and start blathering on about "spin locks" or some such stuff...

OSS is no different (0)

Anonymous Coward | about 6 years ago | (#24647175)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>