7 ms·
Linux Vendor Firmware Service
- rekado 9y agoIs 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.
- jle17 9y agoI 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.
- rekado 9y agoMy 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).
- hutzlibu 9y agoWell, if they think it is too hard otherwise, they might decide the alternative is no update at all. And I rather have a working binary blob on my Linux, than no open source driver at all.
- bipson 9y agoIn 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.
- JepZ 9y agoAnybody 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).
- Juliate 9y agoOpen-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.
- svendbt 9y agoA 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?
- mikegerwitz 9y ago> 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.
- snvzz 9y agoIn 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. [1] https://fwupd.org/vendorlist https://fwupd.org/vendorlist
- hughsient 9y agoTrue, 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.
- zimbatm 9y agoThis seems like a really useful service! 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.
- olau 9y agoRichard Hughes works for Red Hat - I think they are sponsoring his time: https://blogs.gnome.org/hughsie/ https://blogs.gnome.org/hughsie/
- Rondom 9y agoAnd another contributor (Mario Limoncell) works for DELL.
- hughsient 9y agoTrue, 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.
- digi_owl 9y agoI can't help think the actual software end of this is over-engineered.
- esarbe 9y agoI can't help thinking that you should elaborate how you came to that conclusion. Happy day!
- digi_owl 9y agoIt 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.
- andrey_utkin 9y ago> This site is used by all major Linux distributions to provide metadata for clients such as fwupdmgr and GNOME Software. 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-firmware.git 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.
- olau 9y agoEh, 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.
- andrey_utkin 9y agoAh, you are right: > 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.
- Aissen 9y agoYou 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.
- discreditable 9y agoWow, 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".
- antongribok 9y agoI'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!
- Rondom 9y agoCould 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.