I had a similar issue, low frequency or crashes after gaming for a while, turns out the fan control wasn’t setting the fan correctly and the GPU was overheating. Utilisation didn’t show it, but frequency did.
Restarting the game could be giving it enough time to cool off?
I have a 7800XT on Linux and I want to point out that I still run into their “drm_fec_ready” and “no edid read” bugs every day.
amdgpu is miles ahead of what NVIDIA is offering, but it is still a GPU driver on a second class platform. Do not expect a flawless experience on bleeding edge hardware.
Just finished my third co-op campaign with my partner, I think she may enjoy the game more than I do. It is pretty great having shared hobbies ☺️
deleted by creator
No, I’m saying that when people run into strange bugs, sometimes they put together an issue (like the person behind cve-rs), and sometimes they quietly work around it because they’re busy.
Seeing as I don’t often trawl through issues on the language git, neither really involve notifying me specifically.
My lack of an anecdote does not equate to anecdotal evidence of no issue, just that I haven’t met every rust developer.
Yes, the problems rust is solving are already solved under different constraints. This is not a spicy take.
The world isn’t clamoring to turn a go app into rust specifically for the memory safety they both enjoy.
Systems applications are still almost exclusively written in C & C++, and they absolutely do run into memory bugs. All the time. I work with C almost exclusively for my day job (with shell and rust interspersed), and while tried and tested C programs have far fewer memory bugs than when they were first made, that means the bugs you do find are by their nature more painful to diagnose. Eliminating a whole class of problems in-language is absolutely worth the hype.
If someone did, why would I hear of it?
The code used in cve-rs is not that complicated, and it’s not out of the realm of possibility that somebody would use lifetimes like this if they had just enough knowledge to be dangerous.
I’m as much a rust evangelist as the next guy, but part of having excellent guard rails is loudly pointing out subtle breakages that can cause hard to diagnose issues.
I’m sure the developers are competent, but the reason I care about the design decisions is the same reason the electric brakes on cars don’t interface with its infotainment system; the interface inherently creates opportunities for out of spec behaviour and even if the introduced risk is tiny, the consequence is so bad that it’s worth avoiding.
If you have to have an airbag be controlled by software (ideally the mechanism is physical, like a pull tab), it should be an isolated real time device with monitoring your accelerometer and triggering the airbag be it’s only jobs. If it’s also waiting to hear back from another device about whether your subscription ran out before it starts checking, the risk of failure also has to consider that triggering device.
It can be done perfectly, but it’s software so of course it has bugs.
That information changes none of my issues; if you don’t see the plethora of potential implementation bugs involved, either you don’t code professionally or you shouldn’t be.
Yes, but also from an implementation perspective: if I’m making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:
America isn’t even the most democratic country in the Americas, but that’s clearly not the point they’re making.
If the title was “…end of world democracy” you’d have a point but given how much fascistic rhetoric and policy has increased around the world since trunpism it’s fair to say many countries are following the US lead here.
Sure, but that’s not necessarily a bad thing; if the Linux version is missing useful output that would be bad, but if the DX to Vulkan translation ironed out a performance regression, or the scheduler works better in this scenario, or filesystem access had issues with NTFS it could also cause performance differences in Linux favour.
Blaming the creation of a new law on anybody except the lawmakers is a pretty shit take, but blaming it on 150 year old colonialism is actually infantilistic.
They made a smart call that has probably increased the long term privacy of their users.
People were using port forwarding to host illegal shit, and governments were getting pissed off about it. Mullvad has been able to prove in court that they don’t keep logs, but that’s not a perfect deterrent; a properly motivated government, perhaps if somebody is using Mullvad to host CSAM, might attempt to legally force Mullvad to put logging in and add anti-canary clauses.
Preventing port forwarding keeps customers as consumers rather than hosters, and avoids this issue.
Not necessarily, plenty of good programs written in C89 for example.
With something that is heavily library dependent, having a more recent development stack may mean better maintained libraries but definitely not a sure thing.
Even if they don’t, buying this game still goes in to lining JKRs pockets, something she has explicitly considered as validation of her beliefs.
The makers of the movies, and the publishers of the books also probably didn’t all have anti-trans views, but they don’t have to for JKR to use them to cause harm.
I get it, the devs of a good game don’t deserve to be attached to her, but you’ve got to draw the line somewhere and this is where I’ve chosen to draw mine.
Timberborn was worth buying when they came out in alpha, and have made so much progress since. Super fun game still undergoing frequent solid feature updates.
Lisp is responsible for most of the parts of programming widely considered enjoyable.
Fortran is still often used in some of our most performant libraries.
POSIX shell was one of the most important parts of unix-like systems becoming how they are today, and it’s compatibility is still an invaluable glue for tying programs written in the 90’s to programs written today.