Your card limit gets checked on every transaction. There doesn't seem to be a technical reason why information flow back to me should be limited in any way. If the extra layer fails to work the transaction fails to pass.
> Your card limit gets checked on every transaction.
Nope. The merchant can choose the level of verification - in some cases, like copying the card with an imprinter [1] or running phone transactions (yes, that is possible - it's called MOTO [2]), it's obviously impossible to check card limits.
Downside of CNP transactions is, the merchant is fully liable for anything from fraud over chargebacks to exceeding limits.
And then you got card-present transactions but the network connectivity is down for whatever reasons... been a while since I messed with that, but at least for German cards you could configure the terminal to store the account details for later submission when connectivity was restored.
I remember being charged after a while when paying for bus/metro tickets in some places, I think those machines process transactions by batches or something.
Your brain does. It's not _one_ computer. It's dozens some interconnected and synchronized to others some with entirely independent control. It's why we have seizures, why optical illusions exist, and why you flinch when something moves at you in your peripheral vision.
What I love about this article is it's actual engineering work on an existing code base. It doesn't seek to just replace things or swap libraries in an effort to be marginally faster. It digs into the actual code and seeks to genuinely improve it not only for speed but for efficiency. This simply does not get done enough in modern projects.
I wonder if it was done more regularly would we even end up with libraries like simdjson or oj in the first place? The problem domain simply isn't _that_ hard.
Bear in mind that: the author is part of the ruby core team; json is a standard lib gem; the repo from the json gem was in the original author namespace; the repo had no activity for more than a year, despite several quality MRs.
It took some time to track and get the original author to migrate it to the ruby team namespace.
While I'm glad they to all this trouble, there's only a few who could pull this off. Everyone else would flock to or build a narrative.
Doesn't the bottom of this announcement describe a previous rule that was announced in January 2024 and then implemented in March 2024? Interesting that rules process was far more rapid than this one.
Also worth noting that today's rules, 89 FR 7456, and the previous one, 89 FR 103054, both derived from the same NPRM. Apparently, based on feedback they thought some parts of the rules needed more work than others and finalized them in two parts.
So a different related rule started its process awhile back and a second rule was in the works concurrently. Is the USG only allowed to do one thing at a time?
The comment period for this rule ended last year to give you an idea of how long this has at least been in the works. All of this information is rapidly found via the submitted url at the top of the page.
It's the same question. What decides when a long process and comment period is required and when it isn't? Why does this agency have such variable performance when it comes to similar rulings?
It's a visa. The whole point is that it's not permanent and you are ultimately expected to return home permanently. You may also be asked to leave at any time. It's reasonable for the host nation to want to ensure that outcome is still available and that someone hasn't actually fully emigrated here with no options for return.
Ultimately it's known to anyone who applies for a visa that this will be the requirement, and so, if they don't want the economic opportunity of working in the US, they're free to avoid the stress and just stay in their home nation.
> It's a visa. The whole point is that it's not permanent and you are ultimately expected to return home permanently
probably do not have to tell you this but not all visas are created equal... this one is particular is a dual-intent visa so what you are saying applies to SOME visas, just not this one :)
No, this was post 9/11. It has nothing to do with immigration policy. The collective jerking after 9/11 led to many bad policies, including this one. Biden half assedly tried to go back to the pre 9/11 state of "stateside renewal" but it went nowhere.
The "support elements" on the mainframe, which are just a laptop connected to some internal buses and power controls, did run OS/2 for many years. You could IPL the machine right from the Warp desktop. It was neat.
They also continued VM with VM/370, VM/ESA and z/VM operating systems which are equally rock solid systems. Aside from these IBM did actually go big on Intel systems but they got completely blindsided by clone manufacturers and entirely failed to see what cloud infrastructure would do to their impressive mainframe lineups.
If you have debilitating diabetes that has failed to respond to changes in exercise and diet. If your taking the drug as some type of "weight loss short cut" you should possibly reconsider that position.
In terms of outcome, it maybe a tolerable risk, but anything that flat out doubles the risk ratio is fairly concerning; in particular, where the mechanisms are not well understood.
All medications increases the risks of side effects, but they are prescribed because the benifits outweigh the downsides - even if little is known about their mechanism.
> but they are prescribed because the benifits outweigh the downsides
Some are. Some are simply prescribed because the patient asks for them.
> even if little is known about their mechanism.
I wouldn't take it unless my condition was immediately life threatening and there were no other medications available. There are very few classes of treatment that fall within these parameters.
