mainde

At my workplace we've used many languages over the years (C#, Python, Go) and Go teams are the ones that by far do the least amount of yak shaving and have the most intelligible codebases.

The issue with things that client must not do is that they might still do them, and users don't care whose fault it is. It's important to have auxilliary mechanisms to mitigate these.

I've been in this situation, a clientside bug meant that different requests arrived with the same idempotency key.

In my case, updating the client would have taken weeks, in the best case scenario. Updating the backend to check for a matching request body would have taken minutes, maybe hours.

It took me a surprising amount of arguing to convince people that, even if it was a clientside bug, we couldn't let users suffer for weeks in name of "correctness".

I had a hunch it was power related because my PSU was nearly 10 years old and probably with just barely enough wattage. I bought a new one and all the buzzing went away.

IIRC when I was researching possible causes, beefy Ryzen CPUs were the most commonly mentioned in various forums and reddit threads.

In fact, I suspect that most hate firearm-related violence and have worked to stop/curb it, and were opposed by Kirk who undeniably unfairly got a taste of his own medicine.

Of course two wrongs don't make one right, and people can be more classy than this, but it's a totally understandable sentiment and response.

There isn't a scenario where, at scale, someone can offer a product that respects consumer rights and is successful, because it's too profitable to not respect consumer rights just like it wasn't in many other cases.

While for sure there's a lot of signal and value in monitoring auth rates per BIN per payload, flipping bits can be extremely disruptive and counterproductive. From doing the wrong operation to being fined by the schemes, it's a lot of risk for not a lot of gain when these fields can be tuned ad-hoc for the few card issuers that deviate from the standard/norm.

For sure the better dev team won there, but on the long run, especially once CUDA becomes the only way to do "professional real world work", I'd like the hardware company to sell the hardware and the software company to sell the software, to avoid a dominant market position that hurts consumers and the industry, which is forced to pay premiums to monopolists.

I'm a bigger fan of the approach that AMD had over the years, their software frameworks are open and hardware agnostic, which resulted in improvements for everyone and not just their customers (e.g. Vulkan which came from Mantle, games with FSR or TressFX run well on all hardware, those with DLSS or Hairworks don't) and enable competition that brings prices down.

IMHO it's mainly due to the popularity of the service/product. The concentration of bad actors and the vastness of the audience/userbase make the difference. If Signal was used in the same way, it would get the same attention.

Ultimately we don't know if they QA'd the changes at all, if this was data corruption in production, or anything really. What we know for sure is that they didn't have a good story for rollbacks and enforced staggered rollouts.

On a serious note, we have no way of knowing whether their update passed some QA or not, likely it hasn't, but we don't know. Regardless, the post you're replying to, IMHO, correctly makes the point that no matter how good your QA is: it will not catch everything. When something slips, you are going to need good observability and staggered, gradual, rollbackable, rollouts.

Ultimately, unless it's a nuclear power plant or something mission critical with no redundancy, I don't care if it passes QA, I care that it doesn't cause damage in production.

Had this been halted after bricking 10, 100, 1.000, 10.000, heck, even 100.000 machines or a whopping 1.000.000 machines, it would have barely made it outside of the tech circle news.

IHMO the experience, the pragmatism and the soft skills needed for a successful/productive informal architectural meeting are too rare for this solution to work consistently.

Personally I've abandoned all hope and interest in software architecture, while on paper it makes a lot of sense, in practice (at least in what I do) it just enables way too many people to throw imaginary problems in the mix, distracting everyone from what matters with something that may eventually be a concern once/if a system hits a top-1% level of criticality/scale.

In my experience this is normally due to either how the card machine provider has set up the device or due to the lack of certification of the mobile wallet functionality on the "acquirer" backend ("host") that speaks to the card schemes.

It's annoyingly tricky to get the end-to-end transaction working properly across all schemes, all payment methods and devices. Different card schemes support different "payment kernel" parameters and have different certification requirements.

It could also be an attempt to save money on transaction fees, amex is generally significantly more expensive for merchants.

>Note that that’s a best-of-five measurement, so I’m allowing the file to be cached. Who knows whether Linux will allow all 13GB to be kept in disk cache, though presumably it does, because the first time it took closer to 6 seconds.

This is a protocol/product problem, it's wild that to make a payment all the crown jewels need to be put on the wire. It's about time that payment devices and the whole ecosystem adopts some sensible cryptography that, at minimum allows signing payment requests, and ideally keeps its keys private.

Although this whole problem is kind of already solved by 3DS2, albeit not in a great way.

You don't have to reach pro levels, it often only takes small assists to turn a balanced game on its head, ruining someone's experience with a game. Repeat often enough and the userbase will leave, feeling cheated or at least demoralised for being unable to compete or improve.

And allowing machine-assists, thus leveling the playing field, turns the game into a completely different one that is (imho) drastically less fun whoever may not be interested in (or may be unable to) running/coding their bot.

[1] Unless we're talking about captcha solving competitions, for now, maybe. :)

About two years ago, pre-adblocking crackdown, I was having a great time with YouTube and I considered buying the premium subscription because I really liked the product.

Then the number of ads and their frequency changed massively, ruining the whole experience for me, the premium subscription went from feeling like "something I want because of perceived value" to "something I now need because YouTube has been made unusable in an attempt to coerce me into paying".

I went from checking out the prices and planning the purchase to blocking the whole domain on my pihole for all devices except my workstation.

I was also very disappointed by the subscription model: no yearly plan, no way to bundle it with the Google One subscription that I already pay for, the price of a family plan Vs individual subscription is predatory and anti-consumer (325% higher per individual).

I would imagine DNS plays quite a key role in the internal operations of literally everything in a public cloud but I could be wrong.

Not really a "configurable option" but very close to it, it achieves the same goal and has been released along with the Backspace modification.