
Linux Vendor Firmware Service - Aissen
https://fwupd.org/
======
antongribok
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!

~~~
Rondom
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.

------
andrey_utkin
> 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-...](https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-
firmware.git)

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.

~~~
Aissen
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.

~~~
andrey_utkin
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.

~~~
Rondom
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.

------
snvzz
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.

[1] [https://fwupd.org/vendorlist](https://fwupd.org/vendorlist)

~~~
hughsient
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.

------
JepZ
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).

~~~
brudgers
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.

~~~
Anticapitalist
You missed the most likely business case.

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.

~~~
JepZ
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.

~~~
korethr
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.

------
zimbatm
This 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
Richard Hughes works for Red Hat - I think they are sponsoring his time:

[https://blogs.gnome.org/hughsie/](https://blogs.gnome.org/hughsie/)

~~~
hughsient
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.

------
rekado
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.

~~~
jle17
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.

~~~
rekado
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).

~~~
hutzlibu
Well, 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.

------
discreditable
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".

------
digi_owl
I can't help think the actual software end of this is over-engineered.

~~~
esarbe
I can't help thinking that you should elaborate how you came to that
conclusion.

Happy day!

~~~
digi_owl
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.

