Announcement

Collapse
No announcement yet.

"A Clear Example Of Why DRM Has Been Problematic"

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

  • "A Clear Example Of Why DRM Has Been Problematic"

    Phoronix: "A Clear Example Of Why DRM Has Been Problematic"

    Linus Torvalds is known to have an interesting, colorful e-mail from time to time when becoming frustrated with developers over the quality of patches or when in a very polarized technical debate. In particular, the DRM developers for the Direct Rendering Manager in the kernel (not the restrictive kind, Digital Rights Management) have received a number of critical remarks from Linus. This morning Linus has criticized a second DRM pull request for the Linux 2.6.39 kernel over one of the patches not being ready in advance...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Sounds more like a clear case as to why trying to keep strictly separate kernel and userspace is a real problem...

    Comment


    • #3
      So, Linus, whats better solution:
      - "module $BLOB taints kernel", or
      - unstable opensource driver stack

      Of course, if s/Linux/Windows/ then s/kernel folks/responsible company/; but they keep pushing that then it would inevitably be s/opensource/proprietary/

      Why? I dunno. Greed, Fear, Dinosaurs?

      Comment


      • #4
        Will this become more "UNTESTED CRAP"?

        Comment


        • #5
          Hehe, the other day when I posted that developers of the open source video drivers (and the rest of the video stack) need to get their act together, I got only negative replies. Thanks, Linus.

          Comment


          • #6
            Originally posted by bug77 View Post
            Hehe, the other day when I posted that developers of the open source video drivers (and the rest of the video stack) need to get their act together, I got only negative replies. Thanks, Linus.
            This is nothing to do with anything you said. In fact, the goals of pushing out new features and improved performance like you want and maintaining a stable and well-tested kernel interface and driver like Linus wants are in direct contention.

            Comment


            • #7
              Originally posted by crazycheese View Post
              So, Linus, whats better solution:
              - "module $BLOB taints kernel", or
              - unstable opensource driver stack
              It's more like Linus wants the same thing he always asks for, which is that only code that's ready goes into the kernel during the merge window. Devs still have trouble with the merge window concept and throw half-baked code over the wall at the last minute so it gets into the newest kernel. Linus ultimately accepts a lot of crap hoping that it will be fixed in early rc's, but not without calling the DRM devs on their bullsh!t. Drama ensues..

              Comment


              • #8
                Originally posted by Ian_M View Post
                This is nothing to do with anything you said. In fact, the goals of pushing out new features and improved performance like you want and maintaining a stable and well-tested kernel interface and driver like Linus wants are in direct contention.
                The features and performance in and of themselves aren't in contention with a policy change on the amount of testing that goes into merges before it hits Linus, but the rate at which the features can be introduced to mainline is in contention with the degree of testing.

                Linus is basically saying that he doesn't want stuff to go into mainline while APIs and solutions to problems are still being debated by the project maintainers. Since the kernel community is very much a meritocracy, some random newbie making an off-hand comment about disliking a given approach isn't enough to set off Linus; but Michel Danzer is a long time contributor and significant stakeholder in DRM due to the fact that he is employed to work on it (and Gallium / Mesa).

                The whole situation was mostly a misunderstanding, because making sweeping policy changes to ensure that no one has any problem with any patch going into a merge would add so much bureaucracy as to make contributing to DRM take way too much effort on behalf of the person who wants the patch to go in. We have to assume silence is agreement because getting a yes/no from all stakeholders (and determining who exactly are the stakeholders in the first place) is impossible. Especially when you consider the sheer volume of code that is changed in each release cycle.

                Comment


                • #9
                  is this guy the drama queen of FOSS or what. I am getting the feeling that he likes being center of attention with his stupid rants. it was opensuse now this. how about fixing up your shitty monolithic bloat that segfaults from wake/hibernation. that's what I love about freebsd, the devs lead quit lives (too bad that freebsd sucks on the desktop)

                  Comment

                  Working...
                  X