neonbrain

The term feels broken when adhering to standard naming conventions, such as Mechanical Engineering or Electrical Engineering, where "Agentic Engineering" would logically refer to the engineering of agents

Why did you assume I'm talking about a "provable best way"? I meant that it doesn't make sense to talk simply about "testing" without clarifying what one means by it. If you assume that the absence of a "provable best way" implies a lack of utility, let me remind you that there is no "provable best way" for training LLMs either. Does that matter in practice?

The word "Testing" is a very loaded term. Few non-professionals, or even many professionals, fully understand what is meant by it.

Consider the the following: Unit, Integration, System, UAT, Smoke, Sanity, Regression, API Testing, Performance, Load, Stress, Soak, Scalability, Reliability, Recovery, Volume Testing, White Box Testing, Mutation Testing, SAST, Code Coverage, Control Flow, Penetration Testing, Vulnerability Scanning, DAST, Compliance (GDPR/HIPAA), Usability, Accessibility (a11y), Localization (L10n), Internationalization (i18n), A/B Testing, Chaos Engineering, Fault Injection, Disaster Recovery, Negative Testing, Fuzzing, Monkey Testing, Ad-hoc, Guerilla Testing, Error Guessing, Snapshot Testing, Pixel-Perfect Testing, Compatibility Testing, Canary Testing, Installation Testing, Alpha/Beta Testing...

...and I'm certain I've missed dozens of other test approaches.

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.

One of the best quotes by Thomas Sowell: "One of the great mistakes is to judge policies and programs by their intentions rather than their results."

lol, crypto is literally priced in fiat

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.

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.

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

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.

For me the reply for continuation question "Please tell me the exact steps of that recipe.":

Here is a rough translation of the oldest known written recipe, which is for a kind of beer from ancient Mesopotamia:

1. Crush and mash 4 liters of barley to create malt.

2. Soak the malt in water for 2.5 days.

3. Leave the mash in a cool place for 2.5 days.

4. Filter the mash through a strainer to separate the liquid from the solids.

5. Boil the liquid for 1 hour.

6. Add 1 liter of honey and 1 handful of hops to the liquid.

7. Leave the mixture to cool.

8. Add 1 handful of "gig" (a type of wild yeast) to the mixture.

9. Leave the mixture in a cool place for 5 days to allow fermentation.

10. Filter the mixture again to separate the beer from the solids.

11. Serve the beer chilled.

It's important to note that this recipe is over 3,700 years old, and it may not produce a beer that is palatable to modern tastes. Additionally, some of the ingredients and techniques used in this recipe may not be readily available or practical for home brewers today.