Announcement

Collapse
No announcement yet.

The Huge Disaster Within The Linux 2.6.35 Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Kazade View Post
    Exactly. I'm getting sick of these articles boasting "we've found a problem, but we've kept it a secret".

    Michael, have you contacted Linus? Have you reported it as a bug? Phoronix would get a lot more credit if the articles were more like: "We found a regression and it's already fixed in Linus' tree thanks to Phoronix".
    Thing is, bugs like this shouldn't be allowed to enter into the main repository. Again, proper practices and test procedures...

    Comment


    • #17
      Dude, there's not even a -rc1, we are still in the merge week!! What the hell phoronix thinks its measuring?

      Comment


      • #18
        I've got to say I'm glad to see that I'm not the only one to be upset with this kind of drama articles.

        Honestly, showing a graph and just saying "it's better" or "it's worst" isn't journalism. For these kind of articles I expect to have some explanations. For example, I often hear about the mesa stack, but wtf is this stack? It seems to be almost as hard to understand as the sound stack in Linux!

        I also often read articles title like "DRI2 has improved", "Xinput2 is released", "yet another DRM problem", "new version of this", "new version of that"... But all of us aren't Linux gurus, it'd be great to simply _explain_ what all these technos are (isn't it the main purpose of journalism?)

        And finally, here is some kind of articles I'd like to see in Phoronix: https://www.linuxfr.org/2010/05/17/26852.html
        I'm sorry, it's in french, maybe you can google-translate it?
        patrick_g does this kind of articles at each kernel release. And even if I don't understand everything in Linux kernel, patrick_g explains RC by RC what are the improvements and what are the issues the developers had, he even interviews few developers to know how they got involved in the kernel or to explain what they have done in the kernel. It's important to say that despite the very good quality of patrick_g's articles, he doesn't know anything about coding.

        Comment


        • #19
          Originally posted by fhuberts View Post
          OMG what drama

          this is a .35-rc1 kernel for crying out loud!

          beside that, the quality of articles here on phoronix has been nose diving for a while now. I'm even beginning to get annoyed.

          Michael, you have to do better and you can because it was good in the beginning. Articles like this are total crap and do you and your site no service at all
          Actually what's really annoying is rc1 hasn't even been released yet, so it's only hard core git users that have tested the interim code that's went in since 2.6.34's release. I'm sure the regression would have been found after rc1's release if it's really as bad as Michael is making out

          But then again that won't sell advertising will it?

          Comment


          • #20
            Too much.

            Too much drama! Too few relevance !

            I'm removing phoronix's feed today from my RSS reader.

            Comment


            • #21
              Maybe Phoronix should work together with the kernel folks to test kernels and avoid such problems.

              Comment


              • #22
                This site is turning into a load of crap.

                Comment


                • #23
                  Instead Michael is doing a great job. It's not his duty to say what's causing the regression. That's something the kernel developers must know. What he did is let people know that between may 20 and 26 the kernel git regressed in an impressive way.

                  You guys pretend too much. Michael did his job, and for sure if this regression doesn't get fixed i'm not moving towards future kernels if things don't change, and you know what? I must say thanks to Michael.

                  His work isn't crap for me.

                  Comment


                  • #24
                    Michael's work isn't crap. But it could be improved.
                    For instance, you don't name that a "huge disaster". There's nothing like a "disaster" in a regression before the release, so what to say when it is even before the first release candidate?

                    Regression happens!

                    Comment


                    • #25
                      the key is in the text:
                      As we have already shown before, using the Phoronix Test Suite and its components we can also narrow down to the individual commit(s) that introduced these serious performance issues by layering the Phoronix Test Suite's automated support atop the git-bisect command to automatically traverse the tree and perform tests at each step of the process. We may do so again in this instance -- time or incentive permitting -- to track down this newest problem.
                      ...
                      We are also more than happy to work with the Linux kernel community or any other software project in establishing more robust test procedures and greater test coverage. We will work with other vendors too, via our commercial entity


                      Don't forget that Phoronix Test Suite - is a business.

                      Comment


                      • #26
                        Originally posted by bulletxt View Post
                        Instead Michael is doing a great job. It's not his duty to say what's causing the regression. That's something the kernel developers must know. What he did is let people know that between may 20 and 26 the kernel git regressed in an impressive way.

                        You guys pretend too much. Michael did his job, and for sure if this regression doesn't get fixed i'm not moving towards future kernels if things don't change, and you know what? I must say thanks to Michael.

                        His work isn't crap for me.
                        Right but the language of calling it a disaster implies that this is unexpected for the early merging process when that isn't actually the case. It's not like someone wasn't doing their job properly which caused a regression. I've little doubt this will be sorted out well before 2.6.35 goes gold unless the regressions were caused by some necessary change (as was the case for EXT4).

                        Comment


                        • #27
                          I highly respect Michael's efforts to detect kernel performance issue as early as possible. Keep it up, great work!

                          Comment


                          • #28
                            @bulletxt write "The Huge Disaster Within The Linux 2.6.35 Kernel" when the kernel is in a very alpha stage isn't fair. Maybe in rc8 or final 2.6.35 would be fine but not now.

                            I don't like the quality of this article too, too dramatic, as if not solution exists, I would find it more useful if only points that a regression was found, showing benchmark charts and pointing the bad commit.

                            @Creak I agree, a lot of articles seem to be based only on looking at git development tree of some projects (mesa, kernel...), then write a little description of latest changes, based on commits titles. There is not a deep understanding or explanation of how the things works. I think it is not Michael fault and perhaps phoronix lacks of man power to write more decent quality articles.

                            Comment


                            • #29
                              Originally posted by bulletxt View Post
                              Instead Michael is doing a great job. It's not his duty to say what's causing the regression. That's something the kernel developers must know. What he did is let people know that between may 20 and 26 the kernel git regressed in an impressive way.
                              Funny. I always thought that the proper way was to first let the people involved know about it (i.e. filing a bug report) I didn't see anything about that in the lengthy article. Bugs and regressions are part of every large software project. No need to make such drama about it, unless there's unwillingness to fix.

                              Comment


                              • #30
                                Ok it seems you guys got upset of his way of writing a drama article Yes he did that and it was exagerated. But i'm a Linux user, so what I care isn't about michael's drama | not drama. I care about Linux. If Michael shows that in 6 days the Linux kernel became a toilet performance, then I must think: "hey what the hell happened? that's not a small regression, that's a total mess!".

                                You guys seem more afraid of Michael words rather than a real possible Linux kernel regression. I know it's not even an RC, but how many of you would put 100$ on a table saying that the regression will be fixed(if it actually can) by the final realease??
                                I won't.

                                Comment

                                Working...
                                X