Re: [ck] Re: Linus 2.6.23-rc1
> two weeks stale, but your take on the EVMS story is incorrect. The > EVMS developers (that is, Kevin) sent out a nice, conciliatory email, > the project sputtered on for a while, then basically died. This is perfectly normal. It was outevolved and ran out of people who cared enough to continue it. Happens all the time. In the proprietary world its normally one company putting another out of business and lots of people losing jobs and money so its actually a good deal friendlier this side of the fence When you contribute to a big project some of your stuff will get nowhere, other stuff will eventually get kicked out and replaced. Its part of the progress of the system. And yes one day the Linux kernel will probably go the same was as EVMS when something cooler and neater replaces it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Saturday 28 July 2007 14:06, Diego Calleja wrote: > El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) escribió: > The main problem is clearly that no scheduler was clearly better than > the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - > both of them were good enought, but only one of them could be merged. > The difference is that EVMS developers didn't get that annoyed, and > not only they didn't quit but they continued developing their > userspace tools to make it work with the solution included in the > kernel > > (http://lwn.net/Articles/14714/) Not that I want to be in this thread, particularly since it is already two weeks stale, but your take on the EVMS story is incorrect. The EVMS developers (that is, Kevin) sent out a nice, conciliatory email, the project sputtered on for a while, then basically died. http://marc.info/?l=evms-devel=118240945708775=2 Bill is right. People who know people are right. A lot of good talent has been lost to Linux over the years because of various, perhaps good intentioned, gaffs. The thing is, if you contribute to a project like Linux for fun, when it stops being fun you walk. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Saturday 28 July 2007 14:06, Diego Calleja wrote: El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) escribió: The main problem is clearly that no scheduler was clearly better than the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both of them were good enought, but only one of them could be merged. The difference is that EVMS developers didn't get that annoyed, and not only they didn't quit but they continued developing their userspace tools to make it work with the solution included in the kernel (http://lwn.net/Articles/14714/) Not that I want to be in this thread, particularly since it is already two weeks stale, but your take on the EVMS story is incorrect. The EVMS developers (that is, Kevin) sent out a nice, conciliatory email, the project sputtered on for a while, then basically died. http://marc.info/?l=evms-develm=118240945708775w=2 Bill is right. People who know people are right. A lot of good talent has been lost to Linux over the years because of various, perhaps good intentioned, gaffs. The thing is, if you contribute to a project like Linux for fun, when it stops being fun you walk. Regards, Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
two weeks stale, but your take on the EVMS story is incorrect. The EVMS developers (that is, Kevin) sent out a nice, conciliatory email, the project sputtered on for a while, then basically died. This is perfectly normal. It was outevolved and ran out of people who cared enough to continue it. Happens all the time. In the proprietary world its normally one company putting another out of business and lots of people losing jobs and money so its actually a good deal friendlier this side of the fence When you contribute to a big project some of your stuff will get nowhere, other stuff will eventually get kicked out and replaced. Its part of the progress of the system. And yes one day the Linux kernel will probably go the same was as EVMS when something cooler and neater replaces it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter whose code gets merged!
On Thursday 02 August 2007 13:03, Frank Ch. Eigler wrote: > Arjan van de Ven <[EMAIL PROTECTED]> writes: > > [...] > > It does not matter [whose] code gets merged. > > What matters is that the problem gets solved and that the Linux > > kernel innovates forward. > > [...] > > This attitude has risks over the long term, if outsiders with fresh > ideas are discouraged. Risking becoming known to defer too much to > established maintainers, those fresh ideas may stop coming to linux. Amen to that, Frank. Driving off talented contributers is a Very Bad Thing for Linux in the long run. This will not not stop evolutionary progress, but it slows it down and may result in an overly inbred animal. It is especially easy to drive off a contributor whose day job is not Linux hacking. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter whose code gets merged!
On Thursday 02 August 2007 13:03, Frank Ch. Eigler wrote: Arjan van de Ven [EMAIL PROTECTED] writes: [...] It does not matter [whose] code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. Amen to that, Frank. Driving off talented contributers is a Very Bad Thing for Linux in the long run. This will not not stop evolutionary progress, but it slows it down and may result in an overly inbred animal. It is especially easy to drive off a contributor whose day job is not Linux hacking. Regards, Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Hi - > My concern is that only "get my line of code merged" is seen as "the > ultimate thing". It's more than that. Linux is about collaboration [...] Unfortunately, this spirit of collaboration sometimes gets lost in practice when feedback is asymmetric, obnoxious, or absent. - FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven <[EMAIL PROTECTED]> writes: > [...] > It does not matter [whose] code gets merged. > What matters is that the problem gets solved and that the Linux kernel > innovates forward. > [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. - FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Thu, 2007-08-02 at 16:03 -0400, Frank Ch. Eigler wrote: > Arjan van de Ven <[EMAIL PROTECTED]> writes: > > > [...] > > It does not matter [whose] code gets merged. > > What matters is that the problem gets solved and that the Linux kernel > > innovates forward. > > [...] > > This attitude has risks over the long term, if outsiders with fresh > ideas are discouraged. Risking becoming known to defer too much to > established maintainers, those fresh ideas may stop coming to linux. My concern is that only "get my line of code merged" is seen as "the ultimate thing". It's more than that. Linux is about collaboration, where it matters more that people work together to solve a problem, far far more than who actually types the lines in on the keyboard. Working on the problem should be seen (and recognized) as the right thing. Who writes the code is secundary to that. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, Aug 01, 2007 at 12:05:01AM -0700, Arjan van de Ven wrote: > I've had several cases myself where I spent quite some time solving a > problem, just to get some random remark from someone smart on lkml > saying "if you had done you would have had simple and superior solution>". Was I pissed off that my patch didn't > get merged but that this better approach got picked? NO! The problem > that I needed to solve got solved in a really good way. Mission > accomplished. Hey to me it even happened I had this nice and safe pte-highmem patch but the buggy highpte was merged instead, go figure. Con got lucky. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, Aug 01, 2007 at 12:05:01AM -0700, Arjan van de Ven wrote: I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying if you had done this simple thing you would have had this simple and superior solution. Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. Hey to me it even happened I had this nice and safe pte-highmem patch but the buggy highpte was merged instead, go figure. Con got lucky. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven [EMAIL PROTECTED] writes: [...] It does not matter [whose] code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. - FChE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Thu, 2007-08-02 at 16:03 -0400, Frank Ch. Eigler wrote: Arjan van de Ven [EMAIL PROTECTED] writes: [...] It does not matter [whose] code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. [...] This attitude has risks over the long term, if outsiders with fresh ideas are discouraged. Risking becoming known to defer too much to established maintainers, those fresh ideas may stop coming to linux. My concern is that only get my line of code merged is seen as the ultimate thing. It's more than that. Linux is about collaboration, where it matters more that people work together to solve a problem, far far more than who actually types the lines in on the keyboard. Working on the problem should be seen (and recognized) as the right thing. Who writes the code is secundary to that. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Hi - My concern is that only get my line of code merged is seen as the ultimate thing. It's more than that. Linux is about collaboration [...] Unfortunately, this spirit of collaboration sometimes gets lost in practice when feedback is asymmetric, obnoxious, or absent. - FChE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 11:40 -0700, Hua Zhong wrote: > > > And, from a standpoint of ONGOING, long-term innovation: what matters > > > is that brilliant, new ideas get rewarded one way or another. > > > > and in this case, the reward is that the idea got used and credit was > > given > > You mean, when Ingo announced CFS he mentioned Con's name? and put his name in the code too > When you said "it does not matter whose code got merged", I have to > disagree. Sure, for the Linux community as a whole, for Linux itself, > it may not matter, but for the individuals involved, it does. And I > think benefits of individuals are as important as benefits of the > community (or the nation). I agree it's a nice ego boost to see your code merged. But... do you care more about your ego boost or about your problem getting solved? I really want to change this if you say "ego for code merging"... "ego boost for getting linux improved and being involved in solving an important problem" is a lot better type of ego boost.. No developer can or should expect that most, or even half of his code to be merged. Even Linus doesn't get half the code he writes into linux :) Con did get a whole bunch of stuff merged over the years, and for the rest he mostly got the problem solved. That's pretty successful -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
> > And, from a standpoint of ONGOING, long-term innovation: what matters > > is that brilliant, new ideas get rewarded one way or another. > > and in this case, the reward is that the idea got used and credit was > given You mean, when Ingo announced CFS he mentioned Con's name? I really doubt that is the best reward for a developer. > > Because if you don't, the people with the 'different' ideas walk away, > > you end up with only those who 'fit' the culture, and there goes innovation. > > yet at the same time if people walk away just because their code didn't > get used, even though their problem got solved, should we merge "worse" > code just to prevent that ? That's almost blackmail, and also just > stupid. > > (not suggesting that SD in this case was better or worse, just trying > to make a general point) If it is a general point, sure, but it's hardly 1/10 of what happened here. And note I don't agree with Con's decision either - I wish he'd be back, but the reason I jumped in was to show some understanding, as I see some comments in the thread that were not doing so. When you said "it does not matter whose code got merged", I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). Con has been working on scheduler (fair or not) for years, and nothing got merged. Yet CFS got merged in a blink despite the fact that the competition just began to show. Have we given SD a fair chance? No. Ingo has a unique position that nobody else could challenge. Note I have said that he earned it through hard work and talent, so that's not the problem. The problem is how he could have handled it better, not "grab the food right under other's nose" blatantly. I don't think merging CFS was a wrong decision. The problem was how this decision was made. And I think Linus made some rather unfair comments about Con's personality, and I don't think deeply that was the reason he merged Ingo's code. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 10:14 +0200, [EMAIL PROTECTED] wrote: > On 8/1/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > Let me repeat the key message: > > > > It does not matter who's code gets merged. > > It does not matter who's code gets merged. > > It does not matter who's code gets merged. > > It does not matter who's code gets merged. > > > > What matters is that the problem gets solved and that the Linux kernel > > innovates forward. > > And, from a standpoint of ONGOING, long-term innovation: what matters > is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given > Because > if you don't, the people with the 'different' ideas walk away, you end > up with only those who 'fit' the culture, and there goes innovation. yet at the same time if people walk away just because their code didn't get used, even though their problem got solved, should we merge "worse" code just to prevent that ? That's almost blackmail, and also just stupid. (not suggesting that SD in this case was better or worse, just trying to make a general point) > That's why I tried to get involved in this discussion. It doesn't > matter who's code gets merged. But it does matter that people get > scared away. It took the kernel folks a few years, but they managed to > get someone kicked out who's not 'in-crowd', who clearly has a > different view, and who has the intent and motivation to write and > maintain code. And he did manage to get some of his code in, just not all. He also managed to get people interested in his problem so much that a healthy stint of competition happened and his problem got solved. If people walk away because they don't 100% always get things done EXACTLY their way.. well so be it. > Of course that's 'overdone', but it conveys a point: If you focus too > much on exploiting current code, instead of fundamentally exploring > new ideas you go down in the long run. here's the thing. Fair scheduling DID get explored. deeply so. now, getting people interested in your problem (and that is needed to get them to pay attention to it) is a sales job, no ifs and buts there. You need to convince them that 1) the problem is real, 2) the problem is relevant. If you also have a proposed solution you also need to convince them that 3) the solution solves the problem and 4) that it's the right way to solve the problem. That isn't politics, it's part of how the ecosystem works; people are not stupid, but you need to convince them about your problem and solution. And that "default a bit skeptical and overworked" approach is the foundation of the process; the same way as you need to pass a code review before people will merge your code. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
> has to get the blessing of the maintainer. On the other hand, > as you just said, the maintainer has no such obligation. Umm nope. As a maintainer if you feed Linus stuff you wrote that he thinks is a bad idea it will not go in, and you'll get an explanation of why. The process isn't perfect (eg removing half-vanished maintainers isnt handled well) but it isn't as you claim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On 8/1/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > Let me repeat the key message: > > It does not matter who's code gets merged. > It does not matter who's code gets merged. > It does not matter who's code gets merged. > It does not matter who's code gets merged. > > What matters is that the problem gets solved and that the Linux kernel > innovates forward. And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. That's why I tried to get involved in this discussion. It doesn't matter who's code gets merged. But it does matter that people get scared away. It took the kernel folks a few years, but they managed to get someone kicked out who's not 'in-crowd', who clearly has a different view, and who has the intent and motivation to write and maintain code. And that's bad. I've quoted this before: Reward Brilliant Failures, Punish Mediocre Successes. Of course that's 'overdone', but it conveys a point: If you focus too much on exploiting current code, instead of fundamentally exploring new ideas you go down in the long run. There has to be a balance. And in some area's of the kernel, there seems to be a good balance - new ideas come in, code is being re-factored. But in scheduling and VM, I wonder if there's enough exploration... I hear 'We don't do politics' a lot in the kernel community. Well, what are politics? Managing the way code gets into the kernel? That's important for sure, right? And what about thinking about the hacker culture? Nobody would object to preserving and securing that. But those are not just technical matters. Yet they require thought. If the kernel culture doesn't work, the code won't work. There is a delicate balance, and a key part of what Linus has been doing is preserving it. I think he must not ignore that there is always room for improvement, and moments like these (where a big 'fight' is going on, and there is a clear sense of urgency about the matter) are the perfect times for a good discussion, and possible change. Use it. Love, Jos * Disclaimer: - I'm no kernel hacker - actually I help at the KDE project in the area of marketing... - yet, i have followed Con and his stuff for years - and I do research in the area of promoting innovation in organisations at a Dutch research institute, which is why I so annoyingly think I might have something to say. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. This, I think, is what really really matters in the end. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying "if you had done you would have had ". Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the "which is likely to be maintained best" arguments) Very rational. I would now have to contend that CFS didn't lose and neither did SD. Linux won. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hua Zhong wrote: I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I agree with you here. It's not simply code superiority that matters but a balance of attitude and the code's corroboration with numbers. Both had numbers to show but I think that one's attitude was preferred over the other. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. I don't see where credit was lacking. As far as I've observed, SD's author was given acknowledgment on what he did and even got praise. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Tue, 2007-07-31 at 23:16 -0700, Hua Zhong wrote: > > Did Ingo have the obligation to improve Con's work? Definitely not. > > Did Con have a right to get Ingo's improvements or > > suggestions? Definitely not. > > Yes, and that's where the inequality is. > > Unless the maintainer does a really bad job or pisses off Linus, > anyone who wants to merge his code into mainline pretty much > has to get the blessing of the maintainer. On the other hand, > as you just said, the maintainer has no such obligation. I think a lot of people are missing some key things here: It does not matter who's code gets merged. The CFS-SD competition was a GOOD THING. Both sides were in heavy, fast improvement mode, and competed on all fronts and borrowed heavily from eachother in terms of ideas that worked, and innovated to stay ahead. The end result is that both were good schedulers, and Linux won by getting the fruit of this competition. Think of it as a mini-evolution of scheduler ideas compressed into a short time period. Now compare this to a single patch without competition/the need to survive in the habitat, say the first SD or the first CFS patch whatever your poison is. If there had been no competition element, we would have ended up with either one of those, and it would have been not nearly as good as they both ended up as in the end. Who wrote the code is not relevant in the large picture, the fact that the problem at hand (2.6 scheduler behavior) got solved is. I wish people would focus less on who wrote the actual code that got merged in the end, and more on the problem that got solved People who care about the desktop should be happy that the scheduler improved a lot due to the competition where the two new schedulers were hair-close in most aspects. Again.. think about the problem being solved. Not who wrote the code or which of the competitive patches got merged in the end. Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying "if you had done you would have had ". Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the "which is likely to be maintained best" arguments) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1
> Did Ingo have the obligation to improve Con's work? Definitely not. > Did Con have a right to get Ingo's improvements or > suggestions? Definitely not. Yes, and that's where the inequality is. Unless the maintainer does a really bad job or pisses off Linus, anyone who wants to merge his code into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. > There are no such rights in this open source > development framework (TM). > > What Ingo did, I think, was what he wanted and he has the right to do > that. I think it's the maintainer's privilege, not right. > in the open source world, that which is superior (i.e. code, function, > not person) has the right to exist and the inferior to die away. I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1
Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. Yes, and that's where the inequality is. Unless the maintainer does a really bad job or pisses off Linus, anyone who wants to merge his code into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I think it's the maintainer's privilege, not right. in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Tue, 2007-07-31 at 23:16 -0700, Hua Zhong wrote: Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. Yes, and that's where the inequality is. Unless the maintainer does a really bad job or pisses off Linus, anyone who wants to merge his code into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. I think a lot of people are missing some key things here: It does not matter who's code gets merged. The CFS-SD competition was a GOOD THING. Both sides were in heavy, fast improvement mode, and competed on all fronts and borrowed heavily from eachother in terms of ideas that worked, and innovated to stay ahead. The end result is that both were good schedulers, and Linux won by getting the fruit of this competition. Think of it as a mini-evolution of scheduler ideas compressed into a short time period. Now compare this to a single patch without competition/the need to survive in the habitat, say the first SD or the first CFS patch whatever your poison is. If there had been no competition element, we would have ended up with either one of those, and it would have been not nearly as good as they both ended up as in the end. Who wrote the code is not relevant in the large picture, the fact that the problem at hand (2.6 scheduler behavior) got solved is. I wish people would focus less on who wrote the actual code that got merged in the end, and more on the problem that got solved People who care about the desktop should be happy that the scheduler improved a lot due to the competition where the two new schedulers were hair-close in most aspects. Again.. think about the problem being solved. Not who wrote the code or which of the competitive patches got merged in the end. Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying if you had done this simple thing you would have had this simple and superior solution. Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the which is likely to be maintained best arguments) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hua Zhong wrote: I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I agree with you here. It's not simply code superiority that matters but a balance of attitude and the code's corroboration with numbers. Both had numbers to show but I think that one's attitude was preferred over the other. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. I don't see where credit was lacking. As far as I've observed, SD's author was given acknowledgment on what he did and even got praise. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. This, I think, is what really really matters in the end. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying if you had done this simple thing you would have had this simple and superior solution. Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the which is likely to be maintained best arguments) Very rational. I would now have to contend that CFS didn't lose and neither did SD. Linux won. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On 8/1/07, Arjan van de Ven [EMAIL PROTECTED] wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. That's why I tried to get involved in this discussion. It doesn't matter who's code gets merged. But it does matter that people get scared away. It took the kernel folks a few years, but they managed to get someone kicked out who's not 'in-crowd', who clearly has a different view, and who has the intent and motivation to write and maintain code. And that's bad. I've quoted this before: Reward Brilliant Failures, Punish Mediocre Successes. Of course that's 'overdone', but it conveys a point: If you focus too much on exploiting current code, instead of fundamentally exploring new ideas you go down in the long run. There has to be a balance. And in some area's of the kernel, there seems to be a good balance - new ideas come in, code is being re-factored. But in scheduling and VM, I wonder if there's enough exploration... I hear 'We don't do politics' a lot in the kernel community. Well, what are politics? Managing the way code gets into the kernel? That's important for sure, right? And what about thinking about the hacker culture? Nobody would object to preserving and securing that. But those are not just technical matters. Yet they require thought. If the kernel culture doesn't work, the code won't work. There is a delicate balance, and a key part of what Linus has been doing is preserving it. I think he must not ignore that there is always room for improvement, and moments like these (where a big 'fight' is going on, and there is a clear sense of urgency about the matter) are the perfect times for a good discussion, and possible change. Use it. Love, Jos * Disclaimer: - I'm no kernel hacker - actually I help at the KDE project in the area of marketing... - yet, i have followed Con and his stuff for years - and I do research in the area of promoting innovation in organisations at a Dutch research institute, which is why I so annoyingly think I might have something to say. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. Umm nope. As a maintainer if you feed Linus stuff you wrote that he thinks is a bad idea it will not go in, and you'll get an explanation of why. The process isn't perfect (eg removing half-vanished maintainers isnt handled well) but it isn't as you claim. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 10:14 +0200, [EMAIL PROTECTED] wrote: On 8/1/07, Arjan van de Ven [EMAIL PROTECTED] wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. yet at the same time if people walk away just because their code didn't get used, even though their problem got solved, should we merge worse code just to prevent that ? That's almost blackmail, and also just stupid. (not suggesting that SD in this case was better or worse, just trying to make a general point) That's why I tried to get involved in this discussion. It doesn't matter who's code gets merged. But it does matter that people get scared away. It took the kernel folks a few years, but they managed to get someone kicked out who's not 'in-crowd', who clearly has a different view, and who has the intent and motivation to write and maintain code. And he did manage to get some of his code in, just not all. He also managed to get people interested in his problem so much that a healthy stint of competition happened and his problem got solved. If people walk away because they don't 100% always get things done EXACTLY their way.. well so be it. Of course that's 'overdone', but it conveys a point: If you focus too much on exploiting current code, instead of fundamentally exploring new ideas you go down in the long run. here's the thing. Fair scheduling DID get explored. deeply so. now, getting people interested in your problem (and that is needed to get them to pay attention to it) is a sales job, no ifs and buts there. You need to convince them that 1) the problem is real, 2) the problem is relevant. If you also have a proposed solution you also need to convince them that 3) the solution solves the problem and 4) that it's the right way to solve the problem. That isn't politics, it's part of how the ecosystem works; people are not stupid, but you need to convince them about your problem and solution. And that default a bit skeptical and overworked approach is the foundation of the process; the same way as you need to pass a code review before people will merge your code. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given You mean, when Ingo announced CFS he mentioned Con's name? I really doubt that is the best reward for a developer. Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. yet at the same time if people walk away just because their code didn't get used, even though their problem got solved, should we merge worse code just to prevent that ? That's almost blackmail, and also just stupid. (not suggesting that SD in this case was better or worse, just trying to make a general point) If it is a general point, sure, but it's hardly 1/10 of what happened here. And note I don't agree with Con's decision either - I wish he'd be back, but the reason I jumped in was to show some understanding, as I see some comments in the thread that were not doing so. When you said it does not matter whose code got merged, I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). Con has been working on scheduler (fair or not) for years, and nothing got merged. Yet CFS got merged in a blink despite the fact that the competition just began to show. Have we given SD a fair chance? No. Ingo has a unique position that nobody else could challenge. Note I have said that he earned it through hard work and talent, so that's not the problem. The problem is how he could have handled it better, not grab the food right under other's nose blatantly. I don't think merging CFS was a wrong decision. The problem was how this decision was made. And I think Linus made some rather unfair comments about Con's personality, and I don't think deeply that was the reason he merged Ingo's code. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
On Wed, 2007-08-01 at 11:40 -0700, Hua Zhong wrote: And, from a standpoint of ONGOING, long-term innovation: what matters is that brilliant, new ideas get rewarded one way or another. and in this case, the reward is that the idea got used and credit was given You mean, when Ingo announced CFS he mentioned Con's name? and put his name in the code too When you said it does not matter whose code got merged, I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). I agree it's a nice ego boost to see your code merged. But... do you care more about your ego boost or about your problem getting solved? I really want to change this if you say ego for code merging... ego boost for getting linux improved and being involved in solving an important problem is a lot better type of ego boost.. No developer can or should expect that most, or even half of his code to be merged. Even Linus doesn't get half the code he writes into linux :) Con did get a whole bunch of stuff merged over the years, and for the rest he mostly got the problem solved. That's pretty successful -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Roman Zippel wrote: When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. When Ingo wrote something that went head-on with what Con wrote, it was his prerogative to do so. There's no speaking here of rights to do or not to do since as matter of evidence, in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I believe that Ingo does not have an obligation to be responsible for what Con felt. You feel what you feel because you choose to feel that way. Let us remember that "Happiness is a choice, not a state." And let's just look at the attitudes on how both Ingo and Con reacted to the issues regarding their respective schedulers. I won't list them here now since they're all there in the archives. Since attitude also plays a big part in getting your code in mainline, I think we would know the reason why one got chosen for the other. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hi, On Sat, 28 Jul 2007, Linus Torvalds wrote: > We've had people go with a splash before. Quite frankly, the current > scheduler situation looks very much like the CML2 situation. Anybody > remember that? The developer there also got rejected, the improvement was > made differently (and much more in line with existing practices and > maintainership), and life went on. Eric Raymond, however, left with a > splash. Since I was directly involved I'd like to point out a key difference. http://lkml.org/lkml/2002/2/21/57 was the very first start of Kconfig and initially I didn't plan on writing a new config system. At the beginning there was only the converter, which I did to address the issue that Eric created a complete new and different config database, so the converter was meant to create a more acceptable transition path. What happened next is that I haven't got a single response from Eric, so I continued hacking on it until was complete. The key difference is now that Eric refused the offered help, while Con was refused the help he needed to get his work integrated. When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Bill Huey (hui) wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. Yes, the reaction was legitimate but it could have been better. It would have benefited everyone if instead of posting rants, numbers and patches or suggested solutions were posted. Up until today, some posters that complain on how CFS fairs worse than SD simply post reports that say: "I use this system in this way and it does not fair well with cfs!" Look at this one for example: http://lkml.org/lkml/2007/7/31/199 It looks technical but it isn't. The author simply stated that he built his own lightweight Linux box that specializes in audio but there has not been any technical characteristic of the problem. We don't even know the audio libraries he's using but simply claimed that he wrote his own. The report, if I were the one to debug it, is completely useless since it does not even give some reproducability hints nor technical characteristics of the system. This is what some of the SD fan-boys do. Rant. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, 2007-07-31 at 02:57 -0700, Bill Huey wrote: > On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: > > > > We obviously all saw how the particular authors tried to address the > > issues. Ingo tried to address all concerns while Con simply ranted about > > his scheduler being better. If this is what you think about being a bit > > more human, then I think that this has no place in the lkml. > > That's highly inaccurate and rather disrespect of Con's experience. > There as a policy decision made with SD that one person basically didn't > like, this person whined like a baby for the a formula bottle and didn't > understand how to use "nice" to control this inherent behavior of this > scheduler. Chuckle. You are really desperate for entertainment. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: > And I think you are digressing from the main issue, which is the empirical > comparison of SD vs. CFS and to determine which is best. The root of all > the scheduler fuss was the emotional reaction of SD's author on why his > scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. > We obviously all saw how the particular authors tried to address the > issues. Ingo tried to address all concerns while Con simply ranted about > his scheduler being better. If this is what you think about being a bit > more human, then I think that this has no place in the lkml. That's highly inaccurate and rather disrespect of Con's experience. There as a policy decision made with SD that one person basically didn't like, this person whined like a baby for the a formula bottle and didn't understand how to use "nice" to control this inherent behavior of this scheduler. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. That's highly inaccurate and rather disrespect of Con's experience. There as a policy decision made with SD that one person basically didn't like, this person whined like a baby for the a formula bottle and didn't understand how to use nice to control this inherent behavior of this scheduler. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Tue, 2007-07-31 at 02:57 -0700, Bill Huey wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. That's highly inaccurate and rather disrespect of Con's experience. There as a policy decision made with SD that one person basically didn't like, this person whined like a baby for the a formula bottle and didn't understand how to use nice to control this inherent behavior of this scheduler. Chuckle. You are really desperate for entertainment. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Bill Huey (hui) wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. Yes, the reaction was legitimate but it could have been better. It would have benefited everyone if instead of posting rants, numbers and patches or suggested solutions were posted. Up until today, some posters that complain on how CFS fairs worse than SD simply post reports that say: I use this system in this way and it does not fair well with cfs! Look at this one for example: http://lkml.org/lkml/2007/7/31/199 It looks technical but it isn't. The author simply stated that he built his own lightweight Linux box that specializes in audio but there has not been any technical characteristic of the problem. We don't even know the audio libraries he's using but simply claimed that he wrote his own. The report, if I were the one to debug it, is completely useless since it does not even give some reproducability hints nor technical characteristics of the system. This is what some of the SD fan-boys do. Rant. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hi, On Sat, 28 Jul 2007, Linus Torvalds wrote: We've had people go with a splash before. Quite frankly, the current scheduler situation looks very much like the CML2 situation. Anybody remember that? The developer there also got rejected, the improvement was made differently (and much more in line with existing practices and maintainership), and life went on. Eric Raymond, however, left with a splash. Since I was directly involved I'd like to point out a key difference. http://lkml.org/lkml/2002/2/21/57 was the very first start of Kconfig and initially I didn't plan on writing a new config system. At the beginning there was only the converter, which I did to address the issue that Eric created a complete new and different config database, so the converter was meant to create a more acceptable transition path. What happened next is that I haven't got a single response from Eric, so I continued hacking on it until was complete. The key difference is now that Eric refused the offered help, while Con was refused the help he needed to get his work integrated. When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Roman Zippel wrote: When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. When Ingo wrote something that went head-on with what Con wrote, it was his prerogative to do so. There's no speaking here of rights to do or not to do since as matter of evidence, in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I believe that Ingo does not have an obligation to be responsible for what Con felt. You feel what you feel because you choose to feel that way. Let us remember that Happiness is a choice, not a state. And let's just look at the attitudes on how both Ingo and Con reacted to the issues regarding their respective schedulers. I won't list them here now since they're all there in the archives. Since attitude also plays a big part in getting your code in mainline, I think we would know the reason why one got chosen for the other. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Martin Steigerwald wrote: The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. IMHO, the above statements are all plain conjectures. How could you assert that the kernel development process is without human development? If you've followed the list for a while, you'd realize that the list is very human. The fact that flames fly and abound, and the fact that individual persons tend to be very strong with respect to their opinions indicate that there is a rather high level of human dealings that happen on the list. And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. We've all heard the "show me the numbers" argument, and as far as I can see, CFS now fairs much better than SD. That's the issue. The best one will emerge to be at the top. From several months of tests and improvements, it seems CFS is emerging to be the better scheduler. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Martin Steigerwald wrote: The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. IMHO, the above statements are all plain conjectures. How could you assert that the kernel development process is without human development? If you've followed the list for a while, you'd realize that the list is very human. The fact that flames fly and abound, and the fact that individual persons tend to be very strong with respect to their opinions indicate that there is a rather high level of human dealings that happen on the list. And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. We've all heard the show me the numbers argument, and as far as I can see, CFS now fairs much better than SD. That's the issue. The best one will emerge to be at the top. From several months of tests and improvements, it seems CFS is emerging to be the better scheduler. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On 7/30/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > For example, how hard is it for people to just admit that CFS actually > does better than SD on a number of things? Including very much on the > desktop. Actually in benchmarks Ingo has quoted, SD was better on the desktop (by a small margin). CFS is still a bit bursty, though it has significantly improved with age. I know, I did those benchmarks. That being said, I'm really glad to see CFS in your git tree because the new framework around it really improves the readability of the code, and actually makes it easier to start experimenting with scheduler improvements from an entire scheduler like SD to minor bits like priorities. I have one concern - my benchmarking took load average as the common denominator and CFS alters the way the load average is calculated, so perhaps it wasn't a fair comparison. That being said, they still showed CFS could scale very well and SD did not, so considering we're dealing with everything from wristwatches to BlueGene/L I believe the right choice was made. Those arguing for the 2% improvement that SD would give them in their environment would be better off a) helping port SD to the new scheduler framework b) assisting Ingo in improving CFS to meet/exceed their requirements c) giving practical assistance to anyone doing either of the above I'm re-learning git and using my Copious Spare Time (tm) to do what I can - but I have to admit I'm really in over my head. But hey, if Jeff Garzik can do it, so can I. I remember when he couldn't grok C & now he's got control over all our data :-) -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 14:48 -0700, Bill Huey wrote: > On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote: > > Absolutely. > > > > Con quit for his own reasons. Given that Con himself has said that CFS > > was _not_ why he quite, please discard this... bait. Anyone who's name > > isn't Con Kolivas, who pretends to speak for him is at the very least > > overstepping his bounds, and that is being _very_ generous. > > I know Con personally and I completely identify with his circumstance. This You're still not Con, and I still think it's inappropriate for any person to speak for another unless that person is the designated proxy. > is precisely why he quit the project because of a generally perceived > ignorance and disconnect from end users. Since you side with Ingo on many > issues politically, this response from you is no surprise. Hm. I don't recall entering the world of politics. Where's my cool lapel button? -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote: > Absolutely. > > Con quit for his own reasons. Given that Con himself has said that CFS > was _not_ why he quite, please discard this... bait. Anyone who's name > isn't Con Kolivas, who pretends to speak for him is at the very least > overstepping his bounds, and that is being _very_ generous. I know Con personally and I completely identify with his circumstance. This is precisely why he quit the project because of a generally perceived ignorance and disconnect from end users. Since you side with Ingo on many issues politically, this response from you is no surprise. Again, the choices that have been currently made with CFS basically locks him out of development. If you don't understand that, then you don't understand the technical issues he's struggled to pursue. He has a large following which is why this has been a repeated and issue between end users of his tree and a number of current Linux kernel developers. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
* Satyam Sharma <[EMAIL PROTECTED]> wrote: > > > So whats wrong then? > > > > > > Ingo decides to do a better scheduler - to some extent inspired by > > > Con's work. And after 48 hours he publish first version that > > > _anyone_ can see and comment on. Whats wrong with that? > > > > > > Did you expect some lengthy discussion before the coding phase > > > started or what? > > > > > > Just trying to understand what you are arguing about. > > > > If I tried to rewrite a kernel subsystem - should I ever happen to > > dig that deep into kernel matters - while I actually know that > > someone already spent countless hours on exactly rewriting the exact > > same subsystem, I think I would have told that other developer about > > it as soon as I started coding on it. And if it just was a > > > > "Hi Con, > > > > I reconsidered the scheduling ideas again you brought to the Linux > > kernel world. Instead of using your scheduler tough I like to try to > > write a new one with fairness in mind, cause I think this, this and > > this can be improved upon. > > > > I would like to hear your ideas about that as soon as possible and > > would like you to contribute your ideas and also code, where you see > > hit. You can find the git / bazaar / whatever repository where I do > > my developments at: someurl. > > > > Regards, Ingo" > > Sending out the code (and early enough, 48 hours /is/ early enough) > *is* the normal (and good) way to do exactly the communication you > described above, IMHO. yeah. And note that the time from the "ok, this approach might work" point to releasing CFS was even less than the original ~62 hours of CFS development. I dont typically write code because i'm particularly "convinced" about an idea or because i "believe in" an idea, i mostly write code to _check_ whether an idea is worth advancing or not. Writing code is my form of "thinking", and releasing patches is my form of telling others about my "thoughts". I might have guesses about how well something will work out in practice (and i'd certainly be a fool to go out coding blindly), but surprises happen almost always, both in positive and in negative direction, and even with relatively simple patches. CFS started out as an experiment to simplify the scheduler, to clean up the after-effects of a better-desktop-scheduling patch Mike Galbraith sent me. Had anyone told me at that time that i'd end up writing a new scheduler i'd have laughed at the suggestion and i'd have pointed to the large number of pending patches of mine in forms of the -rt tree, the syslet/threadlet code and other stuff that needs fixing a lot more urgent than the task scheduler. During that cleanup work did i realize how a policy-modularized scheduler would allow the bridging of the seemingly unreconcilable friction between the O(1) data structures that things like RT scheduling needs and the binary tree that "fair share scheduling" concepts dictate. (most of the complexity in kernel code like the scheduler derives from complexity in data structures, so you start writing code by thinking about your data structures.) And the time from the point where i thought "ok, this fair-share thing behaves pretty well and it certainly looks simpler than the current code" to the announcement on lkml was more on the order of hours than days - much of the 62 hours were spent on ripping out the old code and on getting the new design up and running. There was simply no code in existence before CFS which has proven the code simplicity/design virtues of 'fair scheduling' - SD was more of an argument _against_ it than for it. I think maybe even Con might have been surprised by that simplicity: in his first lkml reaction to CFS he also wrote that he finds the CFS code "beautiful": http://lkml.org/lkml/2007/4/14/199 and my reply to Con's mail: http://lkml.org/lkml/2007/4/15/64 still addresses a good number of points raised in this thread i think. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 16:31 +0200, Diego Calleja wrote: > El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <[EMAIL PROTECTED]> > escribió: > > > The scheduler could have and still can undertake good solid transformation, > > but getting folks to listen is another story which is why Con quit. CFS > > basically locks him and his ideas out, not just from a technical stand > > This is just wrong: AFAIK nobody is stopping Con or any other people from > continuing developing SD or any other scheduler, and CFS certainly is subject > to criticism. The idea that Linux can't use other innovative ideas in the > scheduler > is only in your mind. Absolutely. Con quit for his own reasons. Given that Con himself has said that CFS was _not_ why he quite, please discard this... bait. Anyone who's name isn't Con Kolivas, who pretends to speak for him is at the very least overstepping his bounds, and that is being _very_ generous. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 08:23:31PM +0200, Martin Steigerwald wrote: > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > > > I > > > > > actually also think that the communication between Ingo and Con > > > > > could have been better especially when Ingo decided to write CFS > > > > > while Con was still working hard on SD. > > > > > > > > You realize that Ingo posted his code for anyone to look at/comment > > > > at about 48 hours after he started to work on CFS? > > > > > > Yes. > > > > So whats wrong then? > > Ingo decides to do a better scheduler - to some extent inspired by > > Con's work. And after 48 hours he publish first version that _anyone_ > > can see and comment on. Whats wrong with that? > > > > Did you expect some lengthy discussion before the coding phase started > > or what? > > > > Just trying to understand what you are arguing about. > > If I tried to rewrite a kernel subsystem - should I ever happen to dig > that deep into kernel matters - while I actually know that someone > already spent countless hours on exactly rewriting the exact same > subsystem, I think I would have told that other developer about it as > soon as I started coding on it. The usual way to communicate such things on lkml are with patches as also happened in this case. It's not like Ingo had secretly developing a scheduler in parallel for weeks or months but. But I assume all the fuzz is about something else - it cannot be about a these 48 hours - I hope.. Enough on this - back to work. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Satyam Sharma: > Hi Martin, Hi Satyam, > > I believe that Ingo did not meant any bad at all. I think its just > > the way he works, he likes to have code before saying anything. But > > still I believe before I'd go about replacing someone else code > > completely I would inform that developer beforehand, even if it then > > turns out not to be feasible at all. No need to anounce it to the > > world already, but I would have informed that developer. > > IMHO, what you're suggesting is: (1) not the way development normally > happens in Linux, and, (2) not the way it /should/ happen, either. If > there's something (subsystem, any code big or small) I think I can do > better or have an idea for, I /should/ be able to just hack on it a bit > and then send it out so everybody can comment on it. Why should I be > forced to dance/discuss around with some other people, when the faster > and more effective way would be just present the code/patch that I > have in my mind as an RFC? Hmmm, that email would have taken how long? 5 minutes maybe? I just feel that I would have written it if I happen to know that another developer spent lots of time and effort into a subsystem I plan to rewrite. Its just human logic to me. Especially when I happen to know that the other developer may be new to the kernel development process as I know it from a internal view point. The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. I always believed that kernel developers are human beings and no robots. And thus the kernel development process IMHO should be designed with human developers in mind instead of robots which take no offence out of anything. Otherwise things like what happened here will happen again and again and again and talent is lost. It is damn good to take technical merits into full account! But ignoring human aspects of development actually will hinder this. Cause then in the end its not about technical merits anymore that do the decision, but that human aspects that have been ignored and are floating around unconsiously. Actually I do believe that this discussion already took more resources than actually writing a few more mails and doing a bit more communication here and there... IMHO the fact that this discussion exists already shows that something in the process of submitting kernel patches and supporting involvement in kernel development can be improved upon. > See, Martin, in the end it's not about developer A vs developer B. It's > about making the kernel the best out there -- that's what the users > want, anyway. Yes, I fully understand (and have said so earlier myself) > that there's a very important "social" aspect to development on such > projects, but it's best if developer B understands that this is the way > things do (and should) happen and adapt to it. [ It's not like I've > been around for long, however, but the above is still my opinion, fwiw. > ] I am not saying that developer B (Con) does not have his share in how it all happened. As written before I got the impression that Con reacted hurt where from my point of view no offence was meant - and I told him that. But from what I know it would have been possible to actually deal with that quite a bit better than has happened. And it would not have taken much effort. Well actually I think it would have been quite easy to take the talent that has offered itself. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Hi Martin, On Sun, 29 Jul 2007, Martin Steigerwald wrote: > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > > > I > > > > > actually also think that the communication between Ingo and Con > > > > > could have been better especially when Ingo decided to write CFS > > > > > while Con was still working hard on SD. > > > > > > > > You realize that Ingo posted his code for anyone to look at/comment > > > > at about 48 hours after he started to work on CFS? > > > > > > Yes. > > > > So whats wrong then? > > Ingo decides to do a better scheduler - to some extent inspired by > > Con's work. And after 48 hours he publish first version that _anyone_ > > can see and comment on. Whats wrong with that? > > > > Did you expect some lengthy discussion before the coding phase started > > or what? > > > > Just trying to understand what you are arguing about. > > If I tried to rewrite a kernel subsystem - should I ever happen to dig > that deep into kernel matters - while I actually know that someone > already spent countless hours on exactly rewriting the exact same > subsystem, I think I would have told that other developer about it as > soon as I started coding on it. And if it just was a > > "Hi Con, > > I reconsidered the scheduling ideas again you brought to the Linux kernel > world. Instead of using your scheduler tough I like to try to write a new > one with fairness in mind, cause I think this, this and this can be > improved upon. > > I would like to hear your ideas about that as soon as possible and would > like you to contribute your ideas and also code, where you see hit. You > can find the git / bazaar / whatever repository where I do my > developments at: someurl. > > Regards, Ingo" Sending out the code (and early enough, 48 hours /is/ early enough) *is* the normal (and good) way to do exactly the communication you described above, IMHO. > I believe that Ingo did not meant any bad at all. I think its just the way > he works, he likes to have code before saying anything. But still I > believe before I'd go about replacing someone else code completely I > would inform that developer beforehand, even if it then turns out not to > be feasible at all. No need to anounce it to the world already, but I > would have informed that developer. IMHO, what you're suggesting is: (1) not the way development normally happens in Linux, and, (2) not the way it /should/ happen, either. If there's something (subsystem, any code big or small) I think I can do better or have an idea for, I /should/ be able to just hack on it a bit and then send it out so everybody can comment on it. Why should I be forced to dance/discuss around with some other people, when the faster and more effective way would be just present the code/patch that I have in my mind as an RFC? See, Martin, in the end it's not about developer A vs developer B. It's about making the kernel the best out there -- that's what the users want, anyway. Yes, I fully understand (and have said so earlier myself) that there's a very important "social" aspect to development on such projects, but it's best if developer B understands that this is the way things do (and should) happen and adapt to it. [ It's not like I've been around for long, however, but the above is still my opinion, fwiw. ] Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Diego Calleja: > > This time it was Con being the Mindcraft catalyst. But he's on *our* > > side and he got beat down by the Linux kernel community. That's the > > tragedy here. He was beaten down by the very people he was trying to > > help out and support. It should have been handled better. > > Get real: I don't the linux development has always been "friendly". The > idea of a "GNU-hippie community" where everybody is good and helps > others and shares their pots is what the Sun bloggers seem to think > that opensolaris should resemble, but it doesn't matches the real > world. Actually I have seen friendly communities around Linux and free software. Like the KDE project, the ck patchset mailing list community, the TuxOnIce aka suspend2 community, the SGI XFS community, the Bazaar community, quite some parts of the Debian community just to name a few. So I know that it can be different. I know that its inaccurate to talk about the whole Linux kernel community. I had quite friendly contacts with core Linux developers like with Ingo (yes, with Ingo!;-) or Greg Kroah-Hartman. So what would be wrong with looking at how this worked out and why and how it would be possible to avoid loosing a talented developer? -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > > I > > > > actually also think that the communication between Ingo and Con > > > > could have been better especially when Ingo decided to write CFS > > > > while Con was still working hard on SD. > > > > > > You realize that Ingo posted his code for anyone to look at/comment > > > at about 48 hours after he started to work on CFS? > > > > Yes. > > So whats wrong then? > Ingo decides to do a better scheduler - to some extent inspired by > Con's work. And after 48 hours he publish first version that _anyone_ > can see and comment on. Whats wrong with that? > > Did you expect some lengthy discussion before the coding phase started > or what? > > Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a "Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo" I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. And aside from that there has been communication before and after this event that IMHO could have been "better". And thats not only targetted at Ingo. A view this whole issue as "everyone who was involved in it, actually was involved in it and has his share in its outcome". So everyone has a great chance to learn something out of it. (That includes me of course, too.) Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > I > > > actually also think that the communication between Ingo and Con could > > > have been better especially when Ingo decided to write CFS while Con > > > was still working hard on SD. > > > > You realize that Ingo posted his code for anyone to look at/comment at > > about 48 hours after he started to work on CFS? > > Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <[EMAIL PROTECTED]> escribió: > The scheduler could have and still can undertake good solid transformation, > but getting folks to listen is another story which is why Con quit. CFS > basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. > This time it was Con being the Mindcraft catalyst. But he's on *our* side > and he got beat down by the Linux kernel community. That's the tragedy here. > He was beaten down by the very people he was trying to help out and > support. It should have been handled better. Get real: I don't the linux development has always been "friendly". The idea of a "GNU-hippie community" where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > I > > actually also think that the communication between Ingo and Con could > > have been better especially when Ingo decided to write CFS while Con > > was still working hard on SD. > > You realize that Ingo posted his code for anyone to look at/comment at > about 48 hours after he started to work on CFS? Yes. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
> I > actually also think that the communication between Ingo and Con could > have been better especially when Ingo decided to write CFS while Con was > still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: > On Sat, 28 Jul 2007, Diego Calleja wrote: > > El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > > > So "modal" things are good for fixing behaviour in the short run. > > > But they are a total disaster in the long run, and even in the > > > short run they tend to have problems (simply because there will be > > > cases that straddle the line, and show some of _both_ issues, and > > > now *neither* mode is the right one) > > > > I fully agree with this, but plugsched could have avoided this > > useless "division" on the topic of SD vs CFS. IMO that counts as an > > advantage, too ;) > > Sure. I actually think it's a huge advantage (see the ManagementStyle > file on pissing people off), but at the same time, I don't like playing > politics with technology. The kernel is a technical project, and I make > technical decisions. IMHO thats an illusion. The kernel has become a community project pretty soon after you have released it initially. And the community members are human beings. Thus while the kernel source code in itself for sure describes technical processes, the kernel is more than just a technical project. > So I absolutely detest adding code for "political" reasons. I can understand this and I agree to it, cause it would mean fixing political things on technical grounds and thus not fixing them at all. > I personally feel that modal behaviour is bad, so it would introduce > what is in my opinion bad code, and likely result in problems not being > found and fixed as well (because people would pick the thing that > "works for them", and ignore the problems in the other module). So > while I don't like making irreversible decisions (and the choice of CFS > wasn't irreversible in itself, but if it pisses off Con, _that_ is > generally not reversible), I dislike even more making a half-assed > decision. I agree to this to some extent. But if the mainline kernel does not contain suitable solutions for one subsystem people will tend to plug in other solutions that work for them even where there is no boot or runtime plugability. I have been using TuxOnIce (formerly suspend2) for quite some time and didn't even try the in-kernel-suspend-to-disk stuff since quite some kernel versions since I could not have been bothered anymore after it was failing back then. So when there are two different approaches with good following it may have be good to have some plugability for testing things. But it may be difficult to remove it afterwards again..., but it would still be possible to remove plugins that are only used rarely and they how the other ones evolve. > So rather than making a choice at all, my other choice would have been > to not merge _either_ scheduler, and let people just continue to fight > it out. Would that have made people happier? I seriously doubt it. I tried speaking to Con and Ingo whether they could settle their issue with one another and work together. In *private* mails, away from all the flame throwing. Actually I believe that human things should be resolved on the human side, not on the technical one. And as I perceive no serious attempt has been made on that - except my own maybe. Maybe just writing an email to both Con and Ingo where you told both of them your concerns and thoughts would have helped a lot. A "Hi Con and Ingo, Con, I do not believe that you are able to maintain SD for reason 1,2 and 3. But I do think that Ingo could. But I think, that you wrote great code and brought in good scheduler concepts and ideas to the Linux world. Now Ingo has CFS and you have SD... could there be a way for you to stay involved with scheduler issues and work together with Ingo? If so how could it look like? Ingo, do you see areas where Con can help you with? Are there things in SD that you would like to have in CFS? Do you see a way to work with Con together on the scheduler?" (just a draft;-) for example. It would have given Con some recognition for his work. It could have helped to address the political, well not even the political, but the human issue here. I believe that this is what Con missed the most: Getting some form of recognition from the "official" kernel people! I tried to give some recognition, but I am "just" a user of his patches. Would that have been difficult for you to write, Linus? Its not too late for giving Con some recognition. A simple "Hi Con, I am sorry that you decided to leave kernel development. I felt I had to make a decision about the scheduler thing and these where my concerns... I just wanted to tell you that I did not mean any personal offence with you and did not have any real issue with your code at all, Regards Linus" as an aftermath could still help. Just a little gesture maybe - but it can make a big difference. Maybe without even asking him to come back... I think Con made his decision for now at least.
Re: [ck] Re: Linus 2.6.23-rc1
Linus Torvalds wrote: The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole "eat your own dogfood" is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! That comes from someone whose desktop is a dual CPU Mac with how much RAM? 4GB? That can hardly be regarded as the average desktop computer. You cannot have computers with heaps of CPU/RAM and claim that you know how a Linux feels on a 'normal' desktop. That simply doesn't add up. So please stop saying that you're 'eating your own dogfood'. Sure, there may be kernel developers who actually test the kernels on older computers, but don't tell us that you're using those for your daily work. That being said, I can't but agree with Con what he said in his recent interview, namely that some kernel developers are out of touch with the 'normal' desktop users who have a bit slower machines (Linus, if you indeed use a desktop computer like I described above then this also applies to you). And I can't imagine that any of you have done such intensive tests of desktop responsiveness etc. like Con did. By all means I'm not a 'Con Fanboy', nor want I be involved in the whole 'CFS vs. CD' flamewar, but I simply can't let your statement leave unanswered. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: > On Sat, 28 Jul 2007, Jan Engelhardt wrote: > > You cannot please everybody in the scheduler question, that is clear, > > then why not offer dedicated scheduling alternatives (plugsched comes > > to mind) and let them choose what pleases them most, and handles > > their workload best? [...] > So I personally think that it's much better to find a setup that works > "well enough" for people, without having modal behaviour. People > complain and gripe now, but what people seem to be missing is that it's > a journey, not an end-of-the-line destination. We haven't had a single > release kernel with the new scheduler yet, so the only people who have > tried it are either > > (a) interested in schedulers in the first place (which I think is > *not* a good subset, because they have very specific expectations of > what is right and what is wrong, and they come into the whole thing > with that mental baggage) > > (b) people who test -rc1 kernels (I love you guys, but sadly, you're > not nearly as common as I'd like ;) > > so the fact is, we'll find out more information about where CFS falls > down, and where it does well, and we'll be able to *fix* it and tweak > it. I have nothing against CFS in the kernel. I had as long as my ThinkPad T23 had interruptions in music playback initially even though the machine was idling - while at the same time music playback was perfectly fine with SD since quite some iterations. After quite some iterations of testing new CFS versions from Ingo it started working like I think it should. Expecting a interruption free music playback IMO by no way is any mental baggage. I for sure am interested in schedulers, but actually I do not understand the exact principles by with SD and CFS work, I just had no time to look at them closer, and thus just looked at: How does it behave on my laptops with different desktop loads? Actually from a technical point of view I do not care whether CFS or SD goes in, cause I simply understand enough of the technical concepts behind them. And since they are behaving roughly the same on my laptops now I have no issue with CFS going in from a functional view. It seems to do what I expect from a scheduler and I am happy with that. While I have nothing against CFS in the kernel, I actually do not like the way the decision was done and how it was communicated. Its not the outcome of the decision but the way it was done that bothers me. I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. I do think that it would not have been necessary to loose Con's talent. Sure I think that Con had its share in it, but it does not make sense to concentrate on his share, cause only he can do that and he is gone for now. But thats exactly what I perceive you are doing. And I realize it doesn't make sense for me at all to concentrate at your or Ingo's share. I made my point and unless you Ingo and the others involved decide to look at whether there might be something you have done that has contributed to loosing the talent of a good kernel developer the issue can't be helped. Unless people decide to look at themselves instead of pointing out what in their eyes has been wrong with others, the issue will stand still. I am pretty confident that SD in the kernel would have been a viable choice as well and that Con would have done his best to support and maintain it. Well now thats history. Con decided to stay out of kernel development and I actually can understand him. I believe it is possible to learn something out of how this all happened. And actually I merely wanted to point this out to you. Whether you decide to learn something out of it or not, actually is your choice. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: > People are suggesting that you'd have a separate "desktop kernel". > That's insane. It also shows total ignorance of maintainership, and > reality. And I bet most of the people there haven't tested _either_ > scheduler, they just like making statements. Ok, hands up again. I tested both schedulers. And I know a lot of people from the ck patchset mailing list did, despite its narrow ck patchset related topic > The fact is, I've _always_ considered the desktop to be the most > important part. And I suspect that that actually is true for most > kernel developers, because quite frankly, that's what 99% of them ends > up using. If a kernel developer uses Windows for his day-to-day work, I > sure as hell wouldn't want to have him developing Linux. That has > nothing to do with anything anti-windows: but the whole "eat your own > dogfood" is a very fundamental thing, and somebody who doesn't do that > shouldn't be allowed to be even _close_ to a compiler! > > So the whole argument about how kernel developers think that the > desktop isn't important is totally made-up crap by Con, and then > parrotted by osnews and other places. Ah, well. So where for example is a working, fast and reliable snapshot solution despite of one being available for *years*? And no, suspend to ram just doesn't cut it - its a complete nonsense for my laptop usage pattern. > And btw, "the desktop" isn't actually one single load. It's in fact a > lot of very different loads, and different people want different > things. What makes the desktop so interesting is in fact that it shows > more varied usage than any other niche - and no, 3D gaming isn't "it". 3D gaming was only *one* workload that people where happy with when running SD. > Con wass fixated on one thing, and one thing only, and wasn't > interested in anythign else - and attacked people who complained. > Compare that to Ingo, who saw that what Con's scheduler did was good, > and tried to solve the problems of people who complained. One thing? How about 1) various improvements to VM stuff and 2) swap prefetch? 3) pluggable schedulers? And various other patch sets. Con concentrated on Desktop performance thats right, but even there he didn't stop. Did you know for example that Con maintained a server related ck patchset for years as well? Where actually is that "Con concrentates only on one thing"? > The ck mailing list is/was also apparently filled with people who all > had the same issues, which is seriously the *wrong* thing to do. Just one question: Did you actually look there *before* making above statement? Can you give a honest answer to this question? > So if you are going to have issues with the scheduler, which one do you > pick: the one where the maintainer has shown that he can maintain > schedulers for years, can can address problems from _different_ areas > of life? Or the one where the maintainer argues against people who > report problems, and is fixated on one single load? Do you have any concrete example? I have only one, one out of countless responses of Con to people how reported problems: The X11 renice issue. If I requested from Ingo to make a scheduler exception that contradicts the design of CFS and I could not convince Ingo that this exception really does make sense, I think I will get into a discussion with Ingo - and exactly that makes perfect sense to me! Actually Ingo did have renicing for X and kernel threads in CFS for quite a while as well. Still that said, I admit that the tone may well have played a role here - as it does in this discussion as well. Maybe Con reacted hurt where no offence was meant at times. But we are all humans, and given all the unfriendlyness Con apparently faced I can understand this. "survival of the fittest maintainer"? Maybe. But I invite you to listen on the last results in biological reasons: Darwins "survival of the fitttest" is only one principle and doesn't explain how lifing beings put themselves together at all. Biologist find out more and more than the genome is no command central at all, but being used by living beings in the way their complex parts being interacting with one another see fit. One should take the tone in this discussion into account. Cause now one can argue that Con doesn't want to maintain the SD scheduler. Well thats true, but once he was more than willing to do that and IMHO he reacted to at least most problem reports in a very professional manner. Maybe not to 100% of them, but can you actually say that from Ingo? From what I seen Ingo also is a human... Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: People are suggesting that you'd have a separate desktop kernel. That's insane. It also shows total ignorance of maintainership, and reality. And I bet most of the people there haven't tested _either_ scheduler, they just like making statements. Ok, hands up again. I tested both schedulers. And I know a lot of people from the ck patchset mailing list did, despite its narrow ck patchset related topic The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole eat your own dogfood is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! So the whole argument about how kernel developers think that the desktop isn't important is totally made-up crap by Con, and then parrotted by osnews and other places. Ah, well. So where for example is a working, fast and reliable snapshot solution despite of one being available for *years*? And no, suspend to ram just doesn't cut it - its a complete nonsense for my laptop usage pattern. And btw, the desktop isn't actually one single load. It's in fact a lot of very different loads, and different people want different things. What makes the desktop so interesting is in fact that it shows more varied usage than any other niche - and no, 3D gaming isn't it. 3D gaming was only *one* workload that people where happy with when running SD. Con wass fixated on one thing, and one thing only, and wasn't interested in anythign else - and attacked people who complained. Compare that to Ingo, who saw that what Con's scheduler did was good, and tried to solve the problems of people who complained. One thing? How about 1) various improvements to VM stuff and 2) swap prefetch? 3) pluggable schedulers? And various other patch sets. Con concentrated on Desktop performance thats right, but even there he didn't stop. Did you know for example that Con maintained a server related ck patchset for years as well? Where actually is that Con concrentates only on one thing? The ck mailing list is/was also apparently filled with people who all had the same issues, which is seriously the *wrong* thing to do. Just one question: Did you actually look there *before* making above statement? Can you give a honest answer to this question? So if you are going to have issues with the scheduler, which one do you pick: the one where the maintainer has shown that he can maintain schedulers for years, can can address problems from _different_ areas of life? Or the one where the maintainer argues against people who report problems, and is fixated on one single load? Do you have any concrete example? I have only one, one out of countless responses of Con to people how reported problems: The X11 renice issue. If I requested from Ingo to make a scheduler exception that contradicts the design of CFS and I could not convince Ingo that this exception really does make sense, I think I will get into a discussion with Ingo - and exactly that makes perfect sense to me! Actually Ingo did have renicing for X and kernel threads in CFS for quite a while as well. Still that said, I admit that the tone may well have played a role here - as it does in this discussion as well. Maybe Con reacted hurt where no offence was meant at times. But we are all humans, and given all the unfriendlyness Con apparently faced I can understand this. survival of the fittest maintainer? Maybe. But I invite you to listen on the last results in biological reasons: Darwins survival of the fitttest is only one principle and doesn't explain how lifing beings put themselves together at all. Biologist find out more and more than the genome is no command central at all, but being used by living beings in the way their complex parts being interacting with one another see fit. One should take the tone in this discussion into account. Cause now one can argue that Con doesn't want to maintain the SD scheduler. Well thats true, but once he was more than willing to do that and IMHO he reacted to at least most problem reports in a very professional manner. Maybe not to 100% of them, but can you actually say that from Ingo? From what I seen Ingo also is a human... Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: On Sat, 28 Jul 2007, Jan Engelhardt wrote: You cannot please everybody in the scheduler question, that is clear, then why not offer dedicated scheduling alternatives (plugsched comes to mind) and let them choose what pleases them most, and handles their workload best? [...] So I personally think that it's much better to find a setup that works well enough for people, without having modal behaviour. People complain and gripe now, but what people seem to be missing is that it's a journey, not an end-of-the-line destination. We haven't had a single release kernel with the new scheduler yet, so the only people who have tried it are either (a) interested in schedulers in the first place (which I think is *not* a good subset, because they have very specific expectations of what is right and what is wrong, and they come into the whole thing with that mental baggage) (b) people who test -rc1 kernels (I love you guys, but sadly, you're not nearly as common as I'd like ;) so the fact is, we'll find out more information about where CFS falls down, and where it does well, and we'll be able to *fix* it and tweak it. I have nothing against CFS in the kernel. I had as long as my ThinkPad T23 had interruptions in music playback initially even though the machine was idling - while at the same time music playback was perfectly fine with SD since quite some iterations. After quite some iterations of testing new CFS versions from Ingo it started working like I think it should. Expecting a interruption free music playback IMO by no way is any mental baggage. I for sure am interested in schedulers, but actually I do not understand the exact principles by with SD and CFS work, I just had no time to look at them closer, and thus just looked at: How does it behave on my laptops with different desktop loads? Actually from a technical point of view I do not care whether CFS or SD goes in, cause I simply understand enough of the technical concepts behind them. And since they are behaving roughly the same on my laptops now I have no issue with CFS going in from a functional view. It seems to do what I expect from a scheduler and I am happy with that. While I have nothing against CFS in the kernel, I actually do not like the way the decision was done and how it was communicated. Its not the outcome of the decision but the way it was done that bothers me. I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. I do think that it would not have been necessary to loose Con's talent. Sure I think that Con had its share in it, but it does not make sense to concentrate on his share, cause only he can do that and he is gone for now. But thats exactly what I perceive you are doing. And I realize it doesn't make sense for me at all to concentrate at your or Ingo's share. I made my point and unless you Ingo and the others involved decide to look at whether there might be something you have done that has contributed to loosing the talent of a good kernel developer the issue can't be helped. Unless people decide to look at themselves instead of pointing out what in their eyes has been wrong with others, the issue will stand still. I am pretty confident that SD in the kernel would have been a viable choice as well and that Con would have done his best to support and maintain it. Well now thats history. Con decided to stay out of kernel development and I actually can understand him. I believe it is possible to learn something out of how this all happened. And actually I merely wanted to point this out to you. Whether you decide to learn something out of it or not, actually is your choice. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: On Sat, 28 Jul 2007, Diego Calleja wrote: El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: So modal things are good for fixing behaviour in the short run. But they are a total disaster in the long run, and even in the short run they tend to have problems (simply because there will be cases that straddle the line, and show some of _both_ issues, and now *neither* mode is the right one) I fully agree with this, but plugsched could have avoided this useless division on the topic of SD vs CFS. IMO that counts as an advantage, too ;) Sure. I actually think it's a huge advantage (see the ManagementStyle file on pissing people off), but at the same time, I don't like playing politics with technology. The kernel is a technical project, and I make technical decisions. IMHO thats an illusion. The kernel has become a community project pretty soon after you have released it initially. And the community members are human beings. Thus while the kernel source code in itself for sure describes technical processes, the kernel is more than just a technical project. So I absolutely detest adding code for political reasons. I can understand this and I agree to it, cause it would mean fixing political things on technical grounds and thus not fixing them at all. I personally feel that modal behaviour is bad, so it would introduce what is in my opinion bad code, and likely result in problems not being found and fixed as well (because people would pick the thing that works for them, and ignore the problems in the other module). So while I don't like making irreversible decisions (and the choice of CFS wasn't irreversible in itself, but if it pisses off Con, _that_ is generally not reversible), I dislike even more making a half-assed decision. I agree to this to some extent. But if the mainline kernel does not contain suitable solutions for one subsystem people will tend to plug in other solutions that work for them even where there is no boot or runtime plugability. I have been using TuxOnIce (formerly suspend2) for quite some time and didn't even try the in-kernel-suspend-to-disk stuff since quite some kernel versions since I could not have been bothered anymore after it was failing back then. So when there are two different approaches with good following it may have be good to have some plugability for testing things. But it may be difficult to remove it afterwards again..., but it would still be possible to remove plugins that are only used rarely and they how the other ones evolve. So rather than making a choice at all, my other choice would have been to not merge _either_ scheduler, and let people just continue to fight it out. Would that have made people happier? I seriously doubt it. I tried speaking to Con and Ingo whether they could settle their issue with one another and work together. In *private* mails, away from all the flame throwing. Actually I believe that human things should be resolved on the human side, not on the technical one. And as I perceive no serious attempt has been made on that - except my own maybe. Maybe just writing an email to both Con and Ingo where you told both of them your concerns and thoughts would have helped a lot. A Hi Con and Ingo, Con, I do not believe that you are able to maintain SD for reason 1,2 and 3. But I do think that Ingo could. But I think, that you wrote great code and brought in good scheduler concepts and ideas to the Linux world. Now Ingo has CFS and you have SD... could there be a way for you to stay involved with scheduler issues and work together with Ingo? If so how could it look like? Ingo, do you see areas where Con can help you with? Are there things in SD that you would like to have in CFS? Do you see a way to work with Con together on the scheduler? (just a draft;-) for example. It would have given Con some recognition for his work. It could have helped to address the political, well not even the political, but the human issue here. I believe that this is what Con missed the most: Getting some form of recognition from the official kernel people! I tried to give some recognition, but I am just a user of his patches. Would that have been difficult for you to write, Linus? Its not too late for giving Con some recognition. A simple Hi Con, I am sorry that you decided to leave kernel development. I felt I had to make a decision about the scheduler thing and these where my concerns... I just wanted to tell you that I did not mean any personal offence with you and did not have any real issue with your code at all, Regards Linus as an aftermath could still help. Just a little gesture maybe - but it can make a big difference. Maybe without even asking him to come back... I think Con made his decision for now at least. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
Re: [ck] Re: Linus 2.6.23-rc1
Linus Torvalds wrote: The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole eat your own dogfood is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! That comes from someone whose desktop is a dual CPU Mac with how much RAM? 4GB? That can hardly be regarded as the average desktop computer. You cannot have computers with heaps of CPU/RAM and claim that you know how a Linux feels on a 'normal' desktop. That simply doesn't add up. So please stop saying that you're 'eating your own dogfood'. Sure, there may be kernel developers who actually test the kernels on older computers, but don't tell us that you're using those for your daily work. That being said, I can't but agree with Con what he said in his recent interview, namely that some kernel developers are out of touch with the 'normal' desktop users who have a bit slower machines (Linus, if you indeed use a desktop computer like I described above then this also applies to you). And I can't imagine that any of you have done such intensive tests of desktop responsiveness etc. like Con did. By all means I'm not a 'Con Fanboy', nor want I be involved in the whole 'CFS vs. CD' flamewar, but I simply can't let your statement leave unanswered. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) [EMAIL PROTECTED] escribió: The scheduler could have and still can undertake good solid transformation, but getting folks to listen is another story which is why Con quit. CFS basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. This time it was Con being the Mindcraft catalyst. But he's on *our* side and he got beat down by the Linux kernel community. That's the tragedy here. He was beaten down by the very people he was trying to help out and support. It should have been handled better. Get real: I don't the linux development has always been friendly. The idea of a GNU-hippie community where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. And aside from that there has been communication before and after this event that IMHO could have been better. And thats not only targetted at Ingo. A view this whole issue as everyone who was involved in it, actually was involved in it and has his share in its outcome. So everyone has a great chance to learn something out of it. (That includes me of course, too.) Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Diego Calleja: This time it was Con being the Mindcraft catalyst. But he's on *our* side and he got beat down by the Linux kernel community. That's the tragedy here. He was beaten down by the very people he was trying to help out and support. It should have been handled better. Get real: I don't the linux development has always been friendly. The idea of a GNU-hippie community where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. Actually I have seen friendly communities around Linux and free software. Like the KDE project, the ck patchset mailing list community, the TuxOnIce aka suspend2 community, the SGI XFS community, the Bazaar community, quite some parts of the Debian community just to name a few. So I know that it can be different. I know that its inaccurate to talk about the whole Linux kernel community. I had quite friendly contacts with core Linux developers like with Ingo (yes, with Ingo!;-) or Greg Kroah-Hartman. So what would be wrong with looking at how this worked out and why and how it would be possible to avoid loosing a talented developer? -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Hi Martin, On Sun, 29 Jul 2007, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo Sending out the code (and early enough, 48 hours /is/ early enough) *is* the normal (and good) way to do exactly the communication you described above, IMHO. I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. IMHO, what you're suggesting is: (1) not the way development normally happens in Linux, and, (2) not the way it /should/ happen, either. If there's something (subsystem, any code big or small) I think I can do better or have an idea for, I /should/ be able to just hack on it a bit and then send it out so everybody can comment on it. Why should I be forced to dance/discuss around with some other people, when the faster and more effective way would be just present the code/patch that I have in my mind as an RFC? See, Martin, in the end it's not about developer A vs developer B. It's about making the kernel the best out there -- that's what the users want, anyway. Yes, I fully understand (and have said so earlier myself) that there's a very important social aspect to development on such projects, but it's best if developer B understands that this is the way things do (and should) happen and adapt to it. [ It's not like I've been around for long, however, but the above is still my opinion, fwiw. ] Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Satyam Sharma: Hi Martin, Hi Satyam, I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. IMHO, what you're suggesting is: (1) not the way development normally happens in Linux, and, (2) not the way it /should/ happen, either. If there's something (subsystem, any code big or small) I think I can do better or have an idea for, I /should/ be able to just hack on it a bit and then send it out so everybody can comment on it. Why should I be forced to dance/discuss around with some other people, when the faster and more effective way would be just present the code/patch that I have in my mind as an RFC? Hmmm, that email would have taken how long? 5 minutes maybe? I just feel that I would have written it if I happen to know that another developer spent lots of time and effort into a subsystem I plan to rewrite. Its just human logic to me. Especially when I happen to know that the other developer may be new to the kernel development process as I know it from a internal view point. The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. I always believed that kernel developers are human beings and no robots. And thus the kernel development process IMHO should be designed with human developers in mind instead of robots which take no offence out of anything. Otherwise things like what happened here will happen again and again and again and talent is lost. It is damn good to take technical merits into full account! But ignoring human aspects of development actually will hinder this. Cause then in the end its not about technical merits anymore that do the decision, but that human aspects that have been ignored and are floating around unconsiously. Actually I do believe that this discussion already took more resources than actually writing a few more mails and doing a bit more communication here and there... IMHO the fact that this discussion exists already shows that something in the process of submitting kernel patches and supporting involvement in kernel development can be improved upon. See, Martin, in the end it's not about developer A vs developer B. It's about making the kernel the best out there -- that's what the users want, anyway. Yes, I fully understand (and have said so earlier myself) that there's a very important social aspect to development on such projects, but it's best if developer B understands that this is the way things do (and should) happen and adapt to it. [ It's not like I've been around for long, however, but the above is still my opinion, fwiw. ] I am not saying that developer B (Con) does not have his share in how it all happened. As written before I got the impression that Con reacted hurt where from my point of view no offence was meant - and I told him that. But from what I know it would have been possible to actually deal with that quite a bit better than has happened. And it would not have taken much effort. Well actually I think it would have been quite easy to take the talent that has offered itself. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 08:23:31PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. The usual way to communicate such things on lkml are with patches as also happened in this case. It's not like Ingo had secretly developing a scheduler in parallel for weeks or months but. But I assume all the fuzz is about something else - it cannot be about a these 48 hours - I hope.. Enough on this - back to work. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
* Satyam Sharma [EMAIL PROTECTED] wrote: So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo Sending out the code (and early enough, 48 hours /is/ early enough) *is* the normal (and good) way to do exactly the communication you described above, IMHO. yeah. And note that the time from the ok, this approach might work point to releasing CFS was even less than the original ~62 hours of CFS development. I dont typically write code because i'm particularly convinced about an idea or because i believe in an idea, i mostly write code to _check_ whether an idea is worth advancing or not. Writing code is my form of thinking, and releasing patches is my form of telling others about my thoughts. I might have guesses about how well something will work out in practice (and i'd certainly be a fool to go out coding blindly), but surprises happen almost always, both in positive and in negative direction, and even with relatively simple patches. CFS started out as an experiment to simplify the scheduler, to clean up the after-effects of a better-desktop-scheduling patch Mike Galbraith sent me. Had anyone told me at that time that i'd end up writing a new scheduler i'd have laughed at the suggestion and i'd have pointed to the large number of pending patches of mine in forms of the -rt tree, the syslet/threadlet code and other stuff that needs fixing a lot more urgent than the task scheduler. During that cleanup work did i realize how a policy-modularized scheduler would allow the bridging of the seemingly unreconcilable friction between the O(1) data structures that things like RT scheduling needs and the binary tree that fair share scheduling concepts dictate. (most of the complexity in kernel code like the scheduler derives from complexity in data structures, so you start writing code by thinking about your data structures.) And the time from the point where i thought ok, this fair-share thing behaves pretty well and it certainly looks simpler than the current code to the announcement on lkml was more on the order of hours than days - much of the 62 hours were spent on ripping out the old code and on getting the new design up and running. There was simply no code in existence before CFS which has proven the code simplicity/design virtues of 'fair scheduling' - SD was more of an argument _against_ it than for it. I think maybe even Con might have been surprised by that simplicity: in his first lkml reaction to CFS he also wrote that he finds the CFS code beautiful: http://lkml.org/lkml/2007/4/14/199 and my reply to Con's mail: http://lkml.org/lkml/2007/4/15/64 still addresses a good number of points raised in this thread i think. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 16:31 +0200, Diego Calleja wrote: El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) [EMAIL PROTECTED] escribió: The scheduler could have and still can undertake good solid transformation, but getting folks to listen is another story which is why Con quit. CFS basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. Absolutely. Con quit for his own reasons. Given that Con himself has said that CFS was _not_ why he quite, please discard this... bait. Anyone who's name isn't Con Kolivas, who pretends to speak for him is at the very least overstepping his bounds, and that is being _very_ generous. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote: Absolutely. Con quit for his own reasons. Given that Con himself has said that CFS was _not_ why he quite, please discard this... bait. Anyone who's name isn't Con Kolivas, who pretends to speak for him is at the very least overstepping his bounds, and that is being _very_ generous. I know Con personally and I completely identify with his circumstance. This is precisely why he quit the project because of a generally perceived ignorance and disconnect from end users. Since you side with Ingo on many issues politically, this response from you is no surprise. Again, the choices that have been currently made with CFS basically locks him out of development. If you don't understand that, then you don't understand the technical issues he's struggled to pursue. He has a large following which is why this has been a repeated and issue between end users of his tree and a number of current Linux kernel developers. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 14:48 -0700, Bill Huey wrote: On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote: Absolutely. Con quit for his own reasons. Given that Con himself has said that CFS was _not_ why he quite, please discard this... bait. Anyone who's name isn't Con Kolivas, who pretends to speak for him is at the very least overstepping his bounds, and that is being _very_ generous. I know Con personally and I completely identify with his circumstance. This You're still not Con, and I still think it's inappropriate for any person to speak for another unless that person is the designated proxy. is precisely why he quit the project because of a generally perceived ignorance and disconnect from end users. Since you side with Ingo on many issues politically, this response from you is no surprise. Hm. I don't recall entering the world of politics. Where's my cool lapel button? -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On 7/30/07, Linus Torvalds [EMAIL PROTECTED] wrote: For example, how hard is it for people to just admit that CFS actually does better than SD on a number of things? Including very much on the desktop. Actually in benchmarks Ingo has quoted, SD was better on the desktop (by a small margin). CFS is still a bit bursty, though it has significantly improved with age. I know, I did those benchmarks. That being said, I'm really glad to see CFS in your git tree because the new framework around it really improves the readability of the code, and actually makes it easier to start experimenting with scheduler improvements from an entire scheduler like SD to minor bits like priorities. I have one concern - my benchmarking took load average as the common denominator and CFS alters the way the load average is calculated, so perhaps it wasn't a fair comparison. That being said, they still showed CFS could scale very well and SD did not, so considering we're dealing with everything from wristwatches to BlueGene/L I believe the right choice was made. Those arguing for the 2% improvement that SD would give them in their environment would be better off a) helping port SD to the new scheduler framework b) assisting Ingo in improving CFS to meet/exceed their requirements c) giving practical assistance to anyone doing either of the above I'm re-learning git and using my Copious Spare Time (tm) to do what I can - but I have to admit I'm really in over my head. But hey, if Jeff Garzik can do it, so can I. I remember when he couldn't grok C now he's got control over all our data :-) -- Matt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
> It's like CONFIG_HZ - more or less often debated, and now we have everyone > happy by giving them the choice. That's an interesting analogy -- since really the right answer there seems not to be modal at all, but rather to do CONFIG_NO_HZ. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Con Kolivas <[EMAIL PROTECTED]> writes: > Interesting... Trying to avoid reading email but with a flooded inbox > it's quite hard to do. Con, good to hear from you. Good luck with your future endeavors. Charles -- "Are [Linux users] lemmings collectively jumping off of the cliff of reliable, well-engineered commercial software?" (By Matt Welsh) pgp22bG9rBbnK.pgp Description: PGP signature
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, Jul 28, 2007 at 03:18:24PM -0700, Linus Torvalds wrote: > I don't think anything was suppressed here. I disagree. See below. > You seem to say that more modular code would have helped make for a nicer > way to do schedulers, but if so, where were those patches to do that? > Con's patches didn't do that either. They just replaced the code. They replaced code because he would have liked to have taken scheduler code in possibly a completely different direction. This is a large conceptual change from what is currently there. That might also mean how the notion of bandwidth with regards to core frequency might be expressed in the system with regards to power saving and other things. Things get dropped often not because of pure technical reasons but because of person preference and the lack of willingness to ask where this might take us. The way that Con works and conceptualizes things is quite a bit different and more comprehensive in a lot of ways compared to how the regular kernel community operates. He's strong in this area and weak in general kernel hackery as a function of time and experience. That doesn't mean that he, his ideas and his code should be subject to an either/or situation with the scheduler and other ideas that have been rejected by various folks. He maintained -ck branch successfully for a long time and is a very capable developer. I do acknowledge that having a maintainer that you can trust is more important, but it should not be exclusionary in this way. I totally understand his reaction. > In fact, Ingo's patches _do_ add some modularity, and might make it easier > to replace the scheduler. So it would seem that you would argue for CFS, > not against it? It's not the same as sched plugin. Some folks might not like to use the rbtree that's in place and express things in a completely different manner. Take for instance, Tong Li's stuff with CFS a bit of a conceptual mismatch with his attempt at expression rebalancing in terms expiry rounds yet would be more seamlessly integrated with something like either the old O(1) scheduler or Con's stuff. It's also the only method posted to lkml that can deal with fairness across SMP situtations with low error. Yet what's happening here is that his implementation is being rejected because of size and complexity because of a data structure conceptual mismatch. Because of this, his notion of trio as a general method of getting aggressive group fairness (by far the most complete conceptually on lkml, over design is a different topic altogether) may never see the light of day in Linux because of people's collective lack of foresight. To answer the question that you posed, no. I'm not arguing against it. I'm in favor of it going into the kernel like any dead line mechanism since it can be generalized, but the current developement processes in Linux kernel should not create an either/or situation with the scheduler code. There has been multipule rejection of ideas with regards to the scheduler code over the years that could have take things in a very different and possibly complete kick ass way that was suppress because of the development attitude of various Linux kernel developers. It's all of a sudden because of Con's work there's a flurry of development in this area when this idea is shown to be superior and even then, it's conceptually incomplete and subject to a lot of arbitrary hacking. This is very different than Con's development style and mine as well. This is an area that could have been addressed sooner if the general community admitted that there was a problem earlier and permitted more conscious and open change. I've seen changes in this area from Con be reject time and time again which effect the technical direction he originally wanted to take this. Now, Con might have a communication problem here, but nobody asked to clarify what he might have wanted and why, yet folks were very quick at dismissing him, nitpick him to death, even when he explained why he might have wanted a particular change in the first place. This is the "facilitation" part that's missing in the current kernel culture. This is a very important idea as the community grows, because I see folks that are capable of doing work get discouraged and locked out because of code maintainability issues and an inability to get folks to move that direction because of a missing concensus mechanism in the community other that sucking up to developers. Con and folks like him should be permitted the opportunity to fail on their own account. If Linux was truely open, it would have dealt with issue by now and there wouldn't be so much flammage from the general community. > > I think that's kind of a bogus assumption from the very get go. Scheduling > > in Linux is one of the most unevolved systems in the kernel that still > > could go through a large transformation and get big gains like what > > we've had over the last few months. This evident with both
Re: [ck] Re: Linus 2.6.23-rc1
Interesting... Trying to avoid reading email but with a flooded inbox it's quite hard to do. A lot of useful discussion seems to have generated in response to people's _interpretation_ of my interview rather than what I actually said. For example, everyone seems to think I quit because CFS was chosen over SD (hint: it wasn't). Since it's generating good discussion I'll otherwise leave it as is. As a parting gesture; a couple of hints for CFS. Any difference in behaviour between CFS and SD since they both aim for fairness would come down to the way they interpret fair. Since CFS accounts sleep time whereas SD does not, that would be the reason. As for volanomark regressions, they're always the sched_yield implementation. SD addressed a similar regression a few months back. Good luck. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Linus Torvalds wrote: I personally feel that modal behaviour is bad, so it would introduce what is in my opinion bad code, and likely result in problems not being found and fixed as well (because people would pick the thing that "works for them", and ignore the problems in the other module). I'm sorry, but this argument doesn't hold water. It was invoked years ago and turned out to be incorrect - the new CFS scheduler is not just a fixed old scheduler, it's a completely redesigned one. -- With respect, Alex Besogonov ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Bill Huey wrote: > > My argument is that schedule development is open ended. Although having > a central scheduler to hack is a a good thing, it shouldn't lock out or > supress development from other groups that might be trying to solve the > problem in unique ways. I don't think anything was suppressed here. You seem to say that more modular code would have helped make for a nicer way to do schedulers, but if so, where were those patches to do that? Con's patches didn't do that either. They just replaced the code. In fact, Ingo's patches _do_ add some modularity, and might make it easier to replace the scheduler. So it would seem that you would argue for CFS, not against it? > I think that's kind of a bogus assumption from the very get go. Scheduling > in Linux is one of the most unevolved systems in the kernel that still > could go through a large transformation and get big gains like what > we've had over the last few months. This evident with both schedulers, > both do well and it's a good thing overall the CFS is going in. > > Now, the way it happened is completely screwed up in so many ways that I > don't see how folks can miss it. This is not just Ingo versus Con, this > is the current Linux community and how it makes decision from the top down > and the current cultural attitude towards developers doing things that > are: I don't think so. I think you're barking up the totally wrong tree here. I think that what happened was very simple: somebody showed that we did badly and had benchmarks to show for it, and that in turn resulted in a huge spurt of coding from the people involved. The fact that you think this is "broken" is interesting. I can point to a very real example of where this also happened, and where I bet you don't think the process was "broken". Do you remember the mindcraft study? Exact same thing. Somebody came in, and showed that Linux did really badly on some benchmark, and that an alternate approach was much better. What happened? A huge spurt of development in a pretty short timeframe, that totally _obliterated_ the mindcraft results. It could have happened independently, but the fact is, it didn't. These kinds of events where somebody shows (with real numbers and code) that things can be done better really *are* a good way to do development, and it's how development generally ends up happening. It's hugely motivational, both because competition is motivational in itself, but also because somebody shows that things can be done so much better opens peoples eyes to it. And if you think the scheduler situation is different, why? Was it just because the mindcraft study compared against Windows NT, not another version of Linux patches? The thing is, development is slow and gradual, but at the same time, it happens in spurts (btw, if you have ever studied evolution, you'll find the exact same thing: evolution is slow and gradual, but it also happens in sudden "spurts" where you have relatively much bigger changes happening because you get into a feedback loop). Another comparison to evolution: most of the competitive pressure actually comes from the _same_ species, not from outside. It's not so much rabbits competing against foxes (although that happens too), quite a lot of it is rabbits competing against other rabbits! Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, Jul 28, 2007 at 11:06:09PM +0200, Diego Calleja wrote: > So your argument is that SD shouldn't have been merged either, because it > would have resulted in one scheduler over the other? My argument is that schedule development is open ended. Although having a central scheduler to hack is a a good thing, it shouldn't lock out or supress development from other groups that might be trying to solve the problem in unique ways. This can be accomplished in a couple of ways: 1) scheduler modularity Clearly Con is highly qualified to experiement with scheduler code and this should be technically facilitate by some means if not a maintainer. He's only a part time maintainer and nobody helped him with this stuff nor did they try to understand what his scheduler was trying to do other than Tong Li. 2) better code modularity Now, cleaner code would help with this a lot. If that was in place, we might not need (1) and pluggable scheduler. It would limit the amount of refactoring for folks so that their code can drop in easier. There's a significant amount of churn that it locks out developers by default since they have to constantly clean up the code in question while another developer can commit without consideration to how it effects others. That's their right as a maintainer, but also as maintainer, they should give proper amount of consideration to how others might intend to extend the code so that development remains "inclusive". This notion of "open source, open development" is false when working under those circumstances. > > where capable but one is locked out now because of the choices of > > current high level kernel developers in Linux. > > Well, there are two schedulers...it's obvious that "high level kernel > developers" needed to chose one. I think that's kind of a bogus assumption from the very get go. Scheduling in Linux is one of the most unevolved systems in the kernel that still could go through a large transformation and get big gains like what we've had over the last few months. This evident with both schedulers, both do well and it's a good thing overall the CFS is going in. Now, the way it happened is completely screwed up in so many ways that I don't see how folks can miss it. This is not just Ingo versus Con, this is the current Linux community and how it makes decision from the top down and the current cultural attitude towards developers doing things that are: 1) architecturally significant which they will get flamed to death by the establish Linux kernel culture before they can get any users to report bugs after their posting on lkml. 2) conceptual different which is subject to the reasons above, but also get flamed to death unless it comes from folks internal to the Linux development processes. When groups get to a certain size like it has, there needs to be a revision of development processes so that they can scale and be "inclusive" to the overall spirit the Linux development process. When that breaks down, we get situations like what we have with Con leaving development. Other developers like me get turned off to the situation, also feel the same as Con and stop Linux development. That's my current status as well. > The main problem is clearly that no scheduler was clearly better than the > other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both > of them were good enought, but only one of them could be merged. The > difference is that EVMS developers didn't get that annoyed, and not only > they didn't quit but they continued developing their userspace tools to > make it work with the solution included in the kernel That's a good point to have folks not go down that particular path. But Con was kind of put down during the arguments with Ingo about his assumptions of the problems and then was personally crapped on by having his own idea under go a a complete reversal in opinion by Ingo, with Ingo then doing this own version of Con's work displacing him How would you feel in that situation ? I'd be pretty damn pissed. [For the record Peter Zijlstra did the same thing to me which is annoying, but since he's my buddy doesn't get as rude as the above situation, included me in every private mail about his working so that I don't feel like RH is paying him to undermine my brilliance, it's ok :)] bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Diego Calleja wrote: > El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> > escribió: > > > > So "modal" things are good for fixing behaviour in the short run. But they > > are a total disaster in the long run, and even in the short run they tend > > to have problems (simply because there will be cases that straddle the > > line, and show some of _both_ issues, and now *neither* mode is the right > > one) > > I fully agree with this, but plugsched could have avoided this useless > "division" > on the topic of SD vs CFS. IMO that counts as an advantage, too ;) Sure. I actually think it's a huge advantage (see the ManagementStyle file on pissing people off), but at the same time, I don't like playing politics with technology. The kernel is a technical project, and I make technical decisions. So I absolutely detest adding code for "political" reasons. I personally feel that modal behaviour is bad, so it would introduce what is in my opinion bad code, and likely result in problems not being found and fixed as well (because people would pick the thing that "works for them", and ignore the problems in the other module). So while I don't like making irreversible decisions (and the choice of CFS wasn't irreversible in itself, but if it pisses off Con, _that_ is generally not reversible), I dislike even more making a half-assed decision. So rather than making a choice at all, my other choice would have been to not merge _either_ scheduler, and let people just continue to fight it out. Would that have made people happier? I seriously doubt it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Fri, 2007-07-27 at 19:35 -0700, Linus Torvalds wrote: > As a long-term maintainer, trust me, I know what matters. And a person who > can actually be bothered to follow up on problem reports is a *hell* of a > lot more important than one who just argues with reporters. > > Linus Once again linus blows a nut getting off about this and that. The fact of the matter linus is a one sided. The fact is linus says what he wants and people think he is god. The fact is noone get code in unless they are a major player in a linux distro. Ingo had much advantage by using fedora users. The fact Con did not take all bugs serious yes that is a player of the game but linus is GOD so all bow before him before he blows his back out while jacking off to his rants about how the kernel and other projects should run. Jory - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) <[EMAIL PROTECTED]> escribió: > of how crappy X is. This is an open argument on how to solve, but it > should not have resulted in really one scheduler over the other. Both So your argument is that SD shouldn't have been merged either, because it would have resulted in one scheduler over the other? > where capable but one is locked out now because of the choices of > current high level kernel developers in Linux. Well, there are two schedulers...it's obvious that "high level kernel developers" needed to chose one. The main problem is clearly that no scheduler was clearly better than the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both of them were good enought, but only one of them could be merged. The difference is that EVMS developers didn't get that annoyed, and not only they didn't quit but they continued developing their userspace tools to make it work with the solution included in the kernel (http://lwn.net/Articles/14714/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Jul 28 2007 22:51, Diego Calleja wrote: >El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> >escribió: > >> So "modal" things are good for fixing behaviour in the short run. But they >> are a total disaster in the long run, and even in the short run they tend >> to have problems (simply because there will be cases that straddle the >> line, and show some of _both_ issues, and now *neither* mode is the right >> one) > >I fully agree with this, but plugsched could have avoided this useless >"division" >on the topic of SD vs CFS. IMO that counts as an advantage, too ;) > It's like CONFIG_HZ - more or less often debated, and now we have everyone happy by giving them the choice. Jan --
Re: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > So "modal" things are good for fixing behaviour in the short run. But they > are a total disaster in the long run, and even in the short run they tend > to have problems (simply because there will be cases that straddle the > line, and show some of _both_ issues, and now *neither* mode is the right > one) I fully agree with this, but plugsched could have avoided this useless "division" on the topic of SD vs CFS. IMO that counts as an advantage, too ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, jos poortvliet wrote: > > Your point here seems to be: this is how it went, and it was right. Ok, got > that. But I wanted to bring out more than what you make sound like "that's what happened, deal with it". I tried to explain _why_ the choices that were made were in fact made. And it's a (I think) important thing for people to be aware of. The fact is, "personality" and "work with the other developers" is a big issue. You cannot just go off and do your own thing in your private world, and then expect it to be accepted without any discussion or other people showing up and doing alternate things. That's _especially_ true in an area that has a respected and working maintainer. >Yet, Con walked away (and not just over SD). Seeing Con go, I wonder > how many did leave without this splash. We've had people go with a splash before. Quite frankly, the current scheduler situation looks very much like the CML2 situation. Anybody remember that? The developer there also got rejected, the improvement was made differently (and much more in line with existing practices and maintainership), and life went on. Eric Raymond, however, left with a splash. It's not common, but it's not unheard of. Anybody who thinks that developers don't have huge egos probably haven't ever met a software engineer. And I suspect kernel people have bigger egos than most. No wonder there are clashes every once in a while - it's a wonder there aren't _more_ of them. > How and why? And is it due to a deeper problem? Well, one part of it is that the way to make changes in the kernel community is to do them incrementally. Small and incremental improvements are much easier to merge. If you go off and rewrite a subsystem, you shouldn't expect it to get merged, at least not unless it can live side-by-side with the old one (the new firewire stack is an example of that, and most filesystems are this way too). And the closer to some central part you get, the harder that gets. So the *bulk* of the kernel stuff can be handled either incrementally, or side-by-side, and as a result, you actually seldom see issues like this. The kernel is extremely modular, and a large reason for that is exactly to avoid couplings. Some (very few) things cannot be done incrementally. That's why I bring up CML2 as a fairly good example of this having happened before. Some things require flag-days. But you should pretty much *assume* that if there is a flag-day, and if there is a maintainer, the maintainer has to be involved. Does "maintainership" give infinite powers? No. I'll take patches that bypass maintainers, but there needs to be some reason for them (ie in some sense the maintainer needs to have done a bad job, or the patch just needs to be trivial enough - or it cuts across maintainership areas - that it's not even _worth_ going through all maintainers). So maintainers aren't "everything". But they are important. You can't just ignore them and go do your own thing, and then expect it to be merged. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, Jul 28, 2007 at 09:28:36PM +0200, jos poortvliet wrote: > Your point here seems to be: this is how it went, and it was right. Ok, got > that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder > how many did leave without this splash. How many didn't even get involved at > all??? Did THAT have to happen? I don't blame you for it - the point is that > somewhere in the process a valuable kernel hacker went away. How and why? And > is it due to a deeper problem? Absolutely, the current Linux community hasn't realized how large the community has gotten and the internal processes for dealing with new developers, that aren't at companies like SuSE or RedHat, haven't been extended to deal with it yet. It comes off as elitism which it partially is. Nobody tries to facilitate or understand ideas in the larger community which locks folks like Con out that try to do provocative things outside of the normal technical development mindset. He was punished for doing so and is a huge failure in this community. Con basically got caught in a scheduler philosophical argument of whether to push a policy into userspace or to nice a process instead because of how crappy X is. This is an open argument on how to solve, but it should not have resulted in really one scheduler over the other. Both where capable but one is locked out now because of the choices of current high level kernel developers in Linux. There are a lot good kernel folks in many different communities that look at something like this and would be turned off to participating in Linux development. And I have a good record of doing rather interesting stuff in kernel. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Op Saturday 28 July 2007, schreef Linus Torvalds: > > Compare this to SD for a while. Ponder. > > Linus Your point here seems to be: this is how it went, and it was right. Ok, got that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder how many did leave without this splash. How many didn't even get involved at all??? Did THAT have to happen? I don't blame you for it - the point is that somewhere in the process a valuable kernel hacker went away. How and why? And is it due to a deeper problem? -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html A: Because it destroys the flow of the conversation Q: Why is top-posting bad? signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, jos poortvliet wrote: > > Actually, the tag you were looking for was "" > http://osnews.com/permalink.php?news_id=18350_id=259044 > > Now I wonder. Apparently, one person complaining about SD was reason to keep > it out http://osnews.com/permalink.php?news_id=18350_id=258997 > > Will this first post stop CFS from entering the kernel? You seem to be not understanding the argument. It wasn't about "one person complaining". Of *course* people will complain. That always happens, and sometimes with totally bogus complaints (the most common being "I'm not used to it"). The problem was the reaction to complaints. Ingo got lots of complaints too. He was very responsive to them (which is not something surprising - he's been doing this a long time), and while some of the tangents he went off on were definitely bogus (the whole renicing thing), they were still useful as part of the discussion. And Ingo got other - totally unrelated - developers involved too, ie the group fairness logic came from Vatsa. And he ended up supporting not just scheduler people, but also talking to the block layer people ahout the scheduler timer usage as a fast clock for block requests etc. And you have to realize that to me, as the top-level maintainer and one who seldom actually does big coding things, but just ends up making sure that people work with others, and fix the problems that crop up, *that* kind of behaviour is much much MUCH more important than the code itself. Can you see that? Can you see how big of a difference those whole approaches make? > Now I'll try to be a bit more constructive. I hope your benevolent > dictatorship allows self reflection. Nobody is very good at self-reflection, I'm afraid. > Sure, the difference in behaviour (not in code) 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 seemingly good > alternative, did THAT one stay in that long? And this argument goes for more > code 'out there', btw. Actually, nobody pushed SD to me, and neither Con nor anybody else tried to get me to merge it until some time in March of this year, I think. Do you think I go trolling for code to merge? No. I actually _require_ that people send it to me, and that I also get the feeling that people are asking for it! In other words, my job is not to "merge code" (even though I sometimes describe it that way), my job is actually largely to "say no". You shouldn't see me as the person who goes out and tries to get everything together - quite the reverse. My job is to say "too late for the merge window", or "too experimental", or "you need to show numbers" or "are there going to be any _users_ for this"? > 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'? Umm. The absolute *last* thing we want to do is to merge earlier. In fact, one of our biggest problems is that people send half-cooked stuff to me (and even more so, to Andrew). So in this case, if you've been on the CK mailing list, ask yourself: why wasn't parts of it pushed up to the standard kernel? Asking "why didn't Linus take it earlier" is exactly the wrong thing to do, since nobody even _asked_ me to. I never _ever_ got a patch saying "please merge this". Seriously. (Btw, on that note: please don't send me patches saying "please merge this". I want more than just that. I want an explanation, and I want it to be in many small pieces, and I want to feel like it got tested and is likely to be an obvious improvement). So now look at what happened to CFS: - Ingo pushed it, and has been a maintainer of the area and shown himself over years to be able to work with others and react to reports of problems. - It was fairly obviously an improvement over the previous status quo (although I expect that there will be regressions - almost nothing is ever a _pure_ improvement, if it's in any way non-trivial) - Even so, I asked for (and got) a series of independent patches. Compare this to SD for a while. Ponder. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Jan Engelhardt wrote: > > You cannot please everybody in the scheduler question, that is clear, > then why not offer dedicated scheduling alternatives (plugsched comes to mind) > and let them choose what pleases them most, and handles their workload best? This is one approach, but it's actually one that I personally think is often the worst possible choice. Why? Because it ends up meaning that you never get the cross-pollination from different approaches (they stay separate "modes"), and it's also usually really bad for users in that it forces the user to make some particular choice that the user is usually not even aware of. So I personally think that it's much better to find a setup that works "well enough" for people, without having modal behaviour. People complain and gripe now, but what people seem to be missing is that it's a journey, not an end-of-the-line destination. We haven't had a single release kernel with the new scheduler yet, so the only people who have tried it are either (a) interested in schedulers in the first place (which I think is *not* a good subset, because they have very specific expectations of what is right and what is wrong, and they come into the whole thing with that mental baggage) (b) people who test -rc1 kernels (I love you guys, but sadly, you're not nearly as common as I'd like ;) so the fact is, we'll find out more information about where CFS falls down, and where it does well, and we'll be able to *fix* it and tweak it. In contrast, if you go for a modal approach, you tend to always fixate those two modes forever, and you'll never get something that works well: people have to switch modes when they switch workloads. [ This, btw, has nothing to do with schedulers per se. We have had these exact same issues in the memory management too - which is a lot more complex than scheduling, btw. The whole page replacement algorithm is something where you could easily have "specialized" algorithms in order to work really well under certain loads, but exactly as with scheduling, I will argue that it's a lot better to be "good across a wide swath of loads" than to try to be "perfect in one particular modal setup". ] This is also, btw, why I think that people who argue for splitting desktop kernels from server kernels are total morons, and only show that they don't know what the hell they are talking about. The fact is, the work we've done on server loads has improved the desktop experience _immensely_, with all the scalability work (or the work on large memory configurations, etc etc) that went on there, and that used to be totally irrelevant for the desktop. And btw, the same is very much true in reverse: a lot of the stuff that was done for desktop reasons (hotplug etc) has been a _huge_ boon for the server side, and while there were certainly issues that had to be resolved (the sysfs stuff so central to the hotplug model used tons of memory when you had ten thousand disks, and server people were sometimes really unhappy), a lot of the big improvements actually happen because somethng totally _unrelated_ needed them, and then it just turns out that it's good for the desktop too, even if it started out as a server thing or vice versa. This is why the whole "modal" mindset is stupid. It basically freezes a choice that shouldn't be frozen. It sets up an artificial barrier between two kinds of uses (whether they be about "server" vs "desktop" or "3D gaming" vs "audio processing", or anything else), and that frozen choice actually ends up being a barrier to development in the long run. So "modal" things are good for fixing behaviour in the short run. But they are a total disaster in the long run, and even in the short run they tend to have problems (simply because there will be cases that straddle the line, and show some of _both_ issues, and now *neither* mode is the right one) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Op Saturday 28 July 2007, schreef Linus Torvalds: > On Sat, 28 Jul 2007, Michael Chang wrote: > > I do recall there is one issue on which Con wouldn't budge -- anything > > that involved boosting certain kinds of processes in the kernel. > > I did that myself, so that's a non-issue. > > No. The complaints were about the CK scheduler not being as responsive > under load as even the _old_ scheduler was. I don't know why people ignore > this fact. It was a long thread back in March or April, and I'm pretty > sure the CK mailing list was cc'd. Of course it wasn't. The speed of tasks slows proportionally with the amount of system usage. That's the whole point, and CFS can't fix that either, can it? > Sure, most people don't actually have load-averages above ten etc, but > it's important to do those well _too_. > > Linus http://osnews.com/permalink.php?news_id=18350_id=259044 Now I wonder. Apparently, one person complaining about SD was reason to keep it out http://osnews.com/permalink.php?news_id=18350_id=258997 Will this first post stop CFS from entering the kernel? Now I'll try to be a bit more constructive. I hope your benevolent dictatorship allows self reflection. Sure, the difference in behaviour (not in code) 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 seemingly good alternative, did THAT one stay in that long? And this argument goes for more code 'out there', btw. 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 there is a problem is the first step in solving it. Of course, I don't have answers - but I do feel strongly that you think there is no issue. Is there, or isn't there? And if there is, what do you plan to do about it? Your influence on the behaviour of the people around you, your 'lieutenants', is huge. Larger than you might think. And in many cases, ppl following someone behave more extreme. That's a big reason why the LKML isn't very polite nor inviting (mind you, I don't think that's necessarily a bad thing, that's up to you to decide). You might want to think about ways to improve the whole process. Again, I'm no Linus, it's your call. And you can make a big difference, I'm sure. Greetings, Jos signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
On Jul 28 2007 10:12, Linus Torvalds wrote: > >The fact is, I've _always_ considered the desktop to be the most important >part. [...] >The fact is, most kernel developers realize that Linux is used in >different places, on different machines, and with different loads. You >cannot make _everybody_ happy, but you can try to do as good a job as >possible. And doing "as good a job as possible" very much includes not >focusing on any particular load. You cannot please everybody in the scheduler question, that is clear, then why not offer dedicated scheduling alternatives (plugsched comes to mind) and let them choose what pleases them most, and handles their workload best? Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Michael Chang wrote: > > I do recall there is one issue on which Con wouldn't budge -- anything > that involved boosting certain kinds of processes in the kernel. I did that myself, so that's a non-issue. No. The complaints were about the CK scheduler not being as responsive under load as even the _old_ scheduler was. I don't know why people ignore this fact. It was a long thread back in March or April, and I'm pretty sure the CK mailing list was cc'd. Sure, most people don't actually have load-averages above ten etc, but it's important to do those well _too_. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
