Linked by Thom Holwerda on Sat 28th Jul 2007 09:04 UTC
Linux "People who think SD was 'perfect' were simply ignoring reality," Linus Torvalds began in a succinct explanation as to why he chose the CFS scheduler written by Ingo Molnar instead of the SD scheduler written by Con Kolivas. He continued, "sadly, that seemed to include Con too, which was one of the main reasons that I never [entertained] the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them." He went on to stress the importance of working toward a solution that is good for everyone, "that was where the SD patches fell down. They didn't have a maintainer that I could trust to actually care about any other issues than his own." Update: OSNews user superstoned pointed us to the other side of the story.
Thread beginning with comment 258925
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

Part of being a maintainer is saying no. In fact, good maintainers might say no a lot more than they say yes. When they're two competing solutions to the same problem, the maintainer certainly has to say no to a least one of them. The goal is not to hurt anyone's feelings, but to keep the project moving in the right direction for most users.

This isn't grade school. Just because you spend a whole bunch of time toiling unpaid on some code doesn't imply that you're entitled to get your code merged. You don't get brownie points for being a good guy or trying really hard. Code doesn't get merged on the grounds that everybody deserves a chance to contribute.

Code gets rejected all the time, and developers almost always take it in stride. Sometimes they make a fuss, and you can't have that in a mature project. If the developer won't stop complaining, the maintainer might have to take them down a peg in order to put out the flames.

The maintainers of Subversion did an excellent talk on people management in open-source projects where they stressed the importance of removing poisonous personalities from your project. Sometimes you have show good developers the door if they can't work appropriately in the context of the project as a whole. At the end of the day, the project is more important than any single developer, however productive and talented they might be.

Maybe SD is better in some respects while CFS is more consistent overall. But the primary reason why Linus chose CFS is because Ingo is a very reliable and experienced maintainer who's had at least twice as much code rejected than Con has ever submitted. He won't take his ball and go home, whereas CK apparently will.

Finally, plugsched is a bad idea because scheduler proliferation is evil. There wouldn't be just two or three schedulers, there would be ten, each one representing a major configuration that needs to be tested. Anyone can write a scheduler that's optimized for a particular workload, but that defeats the purpose. The scheduler should perform consistently in a variety of workloads.

I hope that SD lives on as a patchset for those workloads that benefit from it. But one solid scheduler is all we need in the mainline kernel. CFS is the right choice for the long haul. We'll all benefit from the improvement over the O(1) scheduler, so we should be happy.

Reply Parent Score: 5

gpierce Member since:

Con Kolivas' personality is "poisonous" or his work poisoning the kernel? Are you serious? This guy, more than any one else, brought to attention and a solution to the problems of desktop performance. Linus is human--a high-acheiving one, driven by ego and reputation--and his behavior in this matter is observable in most individuals who acquire national prestige and reputation when they are threatened. They first actively seek to find fault on technical grounds, decline to allow wider testing of alternative ideas and methods (in Con's case--disallowing entry into the mainline kernel), and when that fails attack the individual as being unstable, untrustworthy adducing any vocalized frustration on Con's part as proof of their unsuitability.

Reply Parent Score: 6

butters Member since:

He's doing the rounds on the interview circuit, explaining that computers are dumb and boring, and how there's a vast right-wing conspiracy to make Linux unsuitable for desktop users. He's telling people that he has solutions to a variety of problems with desktop operating systems, but nobody will listen to him. The fact that the kernel community rejected his work is apparently a slap in the face to Linux desktop users.

This is, at best, bad advocacy. He's coming off like those whiny kids that go on talk shows defending that movie on how 9/11 was an inside job. Maybe they're right. I don't know. But they moan and groan and stomp their feet and nearly break out in tears when the guy from Popular Mechanics tries to calmly refute their theories. It's impossible to believe them because they just can't control their frustration.

That's poisonous personality. It means you don't get what you want, even when you're right. It means that other hackers working on desktop performance issues cringe in embarrassment that this guy is representing them in public. This isn't how Linux kernel developers are supposed to act. The kernel community should not encourage this kind of behavior.

The Rubik's Cube kid that screwed up solving the cube blindfolded on national television and got really upset. Nobody thinks he sucks at Rubik's Cube, but he might have more fundamental shortcomings.

EDIT: It was a close call, and a decision had to be made. There wasn't a definitive argument for either solution, but it doesn't make sense to merge both. Somebody was going to get pissed off. Linus ended up pissing off the developer who would get most pissed off and who has the more vocal supporters.

Would there be outcry if SD was chosen over CFS? We'll never know, because in the end, Linus made what he thought was the safe decision. A lot of people are unhappy, and I'm not sure that was avoidable. That's my final comment on this issue.

Edited 2007-07-28 14:01

Reply Parent Score: 5

AdamW Member since:

"decline to allow wider testing of alternative ideas and methods (in Con's case--disallowing entry into the mainline kernel)"

sorry - you consider the mainline kernel an appropriate place for "testing of alternative ideas and methods"?

Reply Parent Score: 2

ShawnX Member since:

I'm going to take issue with this 'maintainer'. One, Con had lots of people testing SD, including myself. I myself provided feedback to Con on IRC. Second, your excuse that 'scheduler proliferation is evil' is stupid. In fact, we should have more pluggable mechanisms in the kernel to allow for greater testing capabilities. I'm truly ashamed to see Linux development go down the drain in the same direction as closed-like projects do with their closed mind, closed attitude towards developers.

Edited 2007-07-28 18:54

Reply Parent Score: 3