Is this a service to encourage the distribution of proprietary software? Firmware ought to be built from source, like any other software that runs on my hardware.
I think it is dangerous to give legitimacy to proprietary software just because it doesn't get executed by the main CPU.
I don't think it's fair to supect Richard Hughes, who makes the ColorHug (open source/open hardware colorimeter) of trying to encourage proprietary firmware.
This is just a service to encourage up2date firmware, proprietary or not.
My comment was not meant to be a slight against the people behind the service. I just think that it is dangerous to give hardware people an alternative to doing things the right way, namely to allow for their "firware" to be built from source (and as part of the kernel).
In a perfect world there would only be open firmware for all devices. We don't live in such a perfect world, and even Linux users might have e.g. a Logitech unifying receiver. And nobody should disallow them to use one with Linux. Modern Linux comes with a huge set of firmware for e.g. DVB-T sticks or WiFi adapters.
Vendors should be allowed to distribute Linux compatible firmware for their products.
Vendors need a reasonable way to update the firmware, if there are e.g. severe security bugs.
Users should have a reasonable way of getting these updates, without having to constantly monitor all pages for all their devices (and switching over to WIN just to update the via a "Updater Tool v4.732.x").
This is a good thing. It makes peoples' devices more secure. The integration with Gnome is seamless and updating usually simple (it is quite a new thing though, and some specific things can always go wrong). Users are free to chose with which vendors they do business and whom to trust.
Anybody knows why vendors are still afraid of releasing their firmwares as source code? I mean are they afraid of patent law suits or do they hope they can cover up some super secrect sauce within their products?
At the moment I feel like closed source firmwares are one of the biggest issues for open source operating systems (especially with regard to mobile operating systems).
Open-sourcing process (that is not part of the culture/structure of manufacturers) and consequences (that provide no direct benefit on the manufacturer industrial bottom line).
Consider:
* direct IP & IP on sub-systems,
* possibility to reverse firmware-added tweaks (used to make/justify market segmentation).
From the commons point of view, we'd all benefit from open source firmwares.
From each and every one manufacturer POV, the associated risk and cost look way bigger than the hypothetical business benefit.
A few points from my own experience:
- Competitive advantage.
Providing open source drivers/stacks will in many cases provide insight into implementation details you do not want competitors to easily understand. Also, complex software stacks (the generic parts) could be recompiled by a competitor into a "free" stack of their own. Closed source provides a barrier for competitors to entering the market by cheating/stealing.
In addition, all silicon have bugs that you don't always want your competitors to know about by seeing the workarounds in SW. They will use that against you when trying to replace your chip in a product.
- Customer support and liability
With limited customer support resources, you don't want to debug your product for a customer without knowing exactly what code is running. This applies both for the end product and the silicon vendor. As an example - what happens if a modified driver bricks the product?
> Providing open source drivers/stacks will in many cases provide insight into implementation details you do not want competitors to easily understand
Competitors will have the resources to reverse engineer; it's not an effective means of hiding implementation details. It _is_ an effective means of wasting free software and security communities' time by forcing them to reverse engineer if they want to use hardware.
Assuming that the vendors act as they do out of fear biases causal analysis away from simple business cases. One of those cases is that vendors may have developed their firmware with software that limits the ways the firmware can be distributed. Another case is that vendors may have incorporated software licensed from other companies and that license agreement prevents release of the source code...or more simply the third party software may have been distributed as a binary. Finally, the source code may have been developed with custom or proprietary tooling, build systems, etc. that are not generally available and so releasing the source code doesn't mean that people can use it or understand it.
Theoretically, it is possible to untangle a big ball of string. Theoretically, it is not possible to untangle a big ball of mud.
Thanks for pointing out the additional use case that can receive more consideration once fear is removed as a primary motivation.
I think that order to be a primary motivating behavior, it would have to also be the case that none of the licensing/tooling issues apply. This suggests that logically it may be less likely as a primary cause due to the dependency.
Well, yeah that is a problem. Does anybody here have an idea how that could be solved?
I mean if the firmware would be released with its source everybody could buy the cheap version and load the full-featured firmware version to their hardware. Even if the manufacturer would place some kind of memory on the hardware which holds the feature-level, someone could patch the firmware to ignore that value.
There probably could still be some market segmentation based on the results of what comes out of the silicon fab. Recall that in the case of CPUs, the circuits on dies of processors from the same line (and different lines!) are the same, but some sections are disabled (blown fuses, cut traces, etc) because those sub-sections didn't make the grade during testing prior to packaging. I've not looked, but I'd not be surprised if that weren't also the case with GPUs as well. Sure, you can enable the extra sections of $mid_range_GPU to make it on-paper-equivalent to $top_shelf_GPU, but it's on you to meet its now-unreasonable power and cooling requirements.
In their Vendor List [1] fwupd do provide status of their relationship with a bunch of vendors.
Interestingly, it can be deduced from the comments column that fwupd has been proactively contacting vendors to try and get them involved, with varying success.
True, I have. I've sent many hundreds of emails, but also some companies have reached out to me proactively. We're getting there, but it's going to be a slow burn.
If it was under the umbrella of a bigger non-profit it would probably be more successful to recruit companies. Right now it looks like it is done by a single person which means the project can disappear at any time. It is also not clear if the project will be sustainable in terms of infrastructure hosting.
True, Red Hat have been awesome with my time. Lots of donors are sponsoring the hosting; including Amazon for the bandwidth. There's a link on the lvfs page if you'd like to throw some money in the hat, so to speak. Long term this hopefully gets transferred to the Linux Foundation, although we're still working on the legal niggles. More to share when I know more myself.
It uses a daemon that gets talked to over dbus (and i see systemd in the flowchart, but as they have adopted meson, requiring ninja and python3, i can't really tell if it is just a vestigial thing or deeply embedded). And from the documentation it seems that said daemon will be autostarted by dbus if any of the "frontends" gets fired up. This reeks of overcomplicated Gnome-sims.
Eh, I'm not an expert on this, but as I understand this project is about firmware that needs to be flashed onto devices. The kind of thing where people in the old days formatted a floppy disk and booted from that. So I think your comparison is incorrect.
I would expect more clients to pop up once this gets a bit more traction.
> NOTE: This service should only be used to distribute firmware that is flashed onto non-volatile memory. It is not designed for firmware that has to be uploaded to devices every time the device is used.
You are comparing two different things. linux-firmware is composed of blob files used by kernel drivers when they do request_firmware(); for devices that load the firmware in RAM and work from that, and have (mostly) no permanent storage.
This project is for firmware blobs that 1/ are already on the device; 2/ for which the update method is traditionally a vendor-provided windows binary; the fwupdmgr incorporates plugins that implement all the different update methods for those devices.
There's nothing maliciously misleading here, and vendors do know the difference between those two.
I see that I was wrong in my comparison. Yet I see the claim "This site is used by all major Linux distributions (for whatever)" misleading. Linux distributions directly don't use this site for anything. They happen to provide package for mentioned apps, that's all.
E.g. I can claim that my HDD-testing app is available in distros, but I would be wrong claiming that all major Linux distributions use my app to test HDDs.
I have Ubuntu, Fedora and Debian systems. All come with fwupd installed by default. I don't have a RHEL7 system to check, but it is in the repos of CentOS7. Whether it is activated by default, I don't know, but given that it is in the repos, I think it is. Linux Mint probably uses GNOME Software as well in its Cinnamon and Mate environments.
I am not sure about Arch and of course there is KDE (OpenSUSE/SUSE) left.
Still I think calling it a "misleading claim" a bit of a stretch given that "all the major distros" (or nearly) ship it in their default install.
Oh and don't get into quibbling about what "use" means here. If I follow that argument, Linux distribution don't "use" or "do" anything. All they do is shipping software.
fwupd is for firmware in external/flashable devices or uefi/bios stuff.
the linux-firmware can only install cpu/gpu/everything which loads firmware everytime related firmware.
Wow, this is awesome. I booted up an Ubuntu 17.10 live and was able to quickly update a bunch of Logitech Unifying Receivers I had sitting around using "fwupdmgr update".
I've been using this as part of Fedora (25 - 27) for the past year on a Dell XPS 13 9360 (Developer Edition). It's been working flawlessly with BIOS updates from Dell.
The end user experience is better than anything I've experienced on Windows (and dare I say smoother than OSX).
Between this and the 22-hour battery life on Linux the XPS 13 is highly recommended!
Could not agree more. I updated my DELL's BIOS and TPM Firmware and it was a breeze! The same goes for my Logitech Unifying receivers (they had some security issue).
And I can see which difference it makes. I still have not patched my other laptop, because I need to extract the image from a Windows installer put it on a USB stick at a specific path (which I always forget...) and then reboot, reboot again because I did not interrupt the boot fast enough, run the update.
34 comments
[ 4.0 ms ] story [ 76.1 ms ] threadI think it is dangerous to give legitimacy to proprietary software just because it doesn't get executed by the main CPU.
This is just a service to encourage up2date firmware, proprietary or not.
And I rather have a working binary blob on my Linux, than no open source driver at all.
Vendors should be allowed to distribute Linux compatible firmware for their products.
Vendors need a reasonable way to update the firmware, if there are e.g. severe security bugs.
Users should have a reasonable way of getting these updates, without having to constantly monitor all pages for all their devices (and switching over to WIN just to update the via a "Updater Tool v4.732.x").
This is a good thing. It makes peoples' devices more secure. The integration with Gnome is seamless and updating usually simple (it is quite a new thing though, and some specific things can always go wrong). Users are free to chose with which vendors they do business and whom to trust.
At the moment I feel like closed source firmwares are one of the biggest issues for open source operating systems (especially with regard to mobile operating systems).
Consider: * direct IP & IP on sub-systems, * possibility to reverse firmware-added tweaks (used to make/justify market segmentation).
From the commons point of view, we'd all benefit from open source firmwares. From each and every one manufacturer POV, the associated risk and cost look way bigger than the hypothetical business benefit.
In addition, all silicon have bugs that you don't always want your competitors to know about by seeing the workarounds in SW. They will use that against you when trying to replace your chip in a product.
- Customer support and liability
With limited customer support resources, you don't want to debug your product for a customer without knowing exactly what code is running. This applies both for the end product and the silicon vendor. As an example - what happens if a modified driver bricks the product?
Competitors will have the resources to reverse engineer; it's not an effective means of hiding implementation details. It _is_ an effective means of wasting free software and security communities' time by forcing them to reverse engineer if they want to use hardware.
Theoretically, it is possible to untangle a big ball of string. Theoretically, it is not possible to untangle a big ball of mud.
The hardware across a family with different prices and features is identical. Features are then enabled/disabled by firmware alone.
This is frequently done to save on silicon manufacturing costs, but still allows marketing/sales to negotiate on features.
I think that order to be a primary motivating behavior, it would have to also be the case that none of the licensing/tooling issues apply. This suggests that logically it may be less likely as a primary cause due to the dependency.
I mean if the firmware would be released with its source everybody could buy the cheap version and load the full-featured firmware version to their hardware. Even if the manufacturer would place some kind of memory on the hardware which holds the feature-level, someone could patch the firmware to ignore that value.
Interestingly, it can be deduced from the comments column that fwupd has been proactively contacting vendors to try and get them involved, with varying success.
[1] https://fwupd.org/vendorlist
If it was under the umbrella of a bigger non-profit it would probably be more successful to recruit companies. Right now it looks like it is done by a single person which means the project can disappear at any time. It is also not clear if the project will be sustainable in terms of infrastructure hosting.
https://blogs.gnome.org/hughsie/
Happy day!
Actually means: "This site is used by author's apps 'fwupdmgr' and 'GNOME Software'"
Wants you to believe it means: "This site is used by all major Linux distributions to serve firmware for all your devices".
What all major Linux distributions use is this git repo hosted by Linux Foundation:
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-...
which is made available and automatically upgradable as "linux-firmware" system package.
Sorry for sounding harsh, I just couldn't stay quiet on that misleading claim.
I would expect more clients to pop up once this gets a bit more traction.
> NOTE: This service should only be used to distribute firmware that is flashed onto non-volatile memory. It is not designed for firmware that has to be uploaded to devices every time the device is used.
This project is for firmware blobs that 1/ are already on the device; 2/ for which the update method is traditionally a vendor-provided windows binary; the fwupdmgr incorporates plugins that implement all the different update methods for those devices.
There's nothing maliciously misleading here, and vendors do know the difference between those two.
E.g. I can claim that my HDD-testing app is available in distros, but I would be wrong claiming that all major Linux distributions use my app to test HDDs.
I am not sure about Arch and of course there is KDE (OpenSUSE/SUSE) left.
Still I think calling it a "misleading claim" a bit of a stretch given that "all the major distros" (or nearly) ship it in their default install.
Oh and don't get into quibbling about what "use" means here. If I follow that argument, Linux distribution don't "use" or "do" anything. All they do is shipping software.
The end user experience is better than anything I've experienced on Windows (and dare I say smoother than OSX).
Between this and the 22-hour battery life on Linux the XPS 13 is highly recommended!
And I can see which difference it makes. I still have not patched my other laptop, because I need to extract the image from a Windows installer put it on a USB stick at a specific path (which I always forget...) and then reboot, reboot again because I did not interrupt the boot fast enough, run the update.