Rosetta 2 doesn't emulate interrupts (they're not visible to userspace components)
It does have to emulate signals but its moderately easy to handle those by deferring them to "safe" points where all architectural state is known
171 karma · joined December 8, 2019
It does have to emulate signals but its moderately easy to handle those by deferring them to "safe" points where all architectural state is known
The bank originates a mortgage to someone. It uses (some of) your $10k to give cash to the customer getting the mortgage, and the customer then uses that cash to buy the house.
For whatever reason, a bank run happens, i.e. everyone comes to make a withdrawal all at once
You try to withdraw your $10,000. The problem is that everyone wants cash, not shares of houses, but the bank only has so much cash.
The bank is good for your $10k, but not on the timeframe you want it. The bank is _illiquid_, but _insolvent_.
The bank will try and sell it's mortgages to someone else for the money, but if it tries to do this all at once it will likely end up selling them at prices that are below par. In that case the bank might end up with less assets than liabilities; this makes the bank _insolvent_.
In a deposit insurance scheme, the government takes over the bank, pays out to customers, and services the loans. The government can do this because it can easily create liquidity. Generally in recent history the government still makes a profit when it reduces an illiquid bank
https://gitlab.freedesktop.org/xorg/xserver/-/tree/master/hw...
"Overseas ACH" isn't a thing; anything which looks like it is fronted by a US institution
With UDP, TCP and SCTP, if you need to change ports in the header, then you need to update the checksum. The traditional TCP/UDP checksum is kinda crap, but this works in its favour here, because you can just perform a corresponding and easy adjustment of the header.
SCTP protects packets with a strong CRC32C checksum. This is on the whole a good thing, but you can't do the twiddle trick with CRC32C. If you're rewriting ports, you need to recalculate the checksum over the entire packet.
This means that linerate SCTP NAT accelerators have never existed. On the whole, what SCTP NATs exist only do address translation: If two people try to establish outbound SCTP connections from the same source port, the second person's connection just gets dropped by the NAT.
It was very underwhelming.
(I tend to think the home office is terrible and inhumane and that in general immigration policies are terrible and inhumane, but the above is in the context of those)
Regardless, there is no such thing as people "disqualified from banking". The CMA9 banks (who are required to offer basic bank accounts) have fairly limited leeway to decline accounts to someone (though having defrauded that particular bank is one valid reason why)
Despite that this displeases the networks, businesses are allowed to elect to only accept a subset of card categories (i.e. they may decide they accept Debit Mastercard only, not Mastercard Credit or business cards). That said, honor all card rules _within_ a given category have been found enforcible (including that e.g. a merchant can't decide they accept Visa Debit, Debit Mastercard and Mastercard Credit but not Visa Credit - Visa are allowed to say "If you accept Visa Debit and Mastercard Credit, you must also accept Visa Credit")
Processors/Terminal providers will add their own margin on top of these, of course (interchange fees are entirely remitted to the card isssuer)
I think this differs from person to person. Cash for me requires more self-discipline, because I don't automatically get a log of where the money has gone and so in some ways it just disappears without me having an idea where
(Sure, my bank statement can't tell me what I bought at a given shop, but knowing I spent €X at a shop is a good memory jog)
(There is a deep irony here that mDNS, LLMNR and NBNS all use the DNS packet format on the wire!)
Sometimes the argument given is that these resolvers should be implemented via a service which listens on localhost, with resolv.conf pointed at. Unfortunately, this assumes you can translate the responses from querying all of these protocols to DNS packets. This isn't true: There's no way to encode an IPv6 address scope in a DNS packet (because they're machine-local considerations). In mDNS and LLMNR, this isn't a problem because the scope is implicit - take it from the sockaddr_in6 of the received packet. This means link local addressing doesn't work.
(n.b. gethostbyname can't support link local addressing either, but getaddrinfo can. This is one reason for gethostbyname's deprecation in favor of the latter API)
This makes trades move quickly, which speeds up price discovery. This is good for market health.
Market makers make their money on the difference between the buy-sell spread. Of course, this is a bet: if the market moves against them, they can lose money on this. Often a market has one or more officially designated market makers who are paid to _always_ have a certain number of both buy and sell offers on the market to ensure that there is always liquidity. The payments help cover their risk
(These payments are often also materialized in the form of a "takers fee", i.e. a surcharge you pay whenever you place an order into the market which can be immediately filled)
TL;DR: They're a warehouse which will always buy and sell some product, except when talking futures we're talking wagons full of nickel 1 month from now and so the warehouse doesn't physically exist
The immediate ramp to the $9000 cap was designed to alleviate this. Yes, it's boneheaded, but I imagine any other manual override of the algorithm would have taken longer to get people to agree to.
The conclusion I keep coming to is that so many free market maximalists are absolutely terrible at designing markets.
Not really; pretty much every UEFI driver shuts itself down when you call ExitBootServices, which is necessary before you can do virtual addressing (as required by every OS)
(My memory is fuzzy but I think the one exception is UNDI/the network driver, but you never want to use UNDI to drive your network card except out of desparation)
Come on, this is just incomparable. Protein is satiating.
A protein bar is a very different experience from a Snickers
I'm sorry, but this is just not true of at least the Itanium exception handling system used by Linux, macOS, etc on most architectures.
It does make the exception handling data quite large and throwing extra slow, of course.
It's an ELF binary; all that's relevant are the program/segment headers and dynamic table. The section headers and non-dynamic symbol table are just there for orthogonality and to make the debugger's life a little easier (and the debugger would much prefer DWARF data and doesn't care about the section headers, tbh)
No, fundamentally it is
If I'm Evil Social Media Company and I want to leak your secrets to someone (the NSA, KGB, whatever), I could
1. Send your plaintext to them (easy)
2. Send them the private key (arguably even easier - I don't have to mirror the traffic, and only my key security officers need to be aware of the fact that we are doing this)
3. Figure out some complex method to make a backdoored key which is backdoored in a way that _only they_ can exploit.
You'll pick 1 or 2 every time.
Fundamentally, you trust the owner(s) of the private key with your data, since they can just decrypt it and share it and preventing them from dooming you with "weak keys" is more about protecting them from themselves (i.e. accidentally generating weak keys) than anything else
Maybe you'll build the framework & subfeature A together, because you need some bit of meat in there to properly figure things out and be able to test things
On Gerrit you'd probably create two commits which get pushed as two CLs
* CL1 Create Thing framework * CL2 Implement A for Thing
They're now pushed for people to review. While they're looking at them, you continue working on, making CL3 implementing B
* CL3 Implement B for Thing
One of your coworkers points out an issue in CL1, so you fix it (by amending the commit) and repush the stack. Now your stack is
* CL1 Create Thing framework [v2] * CL2 Implement A for Thing * CL3 Implement B for Thing
CL1 & CL2 get approved so you merge them (though typically with Gerrit they're cherry picked - CLs are individual Git commits). You push up an implementation of CL4, so your stack now looks like
* CL3 Implement B for Thing * CL3 Implement C for Thing
The important point is that CLs are atomic (and are reviewed atomically) even if they depend upon each other (i.e. are a part of a stack). When you're working in Git you typically (unless for whatever reason you have multiple unrelated stacks on the go, which is relatively rare) just work off of the master branch, so all the commits between `origin/master` and `master` - i.e. the set that automatically show up in `git rebase -i` and similar tooling - are your stack. When you pull, you `git pull --rebase` (or rather set the config for your machine or repo to default to that). When you've revised something in your stack or want to add something to it, you just do "git push HEAD:origin/refs/for/master" update Gerrit with the latest version of your stack
It takes a little time to get used to (and you have to learn how to hold `git rebase -i` properly), but when you're used to it it's immensely more productive than the Github/clones PR flow (and doesn't involve manual branch juggling, etc). I can't express just how badly they deal at handling reviews of stacked PRs - either you create your stacked PR targeting master (and it gets all of the changes from the underlying PRs merged into its changes list, which makes reviewing it harder) or you target it at the branch of the underlying PR (which is non-obvious and painful and you have to manually remember to shift it across when the PR beneath it gets merged)
When I'm in this situation when dealing with something which is PR based, I tend to end up merging CL1 & CL2 (because its easier to review things when you have an example) and hang on to CL3 & CL4 on my local machine until the first one gets merged
A part of the Eurozone transition was that all local systems were replaced by SEPA SCT/SDD, which are inherently IBAN based. But SCT/SDD only apply to Euro transfers, and so in non-eurozone locales the existing infrastructure and nomenclature is retained
> Japan has the same system of sort/branch codes and account number, but when I enter those here the recipient name is automatically filled out, making incorrect transfers pretty much impossible (unless, I guess, your mis-entered transfer to Mr. Sato is transferred to a different Mr. Sato instead)
There is a Confirmation of Payee system coming soon in the UK (which most of the large banks have, unfortunately, delayed). It works slightly differently: it will compare the name, but not _generally_ tell you the name of the recipient because that comes with privacy concerns
In most cases the sort code is included in the checksum
https://www.vocalink.com/media/3513/vocalink-validating-acco...