You're going to have to be more specific on why a failing HSI attribute contributes to the undoing of your privacy? You're aware the security attributes are each based on mitigating actual real-world attacks, right?
You're aware that ME itself is considered a security hole, and that a lot of people disabled it, right? Not to mention, most of the hsi2 and 3 stuff need ME as a dependency?
Edit: again, why is this any part of a firmware updater?
Edit2: this doesn't even get into unsigned kernels, out of tree modules, and unencrypted swaps (or at least not encrypted in the special way fwupd wants them to be)
I feel I must apologize, but my first experience with fwupd was switching from MATE to KDE, opening kinfocenter and seeing all of this... While some of this is a KDE problem, I don't even see a place to update said firmware without using the CLI.
> this is probably leaking information thru its comm channel
It's really not. The fwupd process doesn't have any internet access at all -- all communication is done through a socket over DBus. All the telemetry is done with the user explicitly opting in -- we even show the JSON in the terminal that is going to be sent.
> Does anyone know why this is running 24/7
We auto-quit on idle or for low memory conditions -- unless you have hardware that's expensive (either in terms of power, or time) like thunderbolt and synaptics MST. The resident RSS is tiny as we mmap all the data files which can be paged out by the kernel -- we can even run fwupd on the tiny BMC processor as well. I'd be interested in what OpenSnitch says, but the D-Bus interface is the only way in and out. Interesting, the daemon doesn't actually do any policy actions itself; all actions have to be initiated by the front end -- which includes downloading new firmware metadata.
Good to know. Why is it a root daemon and not a command/library if other tools are directing it? If I had to guess, so the end user does not have to elevate to superuser to initiate actions?
Yes, mostly that. Depending on local policy, it might be possible to upgrade [only] signed firmware from the correct vendor without authenticating. Downgrade always requires authentication for obvious reasons. Most firmware requires you to be root (some even CAP_SYS_ADMIN) to just enumerate the hardware and read the firmware version.
The other main reasons is that some hardware is really, really slow (like 8 seconds to query a dock PD version, or 12 seconds to query a thunderbolt retimer version) and you can't really build a GUI that can do firmware update operations with potentially minutes of delay for each action. Also, cache invalidation is hard if you can't see the device uevents and usb hotplug events.
Is Slackware a major Linux distribution? There's nothing wrong with Slackware, and no reason why fwupd wouldn't work on that distro -- but it's not one that most people would considered "major" IMHO. There are no GNOME deps on fwupd, although there are a couple of GNOME frontends available -- as there is also a CLI and KDE frontend.
Make sure you open a support ticket asking for LVFS updates -- it's easy to ignore one person, but much harder to ignore hundreds of people asking for the same thing.
With most things I just complain a bit and then go on with my life, but this actually feels like it could work. Samsung does already release some sort of broken Linux livecd for fw updates, seems like LVFS would be easier for everyone.
Samsung actually upload firmware to the LVFS on behalf of a few different OEMs, so they certainly know how. It's a policy decision, not a technical or legal one.
The ColorHug is a colorimeter designed to calibrate screens with an approximately-sRGB gamut. If you're trying to calibrate a wide-gamut screen with a ColorHug it isn't going to work very well. If you need to do anything other than consumer hardware you need to use a spectrophotometer (that can do spectral profiling) rather than a colorimter that's calibrated to different primaries than what it's trying to measure. A spectro is going to cost you at least $300, and a good one is going to cost you somewhat more.
Source: Person that designed the ColorHug hardware.
Everyone needs to characterize (not “calibrate”; that term is highly misleading) their display. The question is just whether you keep the characterization provided by the manufacturer, or measure the display yourself using a hardware device. Either way, the result is a display “profile”, which is basically a lookup table used by software to map color coordinates so that they will appear as expected on the display.
People using Macs certainly do care about ColorSync. That’s the name of the software which uses the display characterization to keep colors looking as expected throughout the operating system and most applications.
In many professional environments the preferred route is to use specialist hardware to send an RGB signal at a high bit rate and do any colour transformation in the monitor hardware.
Using LUTs either at the application or OS level to adjust colour information is a big no-no, although that doesn't stop some people from doing it. You simply don't want to change your colour space[1] until you absolutely have to.
The point of calibrating your monitor (which is a hardware + firmware level problem) is to see how your RGB image will look on a colour space restricted piece of hardware (for example in video this is often 12-bit RGB --> Rec709).
If you have some image data stored with reference to one color space, and you want to convert the data to a different color space (e.g. because you are targeting some particular output device), that is a gamut mapping problem. To learn about different trade-offs involved in choice of gamut mapping algorithms, I recommend Ján Morovič’s monograph, https://www.wiley.com/en-us/Color+Gamut+Mapping-p-9780470030...
Same story if you want to show your image on a display with a different gamut.
Most gamut mapping algorithms used in practice (whether on a display or in software) are actually pretty mediocre in my opinion. It would be possible to do substantially better by writing your own code, at the expense of being a bunch of work. Alas.
P.S. The Wikipedia article about color space (and articles about many other color-related topics) is pretty terrible, but I’ve been too lazy to rewrite it.
Try `man fwupd.conf` for all the options.