God I hope they crash and burn
God I hope they crash and burn
Lemmy is not your personal ChatGPT instance. Don’t treat it as such.
It’s precisely because their working standards are absolutely absurd and unsustainable, so a LOT of people bail before full vesting. AMZN HR intentionally structures the vesting schedule like this because they have numbers to prove it works out in the company’s favor.
Yeah I have to replace the suction side AC line on mine and the OE part alone is about 350-400 and absolutely impossible to find 💀
smiles contentedly in 2003 1.8T Jetta 5MT
I really don’t think you’re looking at this from the right angle. This isn’t about being lazy. This isn’t about not double checking work.
My point is that statistically speaking, even the double checkers who check the work of the double checkers may, at some point, miss some really subtle, nuanced condition. Colloquially, these often fall under the category of critical zero-day bugs. Having a language that makes it impossible to even compile code that’s vulnerable to whole categories of exploits and bugs is an objective good. I’m a bit mystified why you’re trying to argue that it’s purely a skill/rigor issue.
Case in point: the LN-100 inertial nav unit used in the F-22 had a bug in it that caused the whole system to unrecoverably crash as the first squadron flew over the International Date Line as it was being deployed to Kaneda air base in Japan. The only reason why they didn’t have to ditch in the pacific was that the tanker was still in radio range; they had to be shepherded back to Honolulu by the tanker, and Northrop Grumman flew an engineering team out to (very literally, heh) hotfix the planes on the tarmac, and then they continued on to Kaneda without issue. TLDR: even with systems that enforce extreme rigor (code was developed and tested under DO-178B), mistakes can and do happen. Having a language that guards against that is just one more level of safety, and that’s a good thing.
That’s really not how software development works.
I care a lot about code quality and robustness. But big projects are almost NEVER done solo. Thus, your code is only as strong as the weakest developer on your team.
Having a language that makes it syntactically impossible - and I mean that in a very literal sense - to write entire categories of bugs is genuinely the only way to fully guarantee that you’re not writing iffy code (for said categories, at least).
Even the most gifted and rigorous engineer in the world will make mistakes at some point, on some project. We are humans. We are fallible. We make mistakes. We get distracted. We fuck up. We have things on our mind sometimes. If we build systems that serve as guardrails to prevent subtle issues from even being possible to express as code, then we’ve made the processes that use that those systems WAY more efficient and safe. Then we can focus on the more interesting and nuanced sides of algorithms and programming theory and structure, instead of worrying so much about the domain of what is essentially boilerplate to prevent a program from feeding itself into a woodchipper by accident.
He’s grumpy that she won’t see any additional jokes he makes about impregnating her
Not to mention, iirc you should get a bit of a perf bump for the GPU due to AMD’s Infinity Cache, so long as you roll with (iirc) Zen2+ and RDNA2+
Pretty sure he’s doing this simply because he doesn’t like how many people have blocked him personally
Again: hard to differentiate all those different bots, because you have to trust that they are what they say they are, and they often are not
The hard part is reliably detecting the bots
That all makes sense - I guess at this point, I’m simply trying to offer some constructive criticism about how to present nuanced problems that involve both hardware and software gremlins in a way that you’ll get the most productive conversation and interaction from the user base here.
Heh, we’re still on the X-Y problem to a degree.
I’d recommend another top-level reply to your post, or a new post, describing precisely how your hardware and ZFS pools are set up, alongside a description of the firmware/stability issues you’re seeing, and solutions you’ve tried already. We’re a bit far down a comment chain at the moment, so you’ll probably get more engagement that way. Not trying to be an ass - this actually sounds like an interesting (and, I’m sure, obnoxious) problem. Putting all the cards on the table will help people give you a more complete answer more quickly.
A bit of searching brought me here - would this suit your purposes?
Edit: amusingly, one of the replies to the original question also points out that this is yet another classical example of the X-Y problem
You are evidently missing the entire point of what the X-Y problem is.
What are you ACTUALLY trying to accomplish here? Why do (think) you need to throttle your USB speed to 50%?
Uh… are you not aware of the catastrophically bad lithography issues Intel has had lately across both the 13th and 14th gen, and the subsequent ass-tier fashion in which they handled it?
Do not buy a 13th or 14th gen Intel CPU.
lol for real though if I went to work and someone sent me a bill for it, I’d probably just set work on fire and let that whole thing work itself out. Iirc, that was the traditional remedy before unions were a thing.
I anticipate the used value for those gens is going to drop quicker than a Mercedes CL65AMG