OSNews

LOL. What is wrong with Linux's ACPI implementation?

it depends. is its the kernels job of fixing hardware quirks/bugs in the ACPI support?

hell, at one time linus showed a strong dislike for ACPI as its kinda like a programing language in its own right. this was stated when people started talking about intels bios replacement (the one that apple use in their X86 macs) that had a similar design.

It's the kernel's job to work properly, and to interface well with the hardware. Wether or not ACPI has been implemented badly in BIOSs, you can't just throw up your hands and cry 'it wasn't me'.

maybe so, but dont expect it to magically work fine before the bugs are ironed out...

Having lurked lkml for years... it's incredible that people still want to do stuff for Linus, when he keeps bashing people like he does after they've spent days and nights shipping code to Linux (lot of CK's stuff have been important drivers for improving the kernel). Sure, Linus says people do whatever they want to do and he reserves himself the right to call people stupid and ugly at will. Fine, but to me, he increasingly comes across as narcissistic sociopath (especially after the google techtalk craze).

I don't think it's true that CK didn't take user reports seriously, but at any rate: give the man some credit, Linus!

As far as SD vs. CFS, my experiments shows that SD is indeed better at extremely cpu intensive workloads, while CFS has an edge on mixed workloads. With a decent plugsched and someone taking on the task to maintain SD (now that CK has quit), we should have both in the kernel.

IMNSHO.

>I don't think it's true that CK didn't take user reports seriously

I don't think so too. This is the usual procedure "how to kill a critic" if he dares to open his mouth afterwards. Sometimes I think, they are more about politics than actually technology.

Edited 2007-07-28 10:29

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.

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.

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

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

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

Its the old story of smart people - the smarter they are, something has got to give, they're either, weird, arrogant, strange, violent or some other trait.

I've seen the debates that occur on lkml - and the end of the day its up to you as to whether you wish to contribute and be part of the community. No one is forcing you to join and contribute to Linux - if you don't like how things are going, there is nothing stopping you from forking the Linux code and creating your own community.

Thats the thing; if there was such a major issue with Linus, someone would have forked Linux, created a parallel community. All things consistant, if there was such a dislike for Linus's mannerisms, he would have isolated long ago - so I'm assuming he is doing something right (not that I agree with him or how he holds himself).

On a bigger issue, this is the reason, although qualified in IT, I don't work in it. I don't work in it because of what I've seen and experienced; I definately don't want to work in a place like Microsoft were I am constantly pushed, prodded and probed by upper management, expecting me constantly on the defensive about every decision being made, constantly having to advocate and explain every possible position made then interrogated.

I can see why so few females are involved with IT - this constant agressiveness thats required. For me, I prefer working in a team as a team rather than simply a bunch of individuals who happen to be under the title of being a group. Peoples egos, unwillingness to discuss in a polite way seems to go way over the head of many people as I've seen.

"
I can see why so few females are involved with IT - this constant agressiveness thats required. For me, I prefer working in a team as a team rather than simply a bunch of individuals who happen to be under the title of being a group. Peoples egos, unwillingness to discuss in a polite way seems to go way over the head of many people as I've seen.
"

Oh, so it is REQUIRED now? No, people make it that way. It doesn't have to BE that way. People become aggressive and insulting because they want their way over someone else's way.

I am guessing that Linus is so famous now that the people who work with him and get their faces slapped actually ENJOY getting their faces slapped by "the great Linus."

I've yet to be in a situation where it has been different from the situation described. I say its a biproduct of men in a group sitting around trying to 'out piss' each other. Beating of chests, trying to prove they're the bigger and better alpha male. Its pathetic to see it in action.

I can assure you, having been in a mixed project of male and female you can really see how the dynamics are different. Rather than the leader trying to make a name for himself she instead encouraged and fostered a team atmosphere.

When I look at the IT world its all about ego's, beating of chests and hopeing if one makes enough noise, they win the praise of the leader. Just take a look at Microsoft and how their meetings are conducted - and they wonder why the crapest ideas from the biggest loud mouth are chosen rather than a good idea from the quietly spoken gentlemen at the back of the room who doesn't want to 'rock the boat'.



I wouldn't be surprised; there are idiots here who appologise for Stallmans out of touch rantings no end - completely devoid of reality when it comes to delivering solutions for end users.

Btw, it isn't just limited to Linux - I've seen it in a number of projects. Its sad though that for every 1 loud mouth prick there are atleast 9 people behind the scenes working on what matters rather than trying to get their name in lights or have infamy for being the biggest asshole on the block.

Linux doesn't implements ACPI.

Do you know who is the Linux ACPI maintainer? There're a few programmers being paid by Intel -you know, this little company that invented ACPI- to maintain it.

The fact that the same company that created ACPI can't create a working implementation should give you an idea of how easy is this task and how beautiful is the x86 world.

and the never ending question remains, is it the users job or the systems job of managing tasks?

in either case, CFS (which is also completely fair, just like SD) did make it into the kernel - despite it has the same 'problem' (not being unfairly positive to interactive tasks). So it's pretty silly of Linus to use this 'problem report' as an argument.

If you read a little further in the thread, you'll see some very good and well informed comments, btw.

if linus switched the kernel to con's scheduler, con would take over as maintainer. but with ingo's scheduler, linus could keep ingo as the maintainer, a person he have learned to trust over the years iirc.

in the end, its a executive decision so to speak. people will either love it or hate it, but they will all learn to live with it.

Why would that necessarily mean Con Kolivas would take over as the maintainer? Could he not simply maintain the HIS scheduler? And it would seem to be better for Con, given all the other desktop-related things he was up to.

And this should not be happening in Open Source. What happened to "best code." Ooops....

Seriously I have had this happen to myself. Around 96-97 I ported the Apache server to Windows and wanted to integrate the sources. What happened? I was blasted. Some guy emailed me privately and said the exact same thing happened to him and that I should forget about it.

Now Apache is on Windows, and it was late!

My point is that Open Source should stop making the argument that their software is based on technical merit alone. And that politics plays quite a bit in Open Source.

True, I see your point. But linus should've said THAT, and not give silly and/or uninformed arguments.

And besides, if Linus from now on would never add any new maintainers, Liux would die soon... Con has proven himself over the years as a trustworthy person (no matter how Linus is trying to portray him), and it would allow Ingo to spend time on new stuff...

now that i think about it, isnt there a kind of chain of command?

as in, linus should not have gotten directly involved as ingo is the person in change of that area of the kernel?

also, from what i understand the SD patches where getting kinda massive. and linus iirc hates massive patches (see reiser4 for a similar issue). how big was the CFS from ingo?

Con has proven himself over the years as a trustworthy person (no matter how Linus is trying to portray him),

I used to run -ck patchsets fairly consistently, and I appreciate Con's work, but I don't understand where people get the idea that he's "proven himself over the years." He's a relative newcomer to kernel development. Until a couple years ago, he didn't even know how to code. He learned by resolving merge conflicts as a patchset maintainer. It's a fantastic story of a self-taught developer pulling himself up from his bootstraps.

He's gotten a good handful of relatively modest patches into the mainline, but he hasn't maintained any significant chunks of code. He went straight for the jugular with the scheduler and swap prefetch. These aren't pieces that you can trust to a relatively inexperienced hacker. Not in the Linux kernel, with millions of users, many of them in production environments. Most hackers start by taking ownership of a driver or a non-core kernel service.

There's so much work to be done in the Linux kernel, and the vast majority is relatively accessible for newer kernel hackers. But Con picked a couple of the very few parts that are typically reserved for seasoned kernel hackers for good reason. For one thing, they know how to navigate the kernel community, grease the wheels, and get the job done. They've had all the idealism beaten out of them. They know when it's time to deviate from the theory.

CK may be a hero to the enthusiast crowd, but he doesn't have much credibility in the kernel community. He doesn't appear to be especially trustworthy, either. I'm interested to see what he ends up doing next.

"""
Con has proven himself over the years as a trustworthy person
"""

How's that? He *quit* when he didn't get his way. Compare that to Ingo, who has likely had more code rejected over the years than Con has written, and has never threatened to quit,let alone actually done it.

I'd hardly call that "trustworthy".

Some examples of major work by Ingo being rejected:

http://lwn.net/Articles/242912/

Though I started out pretty neutral, the more I hear from Con and his followers, the more convinced I become that Linus made the right decision by selecting the more reliable maintainer, and the one who understands the importance of acknowledging when a problem might exist in his code.

Like Linus said:

""
This is like alcoholism. If you cannot admit that you might have a
problem, you'll never get anywhere. And quite frankly, the RSDL proponents
seem to be in denial ("we're always better", "it's your problem if the old
scheduler works better", "just one report of old scheduler being better").
""

http://lwn.net/Articles/226963/

SD is supposed to be a fair scheduler, and that means that if you give some tasks equal prioity, they will get equal cpu time if they want it. the specific problem here, was that the time alotted for X simply was not enough for it to perform the tasks he wanted, within the time he wanted, and hence the gui lagged.

Yes, but then you have to ask yourself, is the CPU scheduler in an operating system that requires users to constantly tweak their nice levels while they change between doing various different activities, each with different load patterns, ideal for the *desktop*?
Is this what would happen, or can you get away with setting them once then leaving them be? (In which case the distro's can handle it for the most part out of the box.)

Most of the time, I want an operating system (read: not kernel) tuned for low latency user interfaces and for intensive tasks to automatically drop back to make that happen. But then again, I want a system that is smart enough to notice I am not moving the mouse, the keyboard or reading (occasionally scrolling a web page) and then bumps the priority of background tasks appropriately while I don't need the interactivity.

If Linux is going to use a *strictly* no nonsense fair scheduler and any of the distro's want to build a solid desktop environment on top (One that doesn't want to make you tear your hair out) then as well as a nice set of 'nice' defaults it's going to take a lot of effort to enhance user land t the point where it can perform things like automatic renicing with a sense of intelligence relevant and well adapted to the user.

One of the things I think people are also underestimating is tweakaholic syndrome. Much like many Window's users which are obsessed disabling services and performing registry tweaks (most of which have positive results that are purely in the mind), this could lead to all kinds of posts on support forums like "Renice X to -19 and gnome-vfs to -5 for ultimate performance!!" and a lack of any real empirical study into the problems with the desktop and improving it.

From a technical perspective *I'm not opposed* to simplifying (or dumbing down) of the kernel scheduler to something completely strict and fair and putting more weight behind nice levels. All I'm saying is the user land will have to adapt and i'm not convinced application developers or distro's have even considered this seriously yet.

Edited 2007-07-28 11:26

You're underestimate the clever design ideas behind both SD and CFS. You're experience in terms of interactivity is not likely to degrade, and in certain cases, it'll get even better. Meanwhile, the reason for the fairness in the first place is that unfairness leads to serious, unfixable problems and cornercases. The specifics are beyond me here, but race conditions like priority inversion (where one high prio process, waiting for a lower prio process, is preventing that same process from running, thus stalling the system) can only be fixed once and for all by fairness.

Oh, and ingo also tried to cheat his way out of SD being superior, now i dont want to spoil your hunting on lkml.org cfs thread, but ill give some pointers.


This is just pure FUD.

Ingo did no "tried to cheat". He implemented a patch to give more priority to processes trying to use the syscall that X.org uses to do I/O to graphics cards as an experiment to nice to -19 processes doing I/O. It was an "obscure x86-only thing" because that was the way to implement this feature.

He released it to the public so that people could give feedback on how it behaves in their systems. He ANNOUNCED it: http://lkml.org/lkml/2007/4/20/197

- usability fix: automatic renicing of kernel threads such as keventd, OOM tasks and tasks doing privileged hardware access (such as Xorg).


There were reports of people saying that CFS with this patch behaved better than SD thanks to this patch and Con needed to explain that SD wasn't renicing anything so you needed to renice X or disable the CFS feature to compare both schedulers.

But then Linus said it was a hack and vetoed it: http://lkml.org/lkml/2007/4/23/179 . And then Ingo removed it, despite of the fact that he argues that desktop is smoother with it (http://lkml.org/lkml/2007/4/23/254). Juzguing from the reported smooter experience, I say that it was a worthy experiment.

End of the story. So much for your stupid "cheat" argument.

I really think you are saying this from an outsiders perspective, the fact is, when people download CFS many of them dont look at the thread, many did not even know this! i know this from the threads when they later observed that X had been reniced.

fact is, if mingo would have wanted people to compare to SD with X reniced, he should have simply told them to renice it, not slip it into the patch like this.

Nah, I don't think this was 'evil' on the part of ingo, though it was sure controversial... He's not like that, imho.

I really think you are saying this from an outsiders perspective, the fact is, when people download CFS many of them dont look at the thread

No, it's YOU who is saying this from a outsider perspective. New CFS versions were announced at the lkml. There could be several releases in hours if a serious bug or a big improvement was coded. Testers did read the lkml to get notified about new versions and told their experiences replyin to the announcement thread. This was an internal lkml work. There were not "outsiders".

if mingo would have wanted people to compare to SD with X reniced, he should have simply told them to renice it, not slip it into the patch like this.

The goal of this feature was to renice tasks automatically. If this feature would have been useful and had not been critized and vetoed by Linus and others, Con could have picked it up and released a new SD version with this feature.

Ingo also prefaced his comments with a completely deferential tone arguing against his own code's making a special case for X as setting a bad precedent and potentially causing trouble in the future. While he clearly was in love with the results of his hack (in his own words), Ingo relegated it to "useful experiment" status and accepted that it was not perhaps the best solution to the problem.

note the point here is NOT which got merged, CFS or SD - it's how Con was and is handled by the kernel community. He's a very valuable hacker, and they let him go.

http://lkml.org/lkml/2007/7/28/34

"""
note the point here is NOT which got merged, CFS or SD - it's how Con was and is handled by the kernel community. He's a very valuable hacker, and they let him go.
"""

I would argue that even brilliant and talented people are not necessarily "valuable" to the project if they are also poor team players.

I believe that Con will be back, and strongly suspect that this business of "quitting" is a poorly considered stunt.

If and when he returns, I hope that he is a better team player and that both he and his followers have a more positive and constructive attitude. In other words, I hope that he can be truly valuable.

Edited 2007-07-28 14:57

Hmmm. I don't think he'll come back anytime soon. He got real sick, you know, for a big part due to the stress of all this.

And he's not a poor teamplayer. He's not perfect either, but I do think the majority of the 'fault' does lie in the kernel community's behaviour. Again, not at specific people. But I think a series of incidents clearly points out there's an underlying problem...

"""
He got real sick, you know, for a big part due to the stress of all this.
"""

If kernel development caused his illness, then perhaps he should not return. Getting high profile pieces of code into the mainline kernel is not for the weak or the thin-skinned. You wouldn't catch me trying it even if I felt that my skills were up to it.

However, many other kernel developers have code rejected, some trying for many years to get it included, without it affecting their health, and are likely better suited to being long term maintainers for it.

Every exchange that I read, both here and on LKML, increases my feeling that Linus made the right choice. Yes, even the one's linked by Con's supporters. Because they so often turn out like your reply, presenting Con's illness as a reason for merging the code, rather than as a reason *not* to merge the code.

Con's health is Con's responsibility and not that of Linus, Andrew, Ingo, or anyone else. The *kernel's* long term health *is* their responsibility. And I cannot help but feel that it is in good hands.

Edited 2007-07-28 18:34

"He's a very valuable hacker, and they let him go."

They didn't let him go, he left. That is a big difference.

From his departing article he stated that he will get obsessed with some other non computer related project now. He didn't seem like a very stable coder. Now what would have happened if more of his code was accepted then one piece of code down the line was rejected? Would he have quite like this? You don't want your main coder on a project to just suddenly drop it.

This is why Linus makes sense in what he was saying. He needs someone who he knows will be there.

And why couldn't CK just suck it up and start patching CFS? This would be the best way to rise above the politics and support the project you believe in.

"""
From his departing article he stated that he will get obsessed with some other non computer related project now.
"""

Add to that the *nature* of his illness (disc prolapse in his neck), and the fact that he says that he did not leave over SD being rejected ( http://lkml.org/lkml/2007/7/28/179 , originally posted by RJop ) and the fact that he did not choose the article headline (which was originally "Why Linux Failed On The Desktop" and was changed by the author to "Why I Quit" when he objected to it that) and the fact that he is still posting cpu scheduling tips on lkml, at least as of yesterday, and a different picture than what has been primarily discussed begins to emerge.

Edited 2007-07-29 19:47

Indeed. Ow, and 'sucking it up and start patching SD'- that's ridiculous. SD went through over 50 (FIFTY!!!) iterations before it became 1.0!!! CFS isn't at version 0.50 yet, is it? I wouldn't say Ingo is not as responsive as Con, but Con SURELY isn't any less responsive than Ingo.

Point is, and he admits this himself, Linus has only a limited view on the whole issue. He doesn't follow the CK mailinglist, he only got CC'ed on a few emails. He didn't see the hard work and short response times, but he DID see the one guy giving stupid complains and Con, tired of it, getting a bit pissed off. Once...

Aaah, and don't just believe me:
http://lkml.org/lkml/2007/7/28/117

He ignored most of the post.

http://lkml.org/lkml/2007/7/28/109

Sure, the diff between SD and CFS is small, and for me it doesn't matter. I'm fine with CFS in the kernel, it's a huge improvement over the previous one. But why, while there was a good alternative, did THAT one stay in that long?

Some things get into the kernel, other don't. Some get in too soon, others too late. Sure. But shouldn't we try to improve this process, instead of saying 'it is what it is, get over it'?

For me, that's the purpose of this whole discussion. We're losing valuable code and contributors, yet at the same time code which isn't mature yet enters the kernel. Acknowledging this is a problem is the first step in solving it.

> Won't even *one* of you offer to maintain the SD patch and fix the inevitable problems? [...]
> No one?
> Well, that settles that, doesn't it?

Har har, be serious now. What on earth would be the point of trying now?

"""
Har har, be serious now. What on earth would be the point of trying now?
"""

1. Linus has been known to change his mind when presented with a *valid* reason to do so.

2. At worst, it would be less useless than whining on message boards.

Qoute Linus:
"It's not like we've come to the end of the road: the baseline has just
improved. If you guys can show that SD actually is better at some loads,
without penalizing others, we can (and will) revisit this issue."

If you guys believe so much in the SD scheduler this is a good reason to continue working on it after Con.
Sure beats crying and whining on public forums about how mistreated you were.