Announcement

Collapse
No announcement yet.

The Huge Disaster Within The Linux 2.6.35 Kernel

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

  • #76
    Man, I love all the "stfu and quit complaining!!! go awaaaii!!!" trolls crawling out of the woodwork today.

    Face it: Michael wrote a sensationalist article that served no real purpose except to alarm people and increase ad revenue. He's on the same level as any other independent news outlet.

    It's not the end of the world. You don't have to be in denial about it. It is what it is.

    Comment


    • #77
      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.
      Amen

      Oh for crying out loud, y'all are making mountains out of molehills here guys. At least Michael is just keeping us in the loop as things progress with the new kernel. As for the regressions, then open bug reports if they are not corrected soon enough. Also when people test the RC's, report any anomalies so they can be fixed by the next RC.

      Comment


      • #78
        Originally posted by allquixotic View Post
        It's like if you were a carpenter and you were about to hammer a nail into a piece of wood, and you lifted your arm halfway up in the air to get ready to bring the hammer down, and I said, "AH! AH! AH! the angle on your arm is off by 15 degrees, you're going to drive the nail in crooked!" -- wouldn't that annoy you? You might say, "But I haven't even hit the nail yet!" -- that's what the Linux testers and developers would say to your over-dramatized article, Michael.
        Very impressive post! And sorry, but that's a beautifully crafted analogy . You hit the nail on the head there!

        Comment


        • #79
          Some points to consider.

          1) The kernel team generally does not have the tools to monitor regressions on a regular cadence. The kernel has been in development for the last 18 years.

          2) The severity (ie: broad impact) of a regression is usually not really understood. The kernel tracker shows a broad impact.

          3) There has been discussion, there has been fingerpointing, analysis, etc. But no concrete steps have been taken in just under a week and the referenced thread seems to have died.

          4) The regression is still there - with no visible actions to revert.

          5) Independent of the root cause of the issue (udev or kernel), the fact is that there is a kernel change that changed the behaviour of the ecosystem. Maintaining a "the kernel is correct, userland can fix it" stance is dangerous. Like it or not, the kernel is part of a bigger system. The components that intimately interact with the kernel should be treated the same as subcomponents within the system. Internally the kernel team requires developers to not break other subcomponents. Outward components are just as important.

          6) Testing is hard, regression management is hard, it places constraints. A lot of the kernel developers simply don't care for some of these constraints. I can guarantee that if this was raised on the kernel mailing list, there would be a lot of people not focusing on the issue, but mouthing of on the testing, the methodology, etc. ie: Attacking everything but the issue.

          Comment


          • #80
            Originally posted by allquixotic View Post
            1. The checkpatch.pl script, which performs automated analysis on the patch to spot glaring errors in submission.
            2. The engineer must submit their patch to their lieutenant, who reviews the patch and has to sign off on it.
            3. The kernel has very robust tracing and debugging facilities, as well as run-time checks, that can optionally be enabled. These facilities will complain loudly if they detect a problem. They impose a performance penalty, so they are turned off in release kernels; but usually, kernel hackers enable these when testing their patches.
            4. Many kernel engineers are employed at an organization that has a license to Coverity Prevent, or some other static analyzer. These engineers might run their patches through Coverity before committing, to see if they've made any logic errors that can be automatically detected by pattern matching.
            One part that you are missing here is that the developer should understand their changes in the context of the system that they are making it. That is why there is the organizational structure over the kernel. You have subsystem owners both up to the branch maintainers (Linux et al), all the way down to subcomponent maintainers.

            The kernel is big huge and scary. You make changes in there, you need to think long and hard about who and what you are going to affect. The _really good_ kernel developers think the system not the code they are changing.

            Sure it's unwritten, but it's real, and it's hard. It separates the ok, good and great kernel developers.

            Comment


            • #81
              Jesus guys... WTF!

              A single kernel commit causing a 50% performance drop IS a disaster!

              Do you call your CNN everytime they interview Obama and tell them to aid with the booming or STFU when oil spills hit the shore?

              This is news and be glad Michael MADE the fscking tools to discover it!

              I am very happy on being kept up to date with development news. If you want to catch the individual stable releases with explenations for the crack stupid I suggest you go to Digg.com for your latest Ubuntu release info.

              If there is either no news or a mini studie/article to help Linux lernel devs than I gladly welcome that.

              I hope that the Steam Linux client is soon released, because that would cut away the complaining about Phoronix on the forums so I can read the interesting comments of people who do know their shit so I can learn something new.

              Jesus...

              Comment


              • #82
                Originally posted by zoomblab View Post
                Thing is, bugs like this shouldn't be allowed to enter into the main repository. Again, proper practices and test procedures...
                I agree. Usually the code that gets merged at this stage has lived for some time before in linux-next. This kind of huge regression basically tells us that nobody tests what lands into linux-next. The fact that it stayed there for a week is even stranger. Nobody tested the code for a whole week? I mean, the problem is so spread that it's difficult to think that the tests that have been run didn't report anything strange.

                Comment


                • #83
                  I am not criticizing Michael for posting this article, as its indeed informative and I do hope he submits his info to LKML so that the devs will be aware and this bug(s) get fixed

                  Why not pull a snapshot and TEST it, guys? Will only help the devs if we test and report anything bad or broken

                  Comment


                  • #84
                    Originally posted by fhuberts View Post
                    well if you'd done just a little bit more research you'd found the lkml thread mentioned in this forum thread before and you'd seen that it might not even be a kernel bug but an udev bug...

                    the more spectacular news an article brings, the more effect you'll have to put in to make sure that you've got your facts straight.

                    you're kind of falling flat-out on your face right now. and you're pissing of lots of kernel people. not very wise
                    Guys, when you inject a change on a system and you cause a regression it simply doesn't matter who needs to make an ultimate fix. Before you inject the change, you make sure the system will work properly. If the change went in with "This causes a performance regression unless you are using udev xx.yy" then the due diligence has been done. Anything less is to some extent irresponsible.

                    Comment


                    • #85
                      Originally posted by V!NCENT View Post
                      WTF!
                      There's no spoon and there's no 2.6.35, so Phoronix, few 'smart' people talking about development, WTF?

                      Comment


                      • #86
                        Originally posted by mtippett View Post
                        Some points to consider.

                        1) The kernel team generally does not have the tools to monitor regressions on a regular cadence. The kernel has been in development for the last 18 years.
                        That is so sad and scary at the same time. With all the major corporations and individual that are involved with the kernel development you would think that at least one of them would have donated use of a few boxes for automatic regression testing. It's not rocket science to setup such a regression testing facility. I bet pretty much every devel out there has an older box that they no longer use that could be used for such testing, not to mention the corporations that have tones of nil load hardware out there just burning power sitting idle.

                        Does nobody else see a major flaw in this lack of capability? With the kernel getting larger and larger and more complex you would think that someone, somewhere that is involved would have said "Hey let's set something up to be proactive watching for regressions!" instead of relying solely on user feedback and the efforts of one enthusiast site.

                        Comment


                        • #87
                          Originally posted by kraftman View Post
                          There's no spoon and there's no 2.6.35, so Phoronix, few 'smart' people talking about development, WTF?
                          r600g wasn't merged to mesa. So scrapt these articles then?
                          Bridgman and others do not add very interesting info on not released drivers?

                          What else does not matter at all? All I see is nin pages full of "why did you report a development bug?"

                          Can I have my WTF back now? I might need it in the future where you might comment on Mesa, KDE and Gnome development.

                          Comment


                          • #88
                            Originally posted by deanjo View Post
                            That is so sad and scary at the same time. With all the major corporations and individual that are involved with the kernel development you would think that at least one of them would have donated use of a few boxes for automatic regression testing. It's not rocket science to setup such a regression testing facility. I bet pretty much every devel out there has an older box that they no longer use that could be used for such testing, not to mention the corporations that have tones of nil load hardware out there just burning power sitting idle.
                            Yes, it's really scary. Unfortunately, the concept of proactive regression management is lightly understood through the industry.

                            Does nobody else see a major flaw in this lack of capability? With the kernel getting larger and larger and more complex you would think that someone, somewhere that is involved would have said "Hey let's set something up to be proactive watching for regressions!" instead of relying solely on user feedback and the efforts of one enthusiast site.
                            Well that's why Michael and I created Phoromatic and PTS.

                            If there are kernel developers interested and motivated enough to work with us to tune the testing and the systems, we can push the kernel tracker way further than it is at the moment.

                            Comment


                            • #89
                              Originally posted by mtippett View Post
                              Yes, it's really scary. Unfortunately, the concept of proactive regression management is lightly understood through the industry.
                              The fact that it is lightly understood is very disturbing. Pretty much every development project that I have worked with however has had a regression tracking setup so I'm not sure if it's so much "the industry" or more just the case in a open development model.


                              Well that's why Michael and I created Phoromatic and PTS.
                              And some of us appreciate that. It seems however, at least judging from a lot of the comments in this thread, if something bad is mentioned against the "church" all of a sudden you become public enemy #1 in their eyes.

                              If there are kernel developers interested and motivated enough to work with us to tune the testing and the systems, we can push the kernel tracker way further than it is at the moment.
                              Have you guys approached the larger projects out there in setting up any facility like this? It seems to me if intel/amd can donate hardware for build services, ftp mirrors, etc for distro's they surely can offer some boxes to setup such a facility for the kernel devs to use.

                              Comment


                              • #90
                                Originally posted by deanjo View Post
                                The fact that it is lightly understood is very disturbing. Pretty much every development project that I have worked with however has had a regression tracking setup so I'm not sure if it's so much "the industry" or more just the case in a open development model.
                                I have lots of personal thoughts on this, I won't go into it here.

                                It depends on what people term as regression tracking. I have seen a lot of incantations from we test now and then to we have a tool. Regression management in my mind has the following aspects.

                                o A way of detecting the regression
                                o A way determining the regression cause (down to the code change)





                                And some of us appreciate that. It seems however, at least judging from a lot of the comments in this thread, if something bad is mentioned against the "church" all of a sudden you become public enemy #1 in their eyes.



                                Have you guys approached the larger projects out there in setting up any facility like this? It seems to me if intel/amd can donate hardware for build services, ftp mirrors, etc for distro's they surely can offer some boxes to setup such a facility for the kernel devs to use.[/QUOTE]

                                Comment

                                Working...
                                X