I doubt that. While the attack was possible on large hosting providers, utilizing the same on workstations or hardmetal and actually get important data was basically impossible.

It had to be fixed, but your thesis that anyone was actually owned by these security issues because they didn't want to apply the mitigation rounds to at most 0.0% with an infinite amount of zeros before a 1.

Guix will never prevent you from doing what you want with your hardware. Nor will it give you software that is not properly free (as in freedom).

The "nonguix" channel mentioned in the article does have Intel and AMD microcode for users who want it. This is similar to Debian, where you have to opt-in by enabling the "nonfree" repository and "apt install" the microcode package corresponding to your CPU.

Good to know, but still

> where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode

Is not ok

I believe that argument is based on the same FUD that I addressed here:

https://news.ycombinator.com/item?id=29290087

...at least, I don't see any such code in the actual deblobbing script: https://linux-libre.fsfla.org/pub/linux-libre/releases/5.15....

edit: since you called linux-libre a "fork", I feel compelled to point out that Linux-Libre is just the vanilla Linux kernel with that script applied. No more, no less.

I'm sorry, but this (and a bunch of other similar blocks) seem pretty intentional...

    # Do no recommend non-Free microcode update.
    announce X86_LOCAL_APIC - Undocumented
    clean_blob arch/x86/kernel/apic/apic.c
    clean_kconfig arch/x86/Kconfig X86_LOCAL_APIC
    clean_mk CONFIG_X86_LOCAL_APIC arch/x86/kernel/apic/Makefile

If the kernel can't load it without code changes and recompilation, due to the de-blobbing process, it doesn't make much sense to recommend to users that they load it.

You can often also update your microcode by updating your BIOS/firmware.

That's a good point! Adjusting the message to direct people down that route rather than simply removing it seems like a good idea.

Sorry, but you are wrong. GNU people won't run nonfree JS at all.

LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run.

At that point why just not power off their machines? That 3 websites that has “free js” is almost as useless as a brick. Also, free software in itself never protected against security vulnerabilities, many eyes is a fallacy.

You are really wrong, a lot of services (specially news) work either without JS or have a libre alternative, such as Twitter/Nitter, or Reddit/Teddit.

I use NoScript and I find very few sites that are really broken if I don't enable JS.

Your and mine definition of very few sites must be different than.

Can you buy anything at all on the internet?

Amazon not so long ago worked without JS, or Ebay, I can't remember.

"LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run."

If attackers who cannot add a comment to their exploit are in your threat model.

Personally, I've been using a browser extension that blocks JS unless it has a comment reading

> This code is NOT evil or malicious!

at the top. Haven't been hacked yet!

> There is no attack when no code is being run.

https://9to5mac.com/2021/03/11/browser-based-attack-affects-...

Turns out you don't need Turing completeness to perform microarchitectural side channel attacks. This is yet another way in which the "all my software is free, therefore I am safe from attacks" fallacy breaks down.

Nevermind that, as pointed out by other replies, LibreJS provides zero security. It relies on scripts voluntarily declaring that they're freely licensed, and if they do, they're allowed to run. The extension doesn't care whether the script is malicious or not.

Dillo has a nice CSS-less rendering. Also, Links+.

I am still safe.