Originally posted by gordboy
View Post
Announcement
Collapse
No announcement yet.
The Huge Disaster Within The Linux 2.6.35 Kernel
Collapse
X
-
Originally posted by gordboy View PostMichael seems to be RedHat's dog, Rover.
The RedHat developers, and in particular, Dave Airlie have come under intense scrutiny and criticism by core kernel developers, for their inept and ultimately damaging stupidity.
Michael, who is partly funded by RedHat, appears to have been asked to redress the balance, as it were. And the net result is a damaging hit-piece that comes straight off the front page of the News Of The World or National Enquirer.
But this is not the first time Michael has not been impartial, by any means. And it certainly won't be the last.
Hey Michael - Fetch that stick ! Good doggy !
Comment
-
The information is useful, the presentation, not so much.
If a shipping stable kernel had this issue it might BEGIN to justify the article title or the jabs at their development process (which it seems, made Linux, PTS, and Phoronix possible in the first place...as I don't see daily testing of manually compiled Microsoft kernel source anywhere.)
I'm not a kernel developer, but I've been playing with development kernels for years... If an RC1 kernel even COMPILES, I'm generally impressed. (Let alone a merge window kernel... I'm reckless and I don't even touch those. In fact I rarely mess with an RC1, because though my main machine is rarely mission critical, I don't feel like wasting a day restoring.)
Now I look back on those failed compiles and kick myself for not seizing the opportunity, could you imagine the headlines? "Armageddnux! Next Linux Broken!" After all, I'd imagine a kernel that doesn't even build would be a bigger problem than one that builds, but runs slowly.
it's inexplicable that a regression like this or change in behavior can even be accepted into the mainline Git tree at any point in the development cycle for such a mature project. That it can not only enter the kernel tree, but it can live for a week or more without either being corrected or the problematic commit being reverted. This is such a glaring performance issue across so many different tests and differently configured systems that it calls to question the current development practices and test procedures of the Linux kernel.
A merge-window/RC1 kernel, is absolutely the WORST time to do ANY sort of analysis... I'd think someone familiar with the development process would know this.
It's kinda like watching the first 5 seconds of a surgery and going "Dude look! He's supposed to be healing her but he's cutting her with a scalpel! Sick SOB... The Masked Slasher Strikes Again! Someone is probably doing this in a neighborhood near you! and sometimes even to children!"
or walking in to someone's shower and saying "See! I told you they were naked! What a sicko!"
Or getting your hands on a 2012 car prototype, seeing the electronics don't function, and stating "OMG...the next models electronics don't even work..."
Feel free to make up your own fun analogy, these were just the ones that went through my head as I mowed the lawn. Consider it an intellectual exercise.
If we see this in a stable kernel, I still wouldn't even call it a disaster... an unfortunate regression for sure, a lapse in the system? certainly... A disaster?... we all know a 2.6.35.1 will follow a 2.6.35. Hardly the end of the world.
-Andy
Comment
-
I have to confess, when I initially read the article title, I'd been away from linux for awhile. (So I'm hooked on GTA4, sue me) I thought they were referring to the recently released kernel (turned out to be 2.6.34)
When I saw they were talking about a merge window kernel, I felt like I wanted the 5 minutes of my life I spent reading the article back...
-Andy
Comment
Comment