331 karma · joined September 19, 2020
(that's buried somewhere in https://www.ecb.europa.eu/pub/pdf/other/Report_on_a_digital_... )
https://www.clevelandfed.org/en/newsroom-and-events/speeches...
These laptops are gorgeous new, but they are SO fragile. One of the screen hinges is broken, I've replaced numerous keys, the keyboard is now developing some debounce/key registration issue all over the right-hand side, the speakers are both blown (left first then the right), the trackpad sits 0.5cm above the case (needs replaced), the glue holding the rubber to the bottom of the case expanded with heat and leaked out everywhere. Probably more I've forgotten
I'd still consider buying another, but I'd also strongly consider changing vendors once this machine finally dies
edit: are the downvotes because you believe race matters in this case, or some other problem with the comment?
The only place etcd might not pay off is in disposable dev environments or something, but do you really want your prod setup to page only to discover a complete cluster rebuild is necessary to resolve the problem?
But don't let it encourage you to think serverless has no value, or it can't be done portably or cheaply. It has its sweet spots just like everything else.
On the ops side even with a platform like Lambda, training an operations team to take over maintenance of a nested spaghetti of random interlinked services and bits of YAML trapped in random parts of the cloud is a total nightmare. The amount of documentation required and even the simple overhead of enumerating every dependency is a long term management burden in its own right. "The app is down" -> escalate to the developers every single time.
Compare that to "the app is down", "this app has basically no ops documentation", "try rebooting the instances", "ah wonderful, it came back"
I'm pro-cloud in many ways and even pro-serverless for certain problems, but let's not close our eyes and pretend dumping everything into these services is anything like a universal win.
For example at IEX when they introduced their speed bump, it was to protect their so-called 'mid peg' hidden orders. What they found was that these orders were still the target of adverse selection because some HFT trader could submit speculative orders well in advance, by predicting price movements based on fast information from connectivity to the order books of other exchanges.
That PDF is an awesome read ( https://iextrading.com/docs/The%20Evolution%20of%20the%20Cru... ), but I think it speaks to a more general problem of trying to slow down. Even if auctions on all exchanges only occurred once every 10 seconds, there will still always be an advantage to whoever can aggregate information the fastest and use this to submit a best price at the latest possible moment to participate in the auction.
In my uninformed state, it doesn't seem possible to truly reverse this process, and I'm left wondering what problem would be solved by attempting to eliminate HFT from the markets
Gosh, it's genuinely shocking I haven't heard that phrase in a long time.
If you limit HFT, then markets /do/ become less efficient. When two trading venues for the same instrument exists, say, in Europe and the US, there is no benefit to any participant for a price disparity to exist for a long period. If $GOOG tanks 10% in a day, and a retail investor buys $GOOG at its old price in Europe, who is better off? Similarly for a seller in Europe, what if you were fleeced 10% because your holdings moved favourably in the moments before you sold?
HFT also makes trading cheaper for everyone. Much of the time these firms are primarily competing with each other. One way that competition manifests is in the bid/ask spread. With firms fighting for order flow, if they can improve their offer by a single cent to ensure price-time order book priority then they'll improve their price. For Joe Retail buying or selling that instrument, he just received a small improvement on the spread as a side effect of essentially duelling titans.
There are more aspects I'm not smart enough to discuss, like how HFT basically enables entire asset classes through dynamic hedging. The only reason that option markets exist on most stocks is because there is an HFT counterparty that sold you the option rapidly buying and selling the underlying stock to ensure its exposure to the position was only the premium you paid for the option.
HFTs also provide some market stability, first through increasing liquidity having a volatility smoothing effect, and second through so-called "volatility compression" as a result of option market dynamic hedging causing HFTs to buy when others are selling and sell when others are buying. This one has a darker side as depending on their aggregate positioning, HFTs will eventually begin to dump just like everyone else.
I believe HFTs are also necessary for exchange-traded funds to be priced correctly and function correctly. That's essentially because two markets always exist for an ETF: a primary market between dealers and the fund where creation/redemption units are traded, and the secondary market where regular folk buy its shares. Given the prevalence of ETFs as a retail investing vehicle, if they were mispriced this would be potentially disastrous for individual investors.
Probably a bunch more good reasons for HFT, I'm not sufficiently versed in this stuff
edit: will be sticking with the original, looks like the fork maintainer made no effort to work upstream first, which is a very bad look for what is essentially a piece of security software. https://gitlab.com/nobody42/localcdn/-/issues/5
(edit: downvotes? I'm sorry to ruin the romanticizing, but surely it should come as no surprise that these old compilers aren't fast due to black magic)
- SSL and "TCP" handshake are collapsed into a single transaction
- That transaction is worst case 1 network roundtrip, best case (returning user) 0 roundtrips
- Anti-filtering baked in. Quic reveals almost nothing for middleboxes to filter on. There is not yet an accepted solution for encrypting the target server name (SSL SNI) but that's still being worked on AFAIK
- "Modern" congestion control approach, where "modern" means "fuck any TCP connections sharing the link"
Getting buffers down to 500ms is already pretty insane assuming reliability doesn't suffer. 250ms is well within the envelope of a single drop on a 3G network killing playback