Announcement

Collapse
No announcement yet.

GNU Linux-libre 4.3 Warns Of Intel Skylake Sound, New AMDGPU Blobs

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

  • GNU Linux-libre 4.3 Warns Of Intel Skylake Sound, New AMDGPU Blobs

    Phoronix: GNU Linux-libre 4.3 Warns Of Intel Skylake Sound, New AMDGPU Blobs

    Building off yesterday's release of Linux 4.3 is now the GNU Linux-libre 4.3 kernel. As usual, the GNU Linux-libre kernel strips-out/disables code from the mainline Linux kernel that depends upon binary-only firmware/microcode files and other non-free components...

    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
    Is this nonsense really required? Does a "free" kernel really offer us anything other than some grief when it comes to using certain parts of a chips hardware.

    Comment


    • #3
      You can't know it in advance, THAT IS the point.

      Comment


      • #4
        Originally posted by wizard69 View Post
        Is this nonsense really required? Does a "free" kernel really offer us anything other than some grief when it comes to using certain parts of a chips hardware.
        No, it doesn't, and one might argue that these libre-kernels are actually counterproductive, due to the weird definition the FSF has for software "not being free". They claim it is all about the users rights, but is this really the case? Think about it for a while: Any software, regardless of open source or proprietary has bugs. It is in the best interest of the user that those bugs can and will be fixed, regardless if the software is proprietary or open source. Now, with the FSF definition of "if it is unchangeable in hardware it isn't software anymore and therefore it can't be non-free" they actively endorse hardware that has the firmware in ROM, making bugfixes practically impossible even if the manufacturer wants to provide fixes.

        So is providing a libre-kernel that favors unfixable firmware over fixable firmware that has to be loaded at boot really in the best interest of the users?

        Comment


        • #5
          Originally posted by MoonMoon View Post
          Any software, regardless of open source or proprietary has bugs. It is in the best interest of the user that those bugs can and will be fixed, regardless if the software is proprietary or open source.
          And theres your jump of judgment. For the FSF and the free software movement, no, "regardless" is not true. If it is proprietary it overrides all other considerations because it takes away control of the software from the user and nothing else matters to a foundation dedicated to the ethical freedom of software.

          The fact Linux-Libre is unusable pretty much anywhere is only a testament to how bad the situation we are in is. It should be a giant red flag that we are not making any progress towards liberating our hardware - instead, we step backwards, because there have been instances in the past where many of the cited blobs this release were not an issue (radeonhd from Suse used to be a completely free driver for AMD cards, Atheros NICs used to be completely free in the Wireless N days, I believe Intel's sound code has been completely free in the past).

          This kernel is not made to be a daily driver, because it cannot run on pretty much any hardware. I would love to see any hardware built of parts that could make a computer running libreboot + linux-libre with working accelerated graphics, C states, and wireless but I doubt one can even be made today. But the fact it cannot run is one of the most dangerous problems facing the future of software liberation.

          Comment


          • #6
            Simple question -> simple answer: Yes, it is really required.

            Comment


            • #7
              Does this mean you can't have sound on Intel Skylake systems using Linux-libre, unless you have a dedicated/external sound card?

              Comment


              • #8
                Originally posted by MoonMoon View Post
                even if the manufacturer wants to provide fixes.
                Thats the issue right there, why should the manufacturer have exclusive control over providing fixes.
                Its not libre if others have more control of your hardware than you do.

                Comment


                • #9
                  I agree a 100% that binary blobs are bad, for plenty of reasons. However, I'm a bit puzzled when I read that the situation supposedly got "worse". Think about it, 10 years ago: your hardware came with a ROM, which contained the non-free, evil binary. If you were unlucky, the code couldn't be change at all, and since it was buggy, Linux came with a special quirk to make it work. If you were somewhat lucky, the vendor provided a way to reflash it, or upload a binary on each boot to patch the buggy ROM. And then vendors realized that masked ROM cost a fortune and are a waste of space because you can just put all those blobs on the flash and let the OS loads those: save costs, save components, save PCB space even. If the vendor never provides any update, that a ROM like situation and if it does, at least you have something better without paying for new hardware.
                  I don't see how providing a binary-free kernel helps, it's really like stripping all the ROM of your hardware. However, I do see how reverse engineering those binary could help, although that's a massive job (see nouveau and other graphic card drivers).

                  Comment


                  • #10
                    Originally posted by pamaury View Post
                    I agree a 100% that binary blobs are bad, for plenty of reasons. However, I'm a bit puzzled when I read that the situation supposedly got "worse". Think about it, 10 years ago: your hardware came with a ROM, which contained the non-free, evil binary.
                    That's what MoonMoon was suggesting. In theory, projects like this are trying to encourage fully-open firmware that users can change, as opposed to what we have now - firmware that the user can update from binaries, but not modify. But in practice, what they're unintentionally promoting is closed firmware that cannot be modified at all - they're rejecting the middle ground, and forcing manufacturers to choose between the extremes of fully locked-down and fully open. No surprises that most manufacturers either ignore them, or choose the former.

                    Comment

                    Working...
                    X