I've been in the room when it happened. In one memorable incident, a junior trader I sat opposite bought 100 bn Japanese Yen instead of 10 bn. His excuse? "I lost track of the zeros". We'd only hired the guy because he had a PhD and "PhD's are smart" - lol. In his defense the UI was awful. He left soon after...
Me too. Fatfingers happen much more often than the ones that are reported, partly because it's really hard to make UX that is functional for high-performing individuals trying to respond quickly in pressure situations while also protecting them from the consequences of errors.
For example, in one old FX trading system I know about you would type in the cross you wanted (eg say GBP if you wanted GBP/USD) and the amount and then if you hit enter it would execute. If you hit F5 it would execute that number of million of that cross. So say you wanted 10 million, you could type 10000000 and hit enter or you could just go 10 F5 and it would immediately execute 10 million. (ie if you hit F5 you didn't also need to press enter).
F6 was the same, but for billion. And yes it originally had an "are you sure?" chicken box but there was only one flag to disable all chicken boxes and one of the chicken boxes on another part of the system was such a constant pain in the ass that everyone had chicken boxes disabled. So if you fatfingered and hit F6 when you meant F5 you could literally execute a thousand times as much as you intended.
Other than massive wrong amounts, the other one I've seen a lot is people buying something when they thought they were selling and vice versa.
A dialog box allowing the user to “chicken out” if they have second thoughts about some important action. Usually they say something like “Are you sure? yes/no”
A "fat finger" of only 10x is not that much of a fat finger and may not be detected for it's probably nothing out of the ordinary compared to the brokerage account's size. The fat finger in TFA, however, is a quite bigger fat finger: $444 bn instead of $58m.
Except that apparently they had such warnings for individual trades, but the bundle was implemented as "for(trade in bundle) transact(trade)". Which design has a certain appeal, standing on the shoulders of the peculiar handling of each trade, but with the terrible flaw that the bundle is never considered in its totality.
How do you buy 10,000,000,000 (let alone 10x that much) of something as a junior trader without someone signing off on it? There's nothing at all to stop catastrophic actions being taken by anyone in the organization?
At the time, no. There wasn't any checking. And while it looks like a lot, it wasn't insanely expensive to unwind. Sometimes these kind of mistakes make money. My own 'mistake profit /loss' was around +1m USD.
Yen was probably around hundredth of euro or dollar. So it is 100 million or billion worth of very liquid currency. Very likely among the most liquid trade pairs. As such you need to trade big to make money there. Get timing right and you make it, get it wrong and you lose some.
It's a completely 3d printed, fully analog, fully per key adjustable activation depth, magnetic levitation, mega RGB keyboard. Absolutly insane.
For sane people there's always the wooting HE https://wooting.io/wooting-60he which by most people's count is the best gaming keyboard money can buy right now.
Or, you could use NixOS and just declare your systems in some text files, git commit; git push.
You build script becomes:
while true; do
git pull
nixos-rebuild switch
sleep x
done
That's it. You can even do it remotely and push the new desired state to remote machines (and still build on the target machine, no cross compile required).
I've completely removed Ansible as a result and no more python version mismatches, no more hunting endless task yaml syntax, no more "my god ansible is slow" deplyments.
There is actually a /bin/true, which could involve the fork of a new process for each iteration of the loop. The form that I have shown you is guaranteed not to fork.
Sounds interesting. Let's say the software is a web backend. Can you deploy it like this with zero downtime? So that the new version starts, new traffic goes to it, and the old version handles its active requests to completion and then shuts off.
I don't think so, by default I think the nixos process will simply stop (probably by sending SIGINT) the service and then start it again.
But if you could have the server into 'lame duck mode' (no new connections accepted, but existing ones can finish) / gracefull shutdown and that's a blocking call (or you could poll if it's still up etc), then you could script that before the 'nixos-rebuild switch' call. Maybe sending SIGINT to the service does that already?
The kind of risky behavior that caused the 2008 crisis would have happened a lot more often if the markets had been regulated as poorly as crypto. There would have been a 2008-style crisis every decade.
What happened to banks in 2008 demonstrates the value of the regulations and other systems we had in place. Some banks did fail, but depositors didn't lose money because of the FDIC insurance.
