IMHO it's more: fix problems, or at least mitigate them, regardless whose problem it is.
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".
Well.. it was ~6 years and ~10 billion payments ago, the clients have been fixed but the "hack" is still there, it has caused no harm as far as I can tell. Worst case scenario it's useless, best case scenario it prevents regressions.
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.
That it may be there or not doesn't mean it "caused no harm". It sounds like yet another carbuncle added in haste and then never fixed properly, leading to 6 years of fear of touching it.
If it's truly intended, it needs to be part of the official spec, with a robust justification of why it's there at all. Neither server nor client ought to have unnecessary and undocumented things "just in case", because that breeds a culture of uncertainty.
If you fear client regressions, make it a mandatory part of the client's test suite. You control the client, right?
> 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.
Then at least admit you’re just hacking quickly fixes, creating technical debt, and not fixing the actual problem.
I agree with your point that business interest is most important, I disagree that it’s the technically most appropriate solution.
The whole article is proclaiming that this is a technical problem about idempotency being hard, while it’s not. The whole premise of client side bugs must be resolved backend side as the correct solution is incorrect.
Eh, idk, I wouldn't classify these fixes as hacks nor as technical debt. It's labels that only work from a partial perspective. IMHO a solution that expects perfect compliance is not really complete, it's not good enough to put all the burden on the client, idempotency keys are part of the solution, but not the solution. So, in this sense I would say it is a technical problem.
It kinda works both ways, just yesterday I tried to play the Linux native version of 8bit.runner and it didn't work, I had to install the Windows (beta) version and run it through proton.
Funny story: I use Anki (the flashcard program), and I run it on my NixOS laptop. There is a NixOS/nixpkgs package for Anki. It doesn't work. You know how I run Anki, which has a native GNU/Linux version and even an actual nixpkgs package, on my GNU/Linux NixOS laptop? Yeah, I run AnkiDroid, the Android version, through Waydroid. Because the Android version works.
Anki seems to be a habitual offender, I was never able to install it reproducibly and in an obvious way on several distros and always ended up building it from source.
no, in the given context and dogma, it's just 'persons' all the way down ... and up ....
I'm just annoyed the HN kind is too retarded, which might be age related or not, to throw a better narrative at the rest of us.
You see, it's all "laissez faire" only until it isn't ... and that's becoming a little too obvious to the wrong people ... who are not among the staff but among those who sense and communicate opportunity ...
the last time something similar played out, nobody--the least the left or the greens or anyone considering themselves a fucking democrat or feynman-style anarchist--noticed the fake/posing devil in the details deliberately put on stage as a show of "pwowa" ... ... by those who only held it over multiple but rather individual instances ... the narrative which mostly left them out, .... "almost" went worse ... than history
When I upgraded my PC to the same CPU, I had the same problem of crackling/buzzing speakers on my USB DAC (externally powered, but from the same strip/outlet) when the system was under load.
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.
This is also my experience, it's not necessarily Apple fans, people just get used to some garbage but necessary workflow/ritual and forget they are doing it.
I witnessed multiple colleagues and friends, who are avid and experienced MacOS users, struggle with basic tasks like ..finding the window of an open application after it was minimised, fullscreening applications, screensharing. Yet, somehow, none of that registered for them and their experience was still reported as flawless.
It's being posted as a gotcha because he fought against firearm control and he was killed with a firearm. His death, like many firearm-related others, would have been significantly less likely to occur if firearm possession was properly regulated and curbed, like it is in many other countries.
>I understand your point. But even if he said otherwise would still be posting this?
>Point is it just seems like a giant gotcha and it’s not fair
Who says life is fair? Was life fair for those school kids in Minnesota? The kids murdered in Uvalde? And on and on and on. Where's the fairness for them?
And why is it more important for Kirk to be treated fairly than those children? That's not a rhetorical question.
I'm not condoning murder. Full stop.
Whoever killed Kirk -- for whatever reason(s) -- should be prosecuted to the full extent of the law by the state of Utah.
To be clear, I didn't know Kirk or anyone in his family. I don't celebrate his death either.
But while it's sad, and even tragic, why is his death more important or relevant than the thousands of other deaths by gun in the US just this year?
All that said, there is a certain irony here -- as he explicitly allowed for exactly this outcome as acceptable in support of the Second Amendment.
And if, as he explicitly said, a certain number of deaths are acceptable (I don't agree, BTW) in support of a broad interpretation of the Second Amendment, why isn't his death also an unfortunate, but necessary offshoot of that?
One could argue that advocating against firearm control and regulation has resulted in significantly increased societal harm, which could also be identified as not fair, if not even evil/hateful, especially from those who have directly suffered from it.
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.
None of my claims disagree with what you just said. People posting the "gotcha" also likely don't disagree with you.
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.
IMHO the incentives are disproportionately in favour of everyone doing something that hurts consumers (= "something that I don't like"), thus regulation in favour of consumer rights is appropriate.
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.
I would be very surprised if bit flipping and ML were really used here, do you have any source?
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.
Find it strange to focus on what that article says when 10 years ago we were using CUDA in a professional context for real world work and AMD didn't have anything competitive at all in the field till very recently.
If the tech was comparable maybe we could entertain the idea but Nvidia was just so absurdly ahead in tooling than AMD that the better dev team won.
Yes, the article focuses on GPP, which is more on the gaming side rather than the compute side. CUDA was clearly ahead and I think AMD still hasn't quite caught up, however, call me old fashioned but I don't like arbitrarily hardware-locked proprietay software frameworks like CUDA (and the same applies for all other nvidia stuff imho in the same category: rtx, dlss, gsync, etc).
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.
>"I want to be clear: best practice, ideologically-pure end-to-end apps like Signal absolutely face the same ratchet. What I’m mostly trying to understand here is why Telegram and Blackberry get more publicy targeted."
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.
There are claims that Signal has already been compromised by the Five Eyes Intel Agencies, albeit through bribery rather than the overt coercion we see here. The key change is that Signal can no longer guarantee end-to-end encryption based on a passphrase tied to the app itself, and known only to the user.
For a while I wanted Signal to get popular so I wouldn't have to use other less private and secure apps, but now... I use it with close friends and close family... and that's it. I don't even mention it to most... I fear that popularity would bring more attention to the app and, with it, political and legal issues.
No, although it used (not sure if it still does) to encourage people to enable backups. On Android I believe the default was Google Drive, so you'd have people send their chats to Google in plain text.
iMessages is another example of a secure service that lets users "break" encryption. As soon we enable cloud features for it to work across devices, the key is uploaded to iCloud, essentially making chats plain text to Apple.
The main "backdoor" to Signal is that having access to the phone can leak all of Signal's data. If the phone OS is backdoored, then Signal is already compromised. Anyway, the point is not to make it impossible to exfiltrate data, but to make it as hard as possible.
Yeah, I almost put in a sentence or two acknowledging that -- as well as the fact that Durov is far more unprotected by a state from a geopolitical point of view. Would the French police arrest Mark Zuckerberg or another Facebook employee? It's not hard and fast (Italian and Brazilian courts have both put warrants out for the arrest of executives at major foreign tech companies), but it surely factors into how much political capital one would burn to pursue the case.
I can't find a description of an arrest warrant, but the case I was thinking of was this one from 2010 where three Google execs were found guilty and given suspended jail sentenced by an Italian court. https://www.theguardian.com/technology/2010/feb/24/google-vi...
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".