Announcement

Collapse
No announcement yet.

GNU Linux-libre 4.15-gnu Deblobs Two New Drivers, Drops More Upstream References

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

  • #11
    Is there actually a system on the planet where the entire sourcecode is available? For everything from the drive controllers/storage to the ram/cpu firmware/bios code?

    Comment


    • #12
      Originally posted by phoron View Post
      So yes, in a first order approach there is a contradiction. If you don't trust a vendor you shouldn't use their hardware (or firmware). If you trust them you can as well trust their updates to propietary firmware.

      But you can look at some finer grain: if you don't trust the vendor but can't find a vendor you trust (all free firmware), then your options are no hardware at all or trying to trust the vendor as little as you can (only once, when you buy the hardware). Hence the blobs in ROM as a lesser evil.
      I see a few issues with the above statements:

      1. If you are willing to trust the vendor once re: blobs in ROM then trusting the vendor once with originally released image in a file is no different, as long as you either check integrity of the file in driver/distro code or via HW signing.

      2. Stripping out blobs completely means that you trust HW vendors with ROM or flash-based microcode one time but trust HW vendors with RAM-based microcode zero times.

      3. If you automatically accept new blobs without even giving the user the option then I agree you are effectively having to trust the vendor more than once, but the alternative to "automatically accepting" is "deliberately accepting" after at least a partial risk/benefit analysis.

      Originally posted by phoron View Post
      One possibily advantage of the linux-libre approach is poiting out what BLOBs are there and what they do. That helps selecting hardware.
      Again, it only points out what file-based blobs are there. It doesn't help at all with pointing out what ROM- or flash-based blobs are there, and just sends a message to HW vendors that they should shift from file-based to ROM- or flash-based, which is a net loss for the user.
      Last edited by bridgman; 29 January 2018, 05:12 PM.
      Test signature

      Comment


      • #13
        Originally posted by bridgman View Post

        I see a few issues with the above statements:
        Thanks

        1. If you are willing to trust the vendor once re: blobs in ROM then trusting the vendor once with originally released image in a file is no different, as long as you either check integrity of the file in driver/distro code or via HW signing.
        I'm not sure I understand you. By once I mean when you buy the hardware. You seem to mean everytime you install the OS ?
        The assumption is that the blob being a proprietary firmware you don't have much way to inspect it. If there are several
        versions you can pick one and check its hash or whatever, but you can't tell differences or check what it does. Do you mean the distro
        should be deciding which version of the firmware to trust ? Each buyer of the hardware gets a different version depending on
        when he buys assuming the firmware is in ROM (a new batch of hardware will have updated firmware in ROM, I guess).
        If the firmware is loaded by the driver or kernel or whatever, each buyer of the hardware doesn't get whatever firmware was available at the
        time he trusted the vendor to buy the hardware, but at the time someone else decided to publish a driver or distro version.
        Neither the hardware buyer nor the distro or driver publisher has enough info to trust which version is good or not.
        It is bad enough to have to choose without enough info, having to rely on other peoples choices would be worse, wouldn't it ?

        I'll take it that you mean something like the hardware buyer should have some way to know which version of the blob is installed
        and whether any other version is the same or not, and get to decide which version is uploaded, including the possibility of
        always choosing the same version. It seems weak. A specific version might not available at a date the buyer needs reinstalling.
        The buyer might be coerced to install a new version because of claimed fixes noone can independently verify.

        The point of linux-libre is to simplify running 100% free software. You can take kernel.org linux and manually deblob what you want.
        Linux-libre will never stop anyone getting their kernels elsewhere. But that is more work. what linux-libre is doing is using a understandable
        criteria to decide what to include and leave out and providing the result of that decisions to others so that they only need to agree
        to the criteria, not apply them by themselves. If you make the proprietary firmware loadable how do you avoid the requirement of having to
        choose which version to load without any realiable info about the contents ?

        2. Stripping out blobs completely means that you trust HW vendors with ROM or flash-based microcode one time but trust HW vendors with RAM-based microcode zero times.
        If that flash is rewritable then I understand it's like RAM for this argument, isn't it? I'll stick to ROM or RAM, then.

        But yes, you trust RAM based vendors zero times because RAM based vendors don't have any version of microcode to trust. You never know what you might get from the net
        to upload. They're shipping their hardware without the firmware it needs hoping you'll get it from the net. That's fine if it is free and everybody can audit it.
        If it's a blob then it gets more complex to really trust them just once. You're trusting them for the wiring when you buy the hardware and for the firmware when
        you download the firmware. That's two times. You could think of shipping the hardware with a CD, but the CD might possibly be exchanged at a shop or customs and at at some point it gets more complex than just a ROM.

        3. If you automatically accept new blobs without even giving the user the option then I agree you are effectively having to trust the vendor more than once, but the alternative to "automatically accepting" is "deliberately accepting" after at least a partial risk/benefit analysis.
        There is not enough information for that analysis if you don't trust proprietary software. It's just someone offloading their responsability to choose something to someone else.
        That is only freedom is that someone else has a chance to make an informed decision.

        In effect, it comes down to :

        Hardware is the part of the information system that can't be changed, software is the part that can be changed (and let's leave wetware alone for now).

        Once some functionality can be changed it becomes software and free software principles start to apply.
        The same code in the hardware in a way that can't change is effectively hardware and can come under
        open hardware principles or whatever, but not free software principles, even if the bytestream is identical.
        Remember the difference between free and proprietary software is not the bytes, it's the license.
        The difference between hardware and software is not matter, but the easiness of being changed (and
        that opens up an spectrum between hardest and softest wares, but that might go too far).

        Again, it only points out what file-based blobs are there. It doesn't help at all with pointing out what ROM- or flash-based blobs are there, and just sends a message to HW vendors that they should shift from file-based to ROM- or flash-based, which is a net loss for the user.
        It is a net loss depending on how you look at it, as I wrote in my earlier message.

        You might mean that, for example, linux-libre can't avoid the BIOS loading a new microcode to the CPU. For that you would need the whole stack of deblobbed software with
        similar criteria for each project, but linux-libre is only part of that.

        I think the message to vendors is that shifting functionality form hardware to software is no excuse for proprietary software. If the vendor wants the flexibility of functionality in software, then the user wants the freedom of free software. It's not "let's push to ROM". It's "it's either ROM or FREE software".

        Comment


        • #14
          Originally posted by phoron View Post
          But you can look at some finer grain: if you don't trust the vendor but can't find a vendor you trust (all free firmware), then your options are no hardware at all or trying to trust the vendor as little as you can (only once, when you buy the hardware). Hence the blobs in ROM as a lesser evil.
          As long as blobs in ROMs means "blobs not meant to be updated during the life of the device", that's something I can agree with.

          It's the refusal to update updatable blobs that still get loaded, they wanted or not, only in an older and possibly unsafe version.

          One possibily advantage of the linux-libre approach is poiting out what BLOBs are there and what they do. That helps selecting hardware.
          There is pretty much nothing even remotely modern that can do without blobs and have any kind of performance, outside of pure headless CPUs and crappy iGPUs (up to Broadwell maybe when they started to require a blob too).

          But if you don't share FSF ideas, don't expect to like their recommendations. If you share them, don't expect all others to share them (yet?). If they don't, don't expect FSF to be able to fix the world (yet?).
          I technically share FSF ideas, what I don't understand is the actual point of making a mostly crippled kernel to run on a system that still uses outdated blobs loaded from ROMs anyway.

          Resources should be placed towards actually supporting and manufacturing hardware that does not have these limitations.

          You may not want to use proprietary software for ethical reasons, because you feel ripped when you buy software and only get part of it, the binary, the proprietary terms of use make the bargain unattactive or educational reasons or whatever, you could change "trust" by "like" or something. The point is more or less the same.
          That's still crippling yourself though. I mean I guess it's very trendy nowadays with Vegans and such, but there are limits. I still need to get a job done.
          Last edited by starshipeleven; 29 January 2018, 07:00 PM.

          Comment


          • #15
            Originally posted by DMJC View Post
            Is there actually a system on the planet where the entire sourcecode is available? For everything from the drive controllers/storage to the ram/cpu firmware/bios code?
            Afaik the closest one is some kind of IBM Power system as they have open microcode and firmware.
            For peripheral controllers, I don't even know what you gan get that has no firmware or is opensourced. In microcontroller-based hardware devices "opensource" is pretty much an alien concept.

            Comment


            • #16
              Sometimes I look at Phoronix and I'm happy to see a vibrant community that slowly but surely reaches its goals.

              And some other times, all I see is a bunch of idiots who probably uses GNU/Linux because it's edgy and "look at my rotating desktop cube!" level of dumbness.

              Do you understand the difference between proprietary and free? Do you understand the pressure and hard work that was needed to just to have a decent level of freedom?
              Do you understand that in the years to come it could be fucking cyberpunk level of distopia when dealing with computers and the internet?

              ​​​​​​Man up, turn off Compiz and start supporting any and all fLoss projects. Or switch to macchintosh, you'll find your "creative" environment.

              Comment


              • #17
                Originally posted by starshipeleven View Post
                That's still crippling yourself though. I mean I guess it's very trendy nowadays with Vegans and such, but there are limits. I still need to get a job done.
                What does this have to do with veganism? Computer software does not put animals in cages or kill them unless it is operating equipment meant to do those things at a slaughterhouse, an "internet hunting site"(remote shooting) or that sort of thing. It can be defective or compromised by a malicious person inside or outside the dev team, but that is more comparable to food which is contaminated to the point of being unsafe to eat. That happens with both meat and vegetable foods, in fact is an unavoidable hazard of eating and always has been.

                Also, if vegan diets crippled people vegans would not be slightly over-represented among elite athletes. ANY bad diet (from steak and eggs based to "Taco Bell Vegan") can pack on the pounds or otherwise ruin your physical performance.

                I would compare a person's choice to go vegan to a choice to buy OpenPOWER vs x86, in a world where OpenPOWER procs and motherboards could be bought off the shelf with cash in any computer store or even fabbed on your roof or in your backyard.

                Comment


                • #18
                  A blob is a blob is a blob.... Just because it's not loading a blob from RAM doesn't mean it's not loading blobs. It -is-. And the ones that it loads are the oldest and -unfixed-. Complete retardedness.

                  Comment


                  • #19
                    Happy 10th anniversary to these kernel deblobers... In the same time and as a Debian user, i could also say Happy 7th anniversary to Debian's completely free of blobs Linux kernel by default

                    I think former is more fair approach to both groups I mean, really if you want to load these then load them it is your thing or if you don't want, that is what you get by default and who cares
                    Last edited by dungeon; 29 January 2018, 08:39 PM.

                    Comment


                    • #20
                      Originally posted by dungeon View Post
                      Happy 10th anniversary to these kernel deblobers... In the same time and as a Debian user, i could also say Happy 7th anniversary to Debian's completely free of blobs Linux kernel by default

                      I think former is more fair approach to both groups
                      Your linux kernel might not load blobs from RAM, but it -is- loading blobs for certain. And old unfixed blobs at that. They say it's a trust issue, but really they are trusting the least trustworthy blobs they possibly can.

                      Comment

                      Working...
                      X