This isn't a good approach because it assumes there are no market makers on trading venues, and that they (as well as exchanges) do not compete for order flow. Also, maybe you haven't noticed, but stocks are often frozen during news announcements by regulatory request, so such pauses are already in place and are designed to maintain market integrity, not disrupt it with arbitrary fills.
At least it could add a theoretical bound on the expected hallucinations for a particular model/quant at hand? Although I'm very skeptical that companies would disclose their training corpus, and derivative models trained on top of foundation models are another level of indirection, it would still be interesting to have these numbers, even if just as rough estimates. The compression angle in this thread is spot-on, but yeah, operationalizing this is hard.
I believe Microsoft's usual "Embrace, Expand, Extinguish" strategy is at work here. For system stability and security reasons, you wouldn't actually want agents to dynamically discover tools without proper governance. Alternatives like PydanitcAI are lost in this steady MCP noise maintained by Microsoft - their "Embrace" phase for MCP, declared during Build 2025 event. Anthropic released this open standard with weak tooling and no governance for the specs, making it easy for Microsoft to dominate.
The next step would be Microsoft attempting to make their registry the de facto choice for developers and extending with Windows-specific verbs.
Then, by controlling what's considered "secure", they can marginalize competitors.
I assume he's just being over dramatic. I use Perplexity every day, multiple times per day, and it almost completely replaced Google for me in such areas as coding or technological research. Also, I never used nor planning to use ChatGPT or Claude (I use private open models instead - Mistral Nemo, Qwen, etc.). But I also feel like "I'm not unique in this regard", lol.
My understanding is that the dataflow user was talking about a notification which the server is supposed to receive from the OS in the case of a broken client connection. This notification is usually received, but cannot be guaranteed in a distributed environment.
The assumption that your server will always receive RST or FIN from your client is incorrect. There are some cases when these packets are being dropped, and your server will stay with an open connection while the client on the remote machine is already dead.
P.S. BTW, it's not me who downvoted you
I made no such assumption this will always happen though? That's why the comment was so much longer than just "isn't TCP RST enough?"... I listed a ton of ways to deal with this that didn't involve letting the program continue happily on its path.
Sorry didn't see your message.
What I mean is that if you are not getting RST/FIN or any other indication for your closed communication channel, you only left to the mechanism of timeouts to recognize a partitioned/dead/slow worker client. Basically, you've mentioned them yourself ("timeouts, lack of heartbeats, etc" in your post are all forms of timeouts). So you can piggyback on these timeouts or use a smaller timeout configured in the lease, whatever suits your purpose, I guess.
This is what I believe Kleppmann referring here to. He's just being generic in his description.
> What I mean is that if you are not getting RST/FIN or any other indication for your closed communication channel, you only left to the mechanism of timeouts to recognize a partitioned/dead/slow worker client.
Timeouts were a red herring in my comment. My problem wasn't with the mere existence of timeouts in corner cases, it was the fact that the worker is assumed to keep working merrily on, despite the timeouts. That's what I don't understand the justification for. If the worker is dead, then it's a non-issue, and the lease can be broken. If the system is alive, the host can discover (via RST, heartbeats, or other timeouts) that the storage system is unreachable, and thus prevent the program from continuing execution -- and at that point the storage service can still break the lease (via a timeout), but it would actually come with a timing-based guarantee that the program will no longer continue execution.
The problem is that gold and crypto are priced in relation to fiat and if fiat ceased to exist, you wouldn't be able to price either. When splitting gold or crypto among fellow citizens (yes, these assets will become shared between everyone), you wouldn't be able to do so without some form of IOU, which effectively would become another form of fiat. It's a catch-22 situation: while fiat exists, gold-bugs and crypto-bros feel smug, when there's no fiat, everyone is suddenly unhappy.
When I run mistral-chat on Ubuntu 22.04 after cleaning up some smaller processes from the GPU (like gnome-remote-desktop-daemon) I am able to start Mistral-Nemo 2407 and get a Prompt on RTX 4090, but after entering the prompt it still fails with OOM, so, as someone noted, it narrowly fits 4090.
Agreed, it narrowly fits on RTX 4090. Yesterday I rented an RTX 4090 on vast.ai and setup Mistral-Nemo-2407. I got it to work, but just barely. I can run mistral-chat, get the prompt, and it will start generating a response to the prompt after 10 to 15 seconds. The second prompt always causes it to crash immediately from OOM error. At first I almost bought an RTX 4090 from Best Buy, but it was going to cost $2,000 after tax, so I'm glad that instead I only spent 40 cents.
