In regards to E3-v3, nothing at all.
I was primarily concerned about the Super Micro board but it is good to know that those Xeons are fine. I will be getting a Haswell Refresh chip just like your 1241, so there shouldn't be any issues with errata. I checked the product page/Quick Reference and the Super Micro board seems to have a standard ATX power connector so that should not be an issue at least.
I am hoping that the sale of my 1600 AF+Biostar X470GTQ (and perhaps WX2100 and DDR4 too) can fund the purchase of a new (well, to me) enterprise HDD to replace my UltraStar 7K3000 as my main HDD and a Noctua case fan to replace the noisy (and probably malfunctioning) case fan that came with my Fractal Design case.
It's really not that simple. I don't really want to be going into it again, because...
...every modern browser patched that problem and all of it's variants. Browsers are NOT a valid attack vector. Even with a vulnerable browser, direct user interaction was required to install a payload. For anyone who has any knowledge of this, they will not be blindly clicking on crap or visiting "iffy" sites.
That's a fair point, but again, the user has to actively download and install the payload. Browsers are configured to block anything that would otherwise be presented to the user. Adblockers and JS managers provide further protection.
Put simply, those patches are completely redundant at this time and can safely be disabled. And if you knew me better and how much of a security boot-stomper I am, you could better appreciate this statement.
I have no idea where you are getting this idea that users need to "actively download and install the payload". Any JavaScript on a web page is run by default when a page is loaded (or it is triggered by something else, which the web page (or ad) 'decides'). We are not talking about some kind of Java or Flash/Adobe AIR applet or something that you need to click to run or that needs to be downloaded and executed by some local runtime manually. "Adblockers and JS managers" do not just provide "further protection". On the contrary, they are necessary to override the dangerous default behavior/configuration of (most/popular) browsers.
Also, they are not "patches" that solve the problem. They are mitigations; they mitigate the risk, they do not eliminate it. You should look at this as browser vendors doing their part (to the degree that in their own eyes is reasonable, when balanced with other concerns such as performance and user experience) to make the best of a bad situation.
I am sure that you take security very seriously and have a great breadth of knowledge when it comes IT/system administration etc but I do not think you have an adequate understanding of this particular niche topic. I will be the first to admit that I am far from an expert when it comes transient execution vulnerabilities, JavaScript or browsers in general but I do have a tiny bit of experience creating web applications with JavaScript and I have learned a lot the last couple of years about how invasive JavaScript has become (in particular when it comes to tracking). Additionally, using OpenBSD as my main desktop OS for half a year and being a part of that community taught me a lot about security and I try to at least keep up on a surface level with the latest about these transient execution vulnerabilities.
As an aside I was reading an overview paper by one of the security researchers involved in discovering these vulnerabilities recently (I will have to look it up again and finish it in the near future) and even though I do not understand at least half of what they are talking about (my rudimentary understanding of how CPUs work from a college computer architecture/assembly language programming course does not really cut it), I still learned a fair amount about the basic concepts behind these vulnerabilities (and there are actually significant differences between different classes of them).