The Huge Disaster Within The Linux 2.6.35 Kernel

[bulletxt]

Bullshit! If one found a regression in a software, then everyone will happily accept patches or at least a proper bug report. This, instead, is just stupid complaining about experimental software not meant to be shipped to users at all!

People like you deserve to have a toilet kernel, and then I'de love to see you saying: "hey michael, you do 24/h benchmarks and didn't say anything to us!!!"

That's what all of you complaining of Michael's work deserve.

[danij3l]

more relevant journalism, less "PTS will write this for me and i will trow in some generic text".

yes, PTS is great in acquiring test result, but author is the one that should interpret them and their causes and make them closer to wider audience.

quality over quantity FTW

P.S. titles like this one are definitely not necessary

[dyna]

Why not let people do what they are good in?

Michael's extensive benchmarks are important and needs to be done, but they are also very time consuming.
So what, now it's up to him to communicate with the developers / report bugs as well? That would also take up a lot of time, which means less benchmarking.

And even if he would report the bug and pinpoint the problem people will probably be complaining why he didn't fix it yet... Come on people it isn't a one man job...

All the info needed to create a bug report is here so almost any reader could do it. So why haven't YOU done it yet? (or me for that matter).


He could cut on the drama though. Specially the headers, but that probably gets him more hits, which i guess also mean more benchmarking in the end.


Keep up the great benchmarking Michael!

[DragonsTear]

Really. This discussion is old.

http://kerneltrap.org/Linux/Active_Merge_Windows

This was discussed over and over.... I'm disappointed of this article.

The reasons for this?

Well. You're actually doing something that is in my opinion bashing - since the discussion I pointed out above, it is clear that the merge windows are not a time for testing. If everything builds, everyones happy. When the merge window has closed, the time for squashing bugs and eliminating the most troublesome stuff has come. And when that is finished, there is normally an rc... And when there is an rc, it is time to test for regression, and trying to find out what has gone wrong.

However. It is disappointing when someone simply bashes that something has gone wrong even before there was a rc (point 1), second point is very simple: Instead of questioning the development model and the work of the developer, use your shiny perfect software not for bashing, instead if u like benchmarking this lot, do it to aid the developers.

[jetpeach]

i agree with the sentiments that the language and title in the article should be toned down, because it certainly isn't a "huge disaster" and just sounds like sensationalism.

and it should be toned down because the real point of the article gets lost with the overdramatic language. the point is that it would be better to not have large regressions be able to enter the kernel _at all_. it'd be better to weed these out before they get committed, because even if they get fixed before the stable kernel release a) they will almost certainly take longer to fix and b) the fixes are more likely to be less effective than if designed properly in the first place. this seems like a valid point based on the evidence in the article.

[FireBurn]

That though wouldn't go towards addressing the fundamental problem that this article is about: how such a glaringly severe regression can be pulled into the tree in the first place and then live there for days. Improving the status quo is what this article is intended to be about more than this bug per se.

I think what you mean is if the kernel developers paid you to run this service they'd get this information directly rather than you writing an article on it.

[Michael]

I think what you mean is if the kernel developers paid you to run this service they'd get this information directly rather than you writing an article on it.

Errm no, I am not looking for the kernel developers to pay me. As I've said before I am happy to run such trackers for free software projects such as the kernel as long as they are being used well.

[pdusen]

That though wouldn't go towards addressing the fundamental problem that this article is about: how such a glaringly severe regression can be pulled into the tree in the first place and then live there for days. Improving the status quo is what this article is intended to be about more than this bug per se.

Uh. Because it still works? Linus's development model involves massively pulling commits he likes and then spending several RC releases hammering away at bugs and regressions.

Hell, you yourself have reported on this. How is this suddenly a problem for you?

[rekiah]

People like you deserve to have a toilet kernel, and then I'de love to see you saying: "hey michael, you do 24/h benchmarks and didn't say anything to us!!!"

That's what all of you complaining of Michael's work deserve.

+1

"We're getting bloated, yes it's a problem," Torvalds said, "I'd love to say we have a plan. I mean, sometimes it's a bit sad and we're definitely not the streamlined hyper-efficient kernel that I had envisioned 15 years ago. The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse."

[rekiah]

All the info needed to create a bug report is here so almost any reader could do it. So why haven't YOU done it yet? (or me for that matter).

Exactly.

Thanks for the benchmarks, Michael.