Listing blobs with vrms in my favorite distro outputs this:

Non-free packages installed on peppermint

amd64-microcode Processor microcode firmware for AMD CPUs
fonts-ubuntu sans-serif font set from Ubuntu
intel-microcode Processor microcode firmware for Intel CPUs
nemo-dropbox Dropbox integration for Nemo
ttf-ubuntu-font-family sans-serif font set from Ubuntu (transitional package)

Contrib packages installed on peppermint

flashplugin-installer Adobe Flash Player plugin installer
iucode-tool Intel processor microcode tool

CPU is by Intel, why are there both the Intel and the AMD microcode packages installed?

Why do you keep carrying on about "blob"s ?. If you are so concerned about FOSS, why are you installing non-free then querying without apparently doing any research.

Off topic but peppermint was installed ages ago in a VM and it now works with Secure Boot as a host too whereas all FOSS Debian derivatives I tried do not. Debian does, but on the system of interest it took hours of research and experimentation to discover that mmx64.efi had to be copied across from a Ubuntu derivative. On topic: CPU microcode packages are supposed to offer security updates so one should not dump them without careful consideration. So what's the deal with AMD being present in an Intel system?

Probably because it's less trouble to install both than to check which one you need. My PCLinuxOS installed an Nvidia driver on my system, probably for the same reason. What other non-free items did I get? I neither know nor care!

1 members found this post helpful.

Maybe some clues can be found here.

https://answers.microsoft.com/en-us/...e-a1b4c48690f1

@Ulysses: If you have a kernel-firmware package installed, or installed the kernel firmware, you've a great selection of blobs that never run. That package has binary firmware for everything. Most cards have some intelligence in them, so theoretically yes, they could be damaging if run, but actually no they won't ever be run, unless you install the relevant device.

If you don't have firmware installed, that's why your cpu is open to attack and none of your peripherals work. It's in a manufacturer's interest to make sure their firmware is spot on to maximize performance and security. A scare will cost them sales. Look at Huawei .

1 members found this post helpful.

Back in my Tru64 days... the OS patch utility was smart enough to figure out that some of the 600+ patches distributed every quarter might not pertain to the particular flavor of hardware that the patches were being installed on. Fortunately, for the authors of the OS's patch utility, there were a limited number of hardware configuration they might have to deal with when deciding whether a particular patch was appropriate for a given system: "Should this updated driver for a specific fibre-channel controller be installed? Nope. It's not present in the configuration." And I knew that only a subset of the patches were going to be installed before beginning the process. (How? Release notes.)

Now compare that to the seemingly infinite number of different hardware configurations that might be present in an Intel- or AMD-based PC system and it's understandable why additional bits of software get installed that are never going to be used. I recently watched 'zypper' pull down firmware for all sorts of wireless network chipsets though I knew that only one of them was needed.

I rather miss the "There are updates/patches. Read all about 'em in the attached PDF" process. A means of getting those release notes so they could be read before clicking "Install all patches" would be great. The only heads-up I know of today -- other than subscribing to a zillion developer mailing lists -- is via Linux Weekly News and those are limited to security-related patches.

Cheers...