Announcement

Collapse
No announcement yet.

System76 Unveils Their Firmware Manager Project For Graphically Updating Firmware

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

  • #41
    Originally posted by Awesomeness View Post

    I'm understanding everything: You wrote system76-firmware as NIH alternative to fwupd instead of distributing your firmware through fwupd like almost everybody else.
    You are completely missing the point for this software. Lets say System76 did use fwupd, guess what? they would of still made this. They didn't like how the graphical frontend for fwupd was tied into gnome software and they didn't want their own firmware delivery method tied to a software application.

    This Firmware Manager works with both, so that system76 owners and owners of other stuff can use the same gui and don't have to use gnome software.

    And someone mentioned with system76 doing their own thing, whats stopping others from doing their own thing as well. Nothing. Sure right now most companies that are doing this have gone the fwupd route, but if they wanted to they could easily spin up their own thing. This is where this nice piece of software comes in handy. It supports both system76-firmware and fwupd. It can also be made to support any other hardware vendor spec as long as that company makes it open enough.

    So thank you mmstick keep up the great work! though two complaints, support my broadwell lemur (nothing wrong with it just sad that it isn't supported) and get amd laptops, yeah i know clevo doesn't do amd, but you guys support linux and you know the linux community prefers open source stuff over closed source stuff.

    Comment


    • #42
      Originally posted by Awesomeness View Post

      I'm understanding everything: You wrote system76-firmware as NIH alternative to fwupd instead of distributing your firmware through fwupd like almost everybody else.
      The article that you're commenting on is about the new Firmware Manager. It is not system76-firmware. system76-firmware is simply one of the supported backends of Firmware Manager, in addition to fwupd.

      Addtionally, no one ever said that we would never use fwupd or LVFS. Once it meets our needs, and the decision is made to do so, the Firmware Manager would make such a transition seamless.
      Last edited by mmstick; 08-18-2019, 06:37 PM.

      Comment


      • #43
        I could understand some not invented here syndrome in this case. I mean, you've got to have a reason to exist, right? If they just resell other people's hardware AND they also reuse other people's software, than they might as well not exist.

        Comment


        • #44
          This basically kills buying a system76 computer for me.

          1) Security: All possible methods to update firmware have the potential to be open to error or attack. Do I prefer a system supported and maintained by many large vendors and the linux foundation, or a homespun one from a small vendor? They got the argument that fwupd increases attack surface with respect to the system76-firmware back-end backwards. Classical case of "we are infallible and inherently trustworthy but others are not".

          2) Use of proprietary closed blobs to perform the update: No word on why this is needed or a good idea, only hand-waving that other stuff in firmware is proprietary as well so we shouldn't care. They may be right or wrong, but what I have read so far is not convincing.

          3) Bad communication: Here the dev tells us that it is about the gui, about not relying on gnome-software etc. Not credible, because they proved that this can be solved with their front-end to fwupd. Why not host their firmware there then? Their entire communication looks to me like a smoke screen in front of what seems to be the real reason hinted at in their blog post: A centralized fwupd service might allow someone to deduce how many machines from system76 are out there. Simple case of them wanting to keep their stats to themselves. That may be a sound reasoning from the perspective of a company (though others seem to have either found a way around that or don't have a problem with it). But as a user, I don't care. Why should I put up with 1) and 2) for the corporate interests of system76? I see no reason at all.

          Yes, Linux is about choice. So a new GUI as a front-end to fwupd is very welcome, well done system76! To me as someone who is not their customer that is great, and I may actually use it. But the main motivation behind this seems to be to create a way to lock their customers into their proprietary way of distributing firmware. Not what I would want so I'll make sure I won't become one of their customers.

          Comment


          • #45
            It is seems pretty cool, the first time I updated the firmware was through Debian but the CLI application worked perfectly fine. Flashing the bios is a risky operation it should be pretty hidden in my opinion but it is integrated so nicely in POP! that I think everything will work smoothly, I look forward to find it on my POP!

            Comment


            • #46
              Originally posted by JanW View Post
              This basically kills buying a system76 computer for me.

              1) Security: All possible methods to update firmware have the potential to be open to error or attack. Do I prefer a system supported and maintained by many large vendors and the linux foundation, or a homespun one from a small vendor? They got the argument that fwupd increases attack surface with respect to the system76-firmware back-end backwards. Classical case of "we are infallible and inherently trustworthy but others are not".

              2) Use of proprietary closed blobs to perform the update: No word on why this is needed or a good idea, only hand-waving that other stuff in firmware is proprietary as well so we shouldn't care. They may be right or wrong, but what I have read so far is not convincing.

              3) Bad communication: Here the dev tells us that it is about the gui, about not relying on gnome-software etc. Not credible, because they proved that this can be solved with their front-end to fwupd. Why not host their firmware there then? Their entire communication looks to me like a smoke screen in front of what seems to be the real reason hinted at in their blog post: A centralized fwupd service might allow someone to deduce how many machines from system76 are out there. Simple case of them wanting to keep their stats to themselves. That may be a sound reasoning from the perspective of a company (though others seem to have either found a way around that or don't have a problem with it). But as a user, I don't care. Why should I put up with 1) and 2) for the corporate interests of system76? I see no reason at all.

              Yes, Linux is about choice. So a new GUI as a front-end to fwupd is very welcome, well done system76! To me as someone who is not their customer that is great, and I may actually use it. But the main motivation behind this seems to be to create a way to lock their customers into their proprietary way of distributing firmware. Not what I would want so I'll make sure I won't become one of their customers.
              Regarding #3: Their decision to use their own firmware service over fwupd was something that they made ages ago and was not something that just happened with the announcement of this project. This project is simply them building a GUI for their own service and then throwing in fwupd support while at it.

              Comment


              • #47
                Originally posted by F.Ultra View Post
                This project is simply them building a GUI for their own service and then throwing in fwupd support while at it.
                It's actually the opposite. We already had a GUI for system76-firmware. What we lacked was a GUI for fwupd. This project's goal was therefore to provide a generic firmware manager that supports both fwupd and system76-firmware, so it wasn't about throwing in fwupd support in addition to system76-firmware.

                Comment


                • #48
                  So much confusion and toxicity, this is sad.

                  Thanks @mmstick for staying constructive and clarifying things.

                  I think the biggest bit that it left is about this afuefi non-libre tool. Which totally prevents LVFS for your computers.

                  What are the reasons for being tied to it? I guess it's not by pleasure that you use non-libre stuff for updating firmware.

                  Comment


                  • #49
                    Another unclear thing is: Was self hosting an LVFS repo a non-viable solution? There you could ship afuefi.
                    Your fwupd graphical front end was still needed but no need building a client and server backup (system76-firmware)

                    Comment


                    • #50
                      And lastly: can you detail about why the LVFS/fwupd data collection is unnecessary? So we can have something more concrete. Because without having studied the context like you did, it's hard to be sure that a piece of data is unnecessary. (well, at least I wish we as a community would do this more before getting our pitchforks out too easily ^^")

                      Oh, i missed the link to the privacy analysis of gnome software + fwupd: https://fosspost.org/analytics/priva...gnome-software

                      (humble suggestion: have a tl;dr in your article about which pieces of data should have been opt-out instead if opt-in)

                      I have some thoughts about it so I can try: /etc/machine-id doesn't bring enough benefits to LVFS to be collected opt-in. But maybe LVFS justified it and I didn't found it, or it should have been more clear: [1]
                      Still your findings should be more valuable than mines ^^

                      About this topic, if I understand correctly, that wasn't a blocker for using fwupd instead of creating system76-firmware because you could just disable this data collection in Pop!_OS and the Ubuntu that you ship.

                      Thank you @mmstick for your time and your work. It's very valuable to be able to communicate directly.

                      Comment

                      Working...
                      X