Announcement

Collapse
No announcement yet.

GNU Linux-libre 6.2 Continues The De-Blobbing Battle

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

  • GNU Linux-libre 6.2 Continues The De-Blobbing Battle

    Phoronix: GNU Linux-libre 6.2 Continues The De-Blobbing Battle

    Building off yesterday's release of Linux 6.2, the GNU Linux-libre 6.2 kernel was published today by the GNU FSFLA folks maintaining this kernel downstream that strips out driver support dependent upon non-free software firmware/assets as well as dropping the ability to load closed-source kernel modules...

    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
    introduced a brand new old-fashioned sourceless binary blob disguised as a sequence of numbers, i.e. binary object code encoded as pseudo-sources
    That's rather unfortunate. Too bad Linus and the kernel maintainers are allowing such things to pass through. I'm still using the 4.19 and 5.10 LTS versions, so this will have 0 impact on me. But still, it's the principle of the thing.

    By the way, happy 15th birthday to Linux-libre! Here's the announcement for the original 2.6.24 kernel from 2008: https://web.archive.org/web/20221001...7ba592.en.html
    Unfortunately, Linus was allowing Broadcom and others to toss their non-free nonsense into the kernel back then, and Linux-libre originator Jeff Moe had the receipts:
    The official "vanilla" Linux kernel from Linus that gets distributed on
    kernel.org has non-free[1] software in it. Here is one example from
    linux-2.6.24/drivers/net/tg3.c:


    /*
    * tg3.c: Broadcom Tigon3 ethernet driver.
    *
    * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@???)
    * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik@???)
    * Copyright (C) 2004 Sun Microsystems Inc.
    * Copyright (C) 2005-2007 Broadcom Corporation.
    *
    * Firmware is:
    * Derived from proprietary unpublished source code,
    * Copyright (C) 2000-2003 Broadcom Corporation.
    *
    * Permission is hereby granted for the distribution of this firmware
    * data in hexadecimal or equivalent format, provided this copyright
    * notice is accompanying it.
    */


    It then has screenfulls of non-free code like this:

    0x0e000003, 0x00000000, 0x08001b24, 0x00000000, 0x10000003, 0x00000000,
    0x0000000d, 0x0000000d, 0x3c1d0800, 0x37bd4000, 0x03a0f021, 0x3c100800,
    0x26100000, 0x0e000010, 0x00000000, 0x0000000d, 0x27bdffe0, 0x3c04fefe,
    0xafbf0018, 0x0e0005d8, 0x34840002, 0x0e000668, 0x00000000, 0x3c030800,​ [etc etc etc]

    Comment


    • #3
      One of the most pointless projects ever. Nobody tell them about all the firmware that's bakedinto the hardware itself. Oh wait, for some reason "ROMs" are 100% stallman approved.

      Comment


      • #4
        Originally posted by Developer12 View Post
        One of the most pointless projects ever.
        What is pointless about knowing what the kernel is doing? That's a nonsensical statement. You may not always want to run a libre kernel, but you can't argue that there's never any point to it.

        Nobody tell them
        Tell who?

        about all the firmware that's bakedinto the hardware itself.
        Shocking. You are way out in front of everyone else, give yourself a pat on the back.

        Oh wait, for some reason "ROMs" are 100% stallman approved.
        Why do you conflate "unavoidable" with "desirable"? No one desires to have non-free firmware. Stallman and many others have noted that this is a concession to reality, otherwise you would not have nearly any running equipment.

        Comment


        • #5
          Originally posted by Developer12 View Post
          One of the most pointless projects ever. Nobody tell them about all the firmware that's bakedinto the hardware itself. Oh wait, for some reason "ROMs" are 100% stallman approved.
          What is pointless is your comment.

          Comment


          • #6
            Originally posted by Developer12 View Post
            One of the most pointless projects ever. Nobody tell them about all the firmware that's bakedinto the hardware itself. Oh wait, for some reason "ROMs" are 100% stallman approved.
            There's a really big difference between firmware that's baked into hardware that the user can never change, essentially making it fixed hardware, versus firmware that's loaded at runtime and/or can be updated by the manufacturer to do fuck knows what.

            Comment


            • #7
              Originally posted by skeevy420 View Post
              There's a really big difference between firmware that's baked into hardware that the user can never change, essentially making it fixed hardware, versus firmware that's loaded at runtime and/or can be updated by the manufacturer to do fuck knows what.
              Its more complex than that. There is not the black and white divide.

              1) Firmware embedded in device on rom
              2) firmware embedded in device with update eeprom..
              3) Firmware embedded in device replaceable at runtime.(this include cpu microcode)
              4) Firmware on device being only a loader and device does not work without being sent firmware.

              Type 4 for particular devices like radio devices can be very good so that if device is no longer legal to use you can delete the firmware file or driver and the device is dead.

              Type 1 2 and 3 you can have the problem that the device is firing up on boot up. Now if this is part of your computer motherboard it could be now stop using your complete computer to be legal.

              What about writable eeprom on devices. So even if the firmware is on the device and the OS does not need to load the firmware it still possible that manufacturer could have way of updating the devices firmware this is what https://fwupd.org/ Linux vendor firmware service is about.

              Firmware in rom as fairly much died out because Manufacturers are normally bad at coding firmware and you will need to update it at some point to fix their defective code. Option 2 eeprom solution has come less popular due to end users updating their firmware and bricking their hardware. Option 3 and 4 are ram options that don't wear out quickly or at least not inside the useful life of the product.


              The big thing I have issue with. Is the Linux kernel has official firmware handling functionality. If you find blob of executable code in Linux kernel source code there is a big problem this is not using the Linux kernel API/ABI for firmware. Linux kernel drivers built right stopping the Linux kernel from loading binary blobs into hardware should be simply depopulate the firmware locations defined in the firmware API section of the Linux kernel. I am not saying those doing Linux-libre are not finding these issues but they should be opening upstream bugs if there is firmware blob in the Linux kernel source code.

              Back in the early days of Linux the formal firmware API did not exist so parties put blobs inside the main Linux kernel source that was technically breach of the GPLv2.0 license and is still technically a breach todo.

              Comment


              • #8
                Originally posted by skeevy420 View Post

                There's a really big difference between firmware that's baked into hardware that the user can never change, essentially making it fixed hardware, versus firmware that's loaded at runtime and/or can be updated by the manufacturer to do fuck knows what.
                Because one you can't audit, and the other you can't audit either? The difference was only about accepting the reality.

                Comment


                • #9
                  God damn blobs ruining our kernel. The only thing I hate more than a blob is a bug. We should get rid of them all.

                  Comment


                  • #10
                    Originally posted by EphemeralEft View Post
                    God damn blobs ruining our kernel. The only thing I hate more than a blob is a bug. We should get rid of them all.
                    how do you feel about systemd_blob ?

                    Comment

                    Working...
                    X