One must consider the potential damages that can happen when the default is wrong, as it’s nigh certain that people are going to be careless and not change it.

If the desktop PC has wrong default the performance is bad. Still functional though.

If in case of VM the default is wrong we will read another headline about how N million customers of $company got their personal data leaked.

I think we'll read such headlines regardless of that setting :-P.

I'm actually wondering if there should be some sort of premade "profiles" when it comes to default settings. Debian for example is used in a lot of contexts so perhaps it'd make sense to have a way to ask you what sort of usage you'll do when installing and provide different defaults based on that (not just at the initial installation time but also when installing some package, the default settings would be based on the profile you chose).

It's pretty easy to change a default, so it's completely reasonable for a gaming distro (say, SteamOS) to have different defaults than a server distro (say, CentOS). Most Linux distributions don't ship the kernel in it's default configuration anyway, so this would really only affect those who use the kernel directly from the source.

I can't imagine a desktop PC that is unlikely to ever be used to browse the web. Spectre and simliar mitigations like disabling hyper threading are required to properly isolate javascript.

Defaults should be set for the lowest common denominator. A lay computer user shouldn't have to understand and make decisions upon things like this.

My feeling is current processors are completely fast enough to do what most users need. And it's programming comminity producing bloated slow frameworks that is the problem. Layers of shit are covered over with yet another layer of shit. Needs to stop.

Your desktop PC is regularly running largely unverified code, some of it potentially hostile: all the javascript in your browser.

Lol,

amount of untrusted dll injections to mod, by default, unmoddable games; 3rd party VR tools and drivers; video and audio multiplexer drivers; compatibility drivers for normally unsupported console cameras/controllers etc; ultra demanding last gen console emulators; macro tools that are essentialy keyloggers; anti-cheat daemons running as admin to read memory of other processes;

Windows gaming is wild! I literally sell my soul to gain a few more fps or immersion. Browser js looks almost too innocent in this whole mess.

Except most users aren't modding their PC games. Every user runs untrusted Javascript.

If someone is patching DLLs they can figure out how to enable hyperthreading.

Browsers have mitigations in place, don't they? Aren't they enough, at least on paper?

I can't provide proper citations right now but there has been working exploits of some the latest CPU bugs using just Javascript in a browser as if we're browsing regular websites.

If you could provide citations at some other time that would be great!

Not if hyperthreading is enabled. The point is that it's a hardware flaw, so any software mitigations can be bypassed.

Is there a PoC exploit for current firefox that would work if I set mitigations=off and enable HT on linux, for instance?

Yess, "sane" is context-specific, but it's useful to err on the side of more security and less performance, rather than the other way round.

Exactly. If you need more performance, there's always something you can tune.

It would be especially awesome if this could be enabled at runtime so it could be turned on when thing specific tasks, like rendering or compiling something big. Even better, it would be nice to lock that to specific processes (i.e. enable it on a few cores and lock privileged processes to those cores).

Uh, are you sure of that? My experience has been that x264, for instance, benefits greatly from hyperthreading.

Hyperthreading allows you to queue up additional instructions (in a different thread) that the executor can switch to when it would otherwise be just waiting for the next instruction in the primary thread.

You are correct that x264 does benefit from hyperthreading. According to the devs, the speed increase is about 20% until you are on the veryfast or ultrafast presets, which at this point is usually bottlenecked by decode speed, and not the speed of the encode.

In making my previous claim, I was limiting the concept of 'encoding' to the more old-school definition: lossless compression of media bytestreams. This would include things like HuffYUV, ProRes, etc. But to be fair, these days it is quite likely that even a few of the newer intermediate/mezzanine codecs benefit from hyperthreading. I'd edit my post to clarify but the edit window has passed.