No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    This time I tried spending more time answering, but I might just have created a wall of text little more worth than before, so I understand anyone who skips it.
    Now I have to trim it, so in two messages it'll go...

    Originally posted by bridgman View Post
    The wrong version could get built into the ROMs as well, although I agree the vendor might test more (and charge more) if they knew that updating was not an option.
    Yes, and I'd welcome more testing for a higher price.

    The point is the public does not know which is the wrong version, the
    one in the ROM or any other that the vendor publishes. People
    trusting the vendor forever will think the latest should include more
    fixes (unless marked beta or something). People not trusting the
    vendor will think the latest may include more flaws or backdoors or

    If the hardware has the code in ROM it is more complete, it does not
    need support in any OS for loading firmware, and it is not vulnerable
    to firmware files being altered (if they are signed then only the
    vendor should be able to alter them, but they can do it at a time we
    no longer trust them, their private key can be stolen, the public key
    you think is the vendor's might be altered, etc.)

    So when you load the firmware from a file, you are trusting nothing
    has gone wrong with the vendor (or your truststore) up to the moment
    you load it. When you use firmware in a ROM you are trusting nothing
    has gone wrong with the vendor up to the (earlier) point you bought
    the hardware. That's trusting less.

    It's not clear to me how "leaving it in" could be any harder to orchestrate than "finding it and removing it"
    The goals of the upstream project and the downstream project are
    different, so downstream can not count on the upstream fulfilling
    downstream goals and has to work around this.

    "Leaving it in" would mean distributing proprietary stuff or leaving
    in free code that will load proprietary code without even warning the
    user. I, as a linux-libre user, appreciate that they care that my
    kernel/distro does not load proprietary stuff so that I don't have to
    do the checking myself.

    What I meant was hard to orchestrate was a notary: that is some
    independent organization that constantly monitors all firmware
    published by all vendors, and can assure the public it was published
    at some date with some contents. You seem to imply this notary is, some binary tree in some git or some upstream already in
    use. Maybe it's not as hard as I thought, I don't know.

    Seriously, there is a tiny bit more work associated with confirming that microcode does not change from one libre distro release to the next, but someone has to do it if you aren't going to trust the vendor.
    Well I wasn't assuming libre distros would ship blobs. So the user
    would have to get the firmware from the vendor or some other
    repository. If a distro ships blobs, then they can ensure they never
    change which version of the blob they ship (I wonder if there's the
    case a new version of the blob works for the same set of hardware plus
    a new set, then they would have to add the new alongside the old and
    maybe change something to pick which one is used, but I must be
    nitpicking). The distro would still be responsible of choosing and
    authenticating the version they ship, instead of the user. Which is
    weird without being able to see the source, but not very different
    from any distro that ships proprietary apps.

    Again this all seems so bizarre because you *do* trust the vendor not to change anything when they burn the microcode into ROM.
    Well, you trust the vendor at some point, but you don't want to trust
    it forever. What you trust is that the code in ROM won't change since
    you buy the hardware, not that the firmware can't have been changed
    before (the hardware could also have been changed and an spying chip
    included or whatever). Once you have the hardware, you don't want the
    firmware to change under your feet (nor the hardware but that's
    phisical security).

    If the hardware and OS have the ability to upload firmware then the user or
    someone has to manage versions. The vendor is assuming everyone keeps
    trusting it so it won't help too much, and then a notary, the distro,
    the user or someone is going to have to keep track of which version is
    acceptable or not for a blob that can't be audited. It's not nice for
    free software supporters.

    Maybe a third party escrow would help, but then you still have the problem of ensuring reliable transport from escrow to distro - and you may end up increasing risk rather than decreasing it. I don't see what is so hard about doing a binary compare against what you shipped in the previous release. It takes time but no more time than deleting the file each time.
    The distro must at some point pick the first (only) version they ship,
    and there is no way to tell which one is better. In the end it just
    has to pick it at random, more or less like a buyer when he buys the
    hardware with firmware in ROM. But it kind of puts some kind of
    liabilities on the distro, while before they were between buyer and

    The distro may start life (or start supporting a vendor) at some point
    some versions have already been published. So the version the distro
    picks from the vendor may have been altered and identified as an
    earlier one if you don't trust the vendor. The distro may pick it from
    another repository, but that complicates things. Free software
    upstreams and downstreams have some trust relationships, but this
    complexity is mitigated by having the source of all versions available
    in case there is any doubt on reliability.

    I agree the notary, the scrow, is complicating things more than it's
    worth. But some form of it seems necessary if you want to be as sure
    of the version of firmware you get as if it were in ROM.

    I realize there is an "if a tree falls in a forest..." aspect to this, but I have a tough time understanding the difference between microcode that is fixed by virtue of being burned into ROM and microcode that is fixed by virtue of a distro-level decision not to pick up newer microcode files if the vendor releases them.
    One difference: parties involved fixing the version. Upstream does one
    thing, downstream wants another. One distro has to cater for many

    Another difference: parties involved in delivering proprietary firmare
    (libre distros don't deliver proprietary stuff).

    Perfect analogy, since I live in Canada where most people are allowed to have firearms but only after some fairly tight checks and controls, rather than "everyone has them" or "nobody has them". The point I'm making is that if the libre distros lock down on one version of vendor microcode then they *have* equalized the power, at least for users of their distro, since the vendor loses their power to update the microcode on the user's system. That's the nice thing about RAM-resident microcode - the choice to update it is made by the distros, not by the vendor.
    I think the distro is a weird place to put that decision, at least if
    it is a libre distro. It is a decision between buyer and vendor,
    supporting firmware you can't audit is just a leap of faith.
    Why should the distro be deciding which version of a bad thing
    all their users get?

    Not really - I do understand and value what the libre linux distros are doing; I just think they are following some outdated and overly simplistic doctrine.
    I don't think so. They need to keep it simple. For me it's like
    complaining they don't carry proprietary apps. It can become outdated
    if everybody gets into propietary network effect apps, but that is not
    the distro's fault, is just that their goals are becoming unpopular.

    I see it more like vendors caring only for a majority of their
    customers and leaving the others to do extra work (alone or in
    community) for making their hardware work. Some restaurants have meat
    or fish in every dish. So vegetarians can go elsewhere or just resign
    and eat meat. Some vendors solve their designs by assuming other
    people will distribute their proprietary code and load it into the
    hardware. So libre distros don't work with that hardware.

    Why not ? They support and recommend hardware with proprietary microcode burned into ROM - drawing the line at redistribution is like saying that killing an animal for meat yourself is bad but buying the meat at the supermarket in a little white plastic foam tray is fine. Hey, my hands are clean.
    I don't think they support and recommend hardware with proprietary
    firmware in ROM. The way I understand they encourage vendors to free
    their firmware. They also refuse to integrate proprietary content.
    The consequence is that the system won't work with hardware that needs
    the OS to load proprietary firmware (that's a byproduct of not
    supporting proprietary contents, not an end goal). Then they realise
    that they cannot stop vendors to puting proprietary content in
    ROMs. They simply can not know which hardware has proprietary content
    in ROMs, because they don't have the blueprints. If they know some
    hardware has proprietary content embedded they could decide to
    blacklist it to ensure it does not work in their system, but that
    seems to me going too much out of their way. It's not that they
    support hardware with proprietary microcode burned into ROM, is that
    they don't cripple it (they sensibly refuse to work to include code
    that detects it and halts the system). The hardware just works with
    their software and they don't stop it working. So they can say this
    hardware works with our system and this doesn't, that is not
    recommending it.

    If a vendor talks to libre-linux on what can be done to get some
    hardware supported under linux-libre (no idea if this happens or how
    often), linux-libre people might tell them their policy, and so that
    the best option is for the vendor to free the firmware. The vendor may
    discard this option very soon for whatever reason (the vendor can't,
    the vendor can but thinks it'll lose money, someone else won't allow
    the vendor to do it... whatever). The rest of the conversation if any
    may go about the fact that hardware needing proprietary firmware can
    work when firmware is already in ROM but linux-libre won't load it
    because it is proprietary. So the vendor's takeaway might be the
    vendor only option is to add a ROM with the firmware. And the vendor
    might go on to tell others so. But that is because some idea or
    awareness on the vendor situation that the vendor already had, that is
    not something linux-libre encourages.

    Linux-libre people are equally aware than they won't deal with
    proprietary material because that is the project's purpose, and
    changing it would amount to ending the project. So they might take
    away from the same conversation that vendors don't want or are not
    able to free firmware and they just want to put proprietary firmware
    in ROM or have it not working in linux-libre. They might even (I hope
    not) tell that directly to the nth vendor that comes asking.

    It's a little like going into a vegetarian restaurant, asking for a
    beef steak and a beer, and leaving thinking that in those restaurants
    they only serve drinks. Maybe going to that restaurant wasn't the best
    option for that person, but the conclusion is a little premature.

    Linux-libre, or the distro does not design or sell the hardware, they
    just refuse to let other peoples proprietary code in their systems.

    Agreed, but copying a stable version each time is no more work than deleting the file each time.
    Deleting proprietary stuff takes them closer to their goal and
    replacing a proprietary blob with another is kind of working for a
    vendor that didn't free their firmware. They could do it ? Yes, but it
    would be some other kind of project.

    Yeah, I do have some sympathy for that part of the discussion. One solution discussed earlier was having each vendor publish compatible repos with packages containing only their microcode, rather than having to download a non-free package containing hundreds or thousands of different images.
    Yes, any publisher of proprietary code should free their code, but if
    they don't, it's up to them to make it easier for their users to get
    the proprietary stuff, they can't rely on libre distros while their
    firmware is proprietary.

    I was responding to your comment suggesting that vendors shipping ROM-based microcode would periodically update the ROM-based microcode in their production line. I was just saying that even though HW vendors could do that my impression was that most of them did not.
    Yes, sorry. I'm spoiled by my email client deep quoting and in this
    forum I wasn't having context into acocunt. My mistake.

    If the microcode is distributed in files then the decision to update is in the distro's hands rather than the vendor's hands. A simple binary compare will tell if anything has changed.
    The binary compare won't tell if your users want one version or the
    other. You can have the policy to carry always the first version
    you've seen, but that does not make you a libre distro, just one that
    is closer to equivalent to the support a user would get if their
    hardware would have firmware in ROM.

    I don't know why people publishing proprietary stuff should shove
    decisions to others on which version to pick. I understand what you
    say is not very different than a vendor who doesn't care for freedom,
    so expect people who care to take care of themselves (and still buy
    their hardware). Well, that may fly if all competing hardware is
    similar, and the vendor may have economic incentives to do so. If
    there is sufficient market for ROM based firmware it may win some
    business from these people, and if there are offers with free firmware
    they may win even more. It all depends on how many people cares for
    that freedom, how much money they have, and how much hardware they
    want to buy.

    It's pretty much zero burden, and no more burden than deleting the file, so I would not say "too much" - in fact it's exactly the kind of integration work that distro packagers normally perform.
    I don't see libre distros integrating proprietary material.
    Other distros already distribute proprietary firmware.

    Nope... "everything is broken" is a consequence of the vendor giving distros the ability to update or not, and the libre distro choosing to delete instead.
    If the distro choses not to load firmware, the hardware fails by
    design, then I don't see that as a vendors giving distros an option.
    Distros are required to load proprietary firmware for the hardware to
    work. They are only given the option to choose between equally
    proprietary versions without any hint on which is better. This is
    hardware that does not work without distro help. Then with distro help
    it can be made to work always with the same version of firmware as a
    hardware with firmware in ROM would, or it can be made to work
    different. But the goal was never to have proprietary firmware in
    ROM. The goal was that any part of the solution which can change (has
    versions) has source and freedoms available.

    That suggests hiding microcode in ROM with no way to tell if it is changing is somehow better than delivering the microcode as a separate object where it is easy to identify changes. The only real argument in favour of ROM-resident microcode is the one related to "including content they idealogically don't agree with", which seems kind of hypocritical if they are also recommending hardware with even more microcode and less visibility into whether the microcode changed.
    How can microcode in ROM change ? Any user can tell the microcode he
    gets in their hardware ROM did't change since purchase. A production
    line can load different batches with different microcode versions, but
    they also sold different hardware 3 years ago.

    If you have updatable microcode then any user may change the version
    of microcode it uses just when it switches distros. Even between two
    libre distros, because they don't have to have the same version taken
    as their only version. They don't have to coordinate between them or
    with any vendor. Yes, the careful user can tell the change, the user
    itself can copy one version around when switching distros, but it is
    still pointless because nobody knows which version is better because
    it is proprietary and can't be audited.

    There is no visibility in blobs. I don't think they are recommending
    proprietary firmware in ROMS, they just can hardly avoid that working.
    Why isn't it hypocritical for a vendor to ask libre distros to ship
    the vendor's proprietary firmware just because the vendor can't ship
    free firmware ? Part of that vendor's design is in the hardware that
    comes in the box, the other part he asks strangers to distribute for
    them. What you got home from the shop won't work without the part
    strangers may give you.

    It also makes the hardware more expensive for everyone. It's tough to justify loading that cost onto all customers when EXACTLY the same result (with more visibility) can be obtained by having distros that don't want to trust vendor microcode updates to lock onto a single version.
    The desired result was that the hardware works with distros that only
    carry free content. Then we are kind of going in circles because from
    the case of the proprietary firmware (in ROM) being out of reach of
    the distro (so the distro can't avoid it being there) you claim libre
    distros should carry proprietary stuff, because there's a policy that
    would make it equivalent to when the proprietary stuff is out of reach
    of the distro. Only that in that case it is within reach, so it is not
    the same case.


    • #32
      The initial release is the version that comes out first
      But I wasn't looking when it came out. My distro wasn't looking
      when it came out. We don't want everybody to have to be looking
      constantly at all vendors just in case they might buy something
      from them some day in the future or may want to support their
      hardware in some distro we may some day build. So we don't know
      what version came out first.

      Now I can only go to a vendors website, or some other intermediary and
      trust that the version they now say it's the first one is really the
      first one.

      My friend has just got the same hardware product as I got a year
      earlier. Well, she got a product that was labeled with the same
      product name or number or whatever, but one of the chips was no longer
      available and the vendor had changed the design to include a different
      chip. The vendor updated the firmware to detect which version of
      hardware was there and drive it differently. So there are now version
      1 of the firmware and version 2 of the firmware. Version 2 works for
      both my friend and I but version 1 does only work for me.

      My distro has been convinced by your arguments of non-updated
      updateable firmware being as good as ROM resident firmware and apt for
      free software enthusiats and only carries version 1. I tell my friend
      to use it because it works great and we think we have the same
      hardware. But in this case the distro should carry version 2 for her,
      or both if there was a way for the software to tell which hardware
      is there.

      If the firmware was in ROM and not in the distro it would work for
      both of us. If the distro carried the latest version too.

      Now, the hardware we got might have been the same and version 2 could
      also have been introducing a backdoor imposed by the government of the
      hardware vendor, some crackers that got into the vendors systems or
      the new management of the vendor. Then the distro should carry version
      1 and my friend and I would be happy. If the firmware was in ROM and
      not in the distro my friend would have got version 2 and be screwed
      and I'd be fine. But the vendor could also have altered the wiring,
      added malicious chips or whatever without a new firmware version, so
      my friend was accepting the risk of malicious hardware shipping, it's
      not an added risk depending on whence the firmware comes or whether
      there is firmware at all. I accepted the same risk a year earlier.
      If the hardware became malicious I got lucky and she was not. If
      the hardware fixed flaws she was lucky and I wasn't. We can't tell.
      If the firmware is updatable we can choose the version we want,
      but we really don't know whether it got faulty or fixed. We just
      got the blame on us.

      The distro can't tell which of the 2 cases is happening. The buyers
      can't tell anyway.

      You may claim that a decent vendor will somehow label that the
      hardware is not realy the same and the distro could track that and
      offer both initial versions or so.

      I may claim that that is the vendor's job, not the distro's, and if
      they want to share that job, free the firmware and people will be able
      to look at what the changes mean. I may claim that I wish all
      companies were decent, but in reality all companies are different.

      The problem is that the vendor doesn't really support the notion
      of people no longer trusting them after buying their hardware
      (and things still working) and the distro isn't holding up the
      principle that every part of what they distribute should be able
      to be inspected and eventually understood.

      Yet an option was found (distributing a fixed version of the firmware
      with the hardware) that _seemed_ to allow both to have their way and
      things to work. But that is just make believe. Nobody really knows.
      The contradiction between libre distro and proprietary material was
      hidden, not resolved.

      Seriously, for a new libre distro I think any vendor would be willing to work with them to identify either "the first" or "the recommended" microcode version. Since the goal of the exercise is only to deny the vendor the ability to perform uncontrolled microcode updates going with "recommended" would probably make most sense in the rare case where there are post-launch updates.
      I appreciate your good will, but free software does not work like
      this. There is not a single new libre distro which has to be allowed
      to exist. Anyone has to be able to fork or start their own. Besides,
      if the vendor cannot be trusted and the firmware can not be audited,
      why should anyone believe the vendor when it says which version is
      best ? Your proposal is no better than just going with the latest
      versions. Vendors don't typically say "hey, get this new firmware, we
      really got it nasty this time !" (some company inside Alphabet once
      said it
      , but for devices that would get the new version irrespective
      of the user wishes). If they're compromised they won't know or won't
      want to tell.

      You may be drawing from experiences with distros that allow some form of
      proprietary stuff and continue to trust vendors. And vendors that try
      to make their hardware work with those distros. Both possibly
      prefering free firmware but both willing to live with proprietary
      firmware. I understand that's a common business case, but it is not
      obligatory. And is not the case linux-libre or the like address.

      This is what I just don't get. Modifiability is a property of the HW/SW/distro system, not just the hardware. Blocking updates at a hardware level is only one option.
      The problem is the party designing the hardware is the party with the
      knowledge of what's in the firmware. The parties doing the other parts
      have to block or allow firmware updates with much less info, so when
      the hardware itself allows updates, the other parties are going to
      have to trust the hardware vendor even if they don't want to. They may
      have the possibility to block or allow updates, but not any reliable
      info on how to decide it. It's like inviting someone to Russian
      roulette and letting them choose where to sit, no wonder they refuse
      (shit, I don't really like gun analogies).

      You only have auditability with file-based microcode, not with ROM-based. If anything the wrong hardware is being blocked based on that logic.
      You only have auditability with freedom, source and toolchain and
      enough info on the hardware. ROM won't change its contents in a
      unit. You can be as sure of that as of an empty binary diff.

      Maybe I wasn't clear. When I said at the begining you may want to
      trust a vendor only once, I meant each user wants to trust the user
      only once. They don't have to all pick the same time, and I didn't
      mean the distro trusts the vendor once. The buyer trusts the vendor
      when he buys its hardware. The distro does not tell them when or what
      to trust because the distro doesn't have the info. Once the buyer has
      bought the hardware he is exposed to any antifeatures,
      vulnerabilities, etc. the vendor may have included but not to any
      further ones.

      Sure, but make sure they are caring about the right thing. Driving more microcode into ROM means you lose auditability and don't gain anything. The last thing you want is more people caring about *that*.
      I don't see what auditability you lose.
      Linux-libre does not drive microcode into ROM, it just happens to work
      with microcode it doesn't have to load because it's already there.

      Linux-libre people just refuse to work with material that they can't
      know what does.

      Vendors can always put whatever they want in as many ROMs as they want
      in their hardware. They even get away without giving blueprints for
      what they sell. There is nothing a customer can do to to stop
      them other than buying from open hardware people instead of them
      (and then making sure somehow the blueprints and hardware match).

      Linux-libre just leaves the vendor with the option of puting anything
      wrong in the hardware or ROM (which the vendor already had) and
      removes the option of putting anything wrong in any proprietary
      firmware loaded at runtime. So they leave the vendor with one option
      for doing wrong instead of two. The vendor still can do things that
      are as worrisome as before. Or the vendor can do the right thing and
      free the firmware and linux-libre will allow updates. The only thing
      the vendor can't do is become compromised for hardware already
      sold. If what was shipped at time T was safe, with linux-libre it will
      stay safe at T'>T. It's not for linux-libre to decide whether it was
      safe at T.

      Yes, it cripples hardware from vendors which offer their users a choice, and supports hardware from vendors which hide the microcode in ROM with no ability to audit (or reverse engineer, if it comes to that).

      It makes the message obvious, but the message is the exact opposite of what free software advocates should be sending.
      The message is proprietary stuff doesn't work well enough.

      Again, linux-libre does not cripple anything, it will just not do the
      job of the hardware vendors for them and as a consequence hardware
      that doesn't work without loading proprietary firmware won't work.
      That hardware is crippled as sold and only gets fixed when the
      software collaborates.
      Last edited by phoron; 01 February 2018, 08:00 AM.


      • #33
        Originally posted by phoron View Post

        Again, linux-libre does not cripple anything, it will just not do the
        job of the hardware vendors for them and as a consequence hardware
        that doesn't work without loading proprietary firmware won't work.
        That hardware is crippled as sold and only gets fixed when the
        software collaborates.
        And the bottom line is that this whole paragraph is wrong. Linux Libre -DOES- still rely on firmware. That firmware -IS- still proprietary. Not only that but the fact is that the hardware the FSF recommends is among the heaviest microcoded hardware in existence. And what makes that whole lie a shame is that libre distributions -choose- to have no control over it. They -choose- to trust the least trustworthy firmware they possibly can.


        • #34
          Originally posted by duby229 View Post

          And the bottom line is that this whole paragraph is wrong.
          The last paragraph in my wall of text ? Wow, thank you if you read it all.

          Linux Libre -DOES- still rely on firmware. That firmware -IS- still proprietary. Not only that but the fact is that the hardware the FSF recommends is among the heaviest microcoded hardware in existence. And what makes that whole lie a shame is that libre distributions -choose- to have no control over it. They -choose- to trust the least trustworthy firmware they possibly can.
          Ok, just to teach me, could you tell me what could linux-libre do so that it does not rely on proprietary firmware ? Should it start designing, manufacturing and selling hardware ?
          How do they even know proprietary firmware is there at all ? How do you remove it if it is there ? The only "solution" I find is if you don't want proprietary firmware, try to check advertising and public info and when you discover some device has proprietary firmware in ROM then just blacklist it. But what about hardware having proprietary firmware in a ROM that linux-libre does not know about ?

          You sound like you're complaining linux-libre is not some super-hero that can stop hardware vendors keeping their firmware proprietary. Well, yes, they're no super heroes.
          They still get my gratitude.


          • #35
            Originally posted by oiaohm View Post

            From a security point of view everything should be auditable. Ok auditable does not mean you have the rights to change anything.
            I tend to think auditable means free. You may argue otherwise but in the end really auditable means:

            1.- anyone can look, not just some designated party
            2.-. anyone can experiment, change and see what it does.
            3.-. those auditing can collaborate. The design is out there for the world to analyse, not just a contractor.
            4.- Those putting in the work to audit can get something in exchange. No vendor can contract the whole world, so being able to reuse the design is some kind of pay.

            I completely see that being free does NOT mean it's audited. People can have all the rights they need and just don't look there.
            It's more like being non-free is a too strong hint it won't get audited properly.

            So, well, I may be too demaning on what audit means, but I'm spoiled by free software. I'm not claiming anyone has to agree, this is a personal view.

            The rom it or free it I disagree with. Just because something is in a unchangeable rom does not mean its a not a massive security hole and is not an area doing copyright infringement.
            But I agree, very nasty things can be in ROMs.
            I only say noone seems able to avoid that. A ROM could be there that noone outside the vendor knows.

            My point of view is please show us that what you are doing is secure and what you are using is not nicked from someone. There have been enough cases of silicon vendors stealing source and ip from other parties and attempting to hide the fact behind trust us.
            How will they show you ? How can you tell the hardware you got is by the design they posted ? If it is at all possible it must be expensive as hell.
            Buying hardware (as opposed to building it yourself down to the silicon, assuming that's even possible) means you're hosed. From there is
            all way down to mitigate risks. You'll never be sure. I'm somewhere having a draught now. The forecast tells it's going to rain and snow in a few hours.
            So I'm happy, but a meteorite could fall in 5 minutes. So what?


            • #36
              Originally posted by phoron View Post

              The last paragraph in my wall of text ? Wow, thank you if you read it all.

              Ok, just to teach me, could you tell me what could linux-libre do so that it does not rely on proprietary firmware ? Should it start designing, manufacturing and selling hardware ?
              How do they even know proprietary firmware is there at all ? How do you remove it if it is there ? The only "solution" I find is if you don't want proprietary firmware, try to check advertising and public info and when you discover some device has proprietary firmware in ROM then just blacklist it. But what about hardware having proprietary firmware in a ROM that linux-libre does not know about ?

              You sound like you're complaining linux-libre is not some super-hero that can stop hardware vendors keeping their firmware proprietary. Well, yes, they're no super heroes.
              They still get my gratitude.
              It's plainly obvious the only solution is massive scale reverse engineering. (It would still need firmware even if the firmware was open source) And I don't think that's ever gonna happen. Every new hardware generation would take years to develop support for, we've already been down that path and it's just not worth it. The Nouveau developers are unfortunately forced to go through that scenario against their wills, And I think they've done a fantastic job given the circumstance, but it's plain to see progress made vs similar projects. That's why it's not worth it.

              Radeonhd vs radeon. That was the scenario that convinced me. And nobody here can say AtomBIOS is hardware, it's definitely software and it's definitely firmware. Because it was supported in radeon, it became the clear winner. Radeonhd did eventually adopt support for it as well, but it was too late by then.
              Last edited by duby229; 01 February 2018, 10:51 AM.


              • #37
                Originally posted by WolfpackN64 View Post
                And who are you going to trust to carry the foss banner?
                firmware is not software, so it has nothing to do with foss
                Originally posted by WolfpackN64 View Post
                I don't use GNU/Linux-Libre as a kernel, but at least I understand why it's there.
                to show that you can use same microcode blobs, but factory installed buggy obsolete versions?
                Originally posted by WolfpackN64 View Post
                You could have the decency by at least trying to understand before you call the good people at the FSF "lunatics".
                they can't be good if they insist that old buggy blob is better than new fixed one


                • #38
                  Originally posted by R41N3R View Post
                  Without the fanatics we would just continue to trust closed blobs everywhere.
                  with fanatics you now trust same blobs but old buggy factory installed, which makes you idiots


                  • #39
                    Originally posted by phoron View Post
                    This is also considered and there are reasons for it. You may not like them, but there exist.
                    yeah, the reason is those people are idiots and obviously it is not very likeable reason. i have no desire to read your pages of bullshit, so just one example:
                    Originally posted by phoron View Post
                    The idea (which you might share) is that by using some vendors hadware you implicitly trust that vendor. There can be ROMs anywhere whether they tell you or not. In theory there might even be hardwired backdoors or threats without even code in ROMs. The difference between (a) ROM-only blobs and (b) uploadable blobs is that with (a) you trust the vendor once and with (b) you have to keep trusting them everyday in that they won't introduce new threats with updated blobs, either by malice, incompetence, government coercion or attack against the vendor.
                    here is example of your idiocy. first, you can only trust once if you will will ever buy only one hardware piece, which is not practical. second, same "once" is doable with loadable blobs - just load same fucking version and do not update it. that would be idiotic, but it would be same "once" as in blobs from rom of flash. see, no "deblobbing" required to have exactly same result


                    • #40
                      Originally posted by phoron View Post
                      I'm not sure I understand you.
                      that does not surprise me
                      Originally posted by phoron View Post
                      By once I mean when you buy the hardware. You seem to mean everytime you install the OS ?
                      obviously every time you install your os you have to trust your os vendor. so you could trust them for example that they use obsolete blob version if you selected distro for idiots