For server CPUs there's not a similar problem or they realize server purchasers may be less willing to tolerate it? I'm not all that thrilled with the prospect of buying Intels especially when wondering about waiting to 5 year out replacement compared to a few generations ago, but AMD server choices can be a bit limited and I'm not really sure how to evaluate if there may be increasing surprises more across the board.
Are you talking about Xeon Scalable? Although they share the same core design as the desktop counterpart (Xeon Scalable 4th Gen shares the same Golden Cove as 12th Gen, Xeon Scalable 5th Gen shares the same Raptor Cove as 13th/14th Gen), they're very different from the desktop counterpart (monolithic vs tile/EMIB-based, ring bus vs mesh, power gate vs FIVR), and often running in a more conservative configuration (lower max clock, more conservative V/F curves, etc.). There has been a rumor about Xeon Scalable 5th Gen having the same issue, but it's more of a gossip rather than a data point.
The issue does happen with desktop chips that are being used in a server context when pairing with workstation chipset such as W680. However, there haven't been any reports of Xeon E-2400/E-3400 (which is essentially a desktop chip repurposed as a server) with C266 having these issues, though it may be because there hasn't been a large deployment of these chips on the server just yet (or even if there are, it's still too early to tell).
Do note that even without this particular issue, Xeon Scalable 4th Gen (Sapphire Rapids) is not a good chip (speaking from experience, I'm running w-3495x). It has plenty of issues such as slow clock ramp, high latency, high idle power draw, and the list goes on. While Xeon Scalable 5th Gen (Emerald Rapids) seems to have fixed most of these issues, Zen 4 EPYC is still a much better choice.
It was really a bit fortunate that the employee pilot quit.. As much of a mess as it was, it was a fair trolley problem trade, and if the owner/engineer who ignored expert opinion was not among the victims there would have been a lot more social friction over the matter of manslaughter, surviving to reframe a misfortune, etc.
Requiring crowdstrike or similar to be able to do business isn't a requirement from government, it is from exactly this industry consensus where business, insurance, etc, gets consulting advice on what best practices exist and should be required.
We have to do precisely what we've done because it isn't working?
Ah yes, signalling on what we would have done.. Well, I'd totally have delivered panels if Convolt and Chinese companies were banned a few years ago. Make the market exclusive to me and I'll look into what the profit will be if I start producing them. I'll also be sure to prevent the domestic installer industry from taking advantage of low prices, only a small number of authorized ones will pay enough kick backs to have any availability. But its not all economic loss, the repair industry will need to be a lot better with my exclusive US panels.
I don't see the point. Your work is going fine, so why not look for a hobby that you enjoy instead of making a burden out of finding a work related hobby? There are plenty of non coding things to do and their differences from your day job may bring new ideas and perspective.
When ypu are talking web facing client full scale browser, C++ is impossible to secure as well as a safer language and most safer languages are impossible to optimize as well as C++. So rust is not so much exciting as not horrifying.
Yes, I know the argument and it has some merit. I just don't find it very persuasive, so a thing being implemented in Rust doesn't make me any more or less willing to use it. To each their own.
"Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start using the language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code...": https://arxiv.org/abs/2003.03296
As I said, there is some merit to the argument. I do think that it's stretched a bit far, but that's neither here nor there. In any case, I'm not saying I'm opposed to applications being written in Rust. Use the language that suits your needs the best. All I'm saying is that the fact that something is implemented in Rust is not really a factor (either way) when I'm deciding whether or not to use a particular piece of software.
> Rust is not really a factor (either way) when I'm deciding whether or not to use a particular piece of software.
For a five function calculator or alarm clock app, sure. Browsers have an immense attack surface, handle incredible amounts of untrusted data in hundreds of different formats, and are actively exploited regularly.
