tbh, that companies tried to make something proprietary of this concept is probably why its adoption has been weak and why we have "MCP vs CLI/Skills/etc" debates in the first place. In contrast, CLI tools only require a general a bash shell (potentially in a sandbox environment), which is very standardised.
Everyone wants the datacenter somewhere in their country for sovereignty... just not next to them. Quelle surprise. At this point you may as well build supermarkets on top of them just to sell 'em to people.
They're so absurdly capital intensive at this point that they probably ought to be buried at least 50 meters down. If any reasonably capable countries ever face off directly they'll probably be one of the first things to go.
Given the rapidly increasing power densities I expect it would be far more straightforward to bury them. I believe a single 42u rack of last gen nvidia hardware is already more energy intensive than the HVAC for a mcmansion.
However it occurs to me that the electrical grid becomes a high priority military target in this scenario. Maybe datacenters should go all in on building their own power plants.
The reason no one responds to this list is because it's just one big gish gallop
It's enough to see that you brought a link to the Israeli Military Censor to hint at a conspiracy, to understand who you're dealing with.
But even if you go into the list, you'll see at the top that those who were shot were in the middle of the battle, where Israeli forces were surprised, to the point of massacre alongside civilians. And there, it turns out, they didn't shoot to save themselves by the skin of their teeth, but simply wanted to kill journalists.
Also, a quick search shows that "Mohammad Jarghoun" ("מוחמד ג'רגון") was not a journalist at all, but a media worker, that according to the CPJ [1], during wartime he receives journalistic status. (Also not mentioned in AJ [2]. what a surprise...)
Another comment to the pantheon of "the most logical failures, in the fewest words". And then no one understands why the ICC will never consider such reports..
Then say civilians. Don't claim what you can't provide. And DO provide context (like, was it still while the massacre was ongoing [1]). But all I can do is to suggest.
> Good job cherry-picking
Me cherry-picking: Taking the literally first entries, Array[0] and Array[1].
Also, you can't claim cherry-picking as invalid against gish-gallop. Since you can't enjoy the size argument only to retract items on the list after the smallest pushback.
Otherwise I can prove God. How? Every sentence in the Bible... Oh, you found some that are wrong? "Good job cherry-picking"!
And not to mention dozens of more problems with the list (no mentioning any IDF comments, no source for titles, etc.). This is just a bad list. Simple as.
> ICC is clearly investigating
Investigating != Judgment. But good, send them more. But please send them a list starting with items that might hold the smallest of scrutinies. And don't prove it by hinting at conspiracies just because Israel has a security censor. But all I can do is to suggest.
The link corroborates my claim; the State of Israel does not protect press freedom.
I am asking you to cite a better counterarguement, if you want to disprove it. Or concede that Israeli journalists are regularly threatened by their government.
I feel like being a journalist in a warzone is already exposure to a sufficient number of threats for the benefit of human society that we shouldn't simply accept them being exposed to any entirely different set of completely unnecessary threats from a pile of sociopaths running their own sick gambling dead pools.
Why do they need to run benchmarks to confirm performance? Can't they run an example prompt and verify they get the exact same output token probabilities for all prompts? The fact that they are not doing this makes me suspicious that they are in fact not doing the exact same thing as vLLM.
It is also a bit weird that they are not incorporating speculative decoding, that seems like a critical performance optimization, especially for decode heavy workloads.
Yes, speculative decoding will make both us and VLLM faster, but we believe it would be a relatively even bump on both sides, so we didn't include it in this comparison. Worth another test!
> Can't they run an example prompt and verify they get the exact same output token probabilities for all prompts?
You don’t even get that with GPUs in general, or really floating point in general.
The Art of Computer Programming. Volume 2: Seminumerical Algorithms section 4.2.2 with explain where it loses floating addition associativity property.
> However, as the name “batch-invariant” suggests, the technique is currently limited to handling variations related only to the batch dimension, making it robust to continuous batching and other batch-size–related changes, but not to other forms of nondeterminism like changing the TP sizes or GPU types.
IMO the core of the issue is the awful Github Actions Cache design. Look at the recommendations to avoid an attack by this extremely pernicious malware proof of concept: https://github.com/AdnaneKhan/Cacheract?tab=readme-ov-file#g.... How easy is it to mess this up when designing an action?
The LLM is a cute way to carry out this vulnerability, but in fact it's very easy to get code execution and poison a cache without LLMs, for example when executing code in the context of a unit test.
GHA in general just isn't designed to be secure. Instead of providing solid CI/CD primitives they have normalized letting CI run arbitrary unvetted 3rd-party code - and by nature of it being CD giving it privileged access keys.
It is genuinely a wonder that we haven't seen massive supply-chain compromises yet. Imagine what kind of horror you could do by compromising "actions/cache" and using CD credentials to pivot to everyone's AWS / GCP / Azure environments!
Wow that is wild, that is exactly along the lines of my fantasy language. It'd be so easy to go into the deep end building tooling and improving a language like this.
I've given up on soft delete -- the nail in the coffin for me was my customers' legal requirements that data is fully deleted, not archived. It never worked that well anyways. I never had a successful restore from a large set of soft-deleted rows.
> customers' legal requirements that data is fully deleted
Strange. I've only ever heard of legal requirements preventing deletion of things you'd expect could be fully deleted (in case they're needed as evidence at trial or something).
While not common, regulations requiring a hard delete do exist in some fields even in the US. The ones I familiar with are effectively "anti-retention" laws that mandate data must be removed from the system after some specified period of time e.g. all data in the system is deleted no more than 90 days after insertion. This allows compliance to be automated.
The data subject to the regulation had a high potential for abuse. Automated anti-retention limits the risk and potential damage.
You're thinking of "legal requirements" as requirements that the law insists upon rather than requirements that your legal department insists upon. You often want to delete records unrecoverably as soon as legally possible; it's likely why you wrote your data retention policy.
I had an integration with a 3rd party where their legal contract required we hard delete any data from them after a year. Presumably so we couldn't build a competing product using their dataset with full history.
Maybe the best part of this legislation will be that people will realize it's not institutional investors that are driving up home prices. No, that's far too optimistic.
Home affordability is getting better anyways, which is great, because we are finally having a surge in new & denser home building in popular regions and there mortgage rates are more reasonable than they were in the COVID-era.
As the article states, LLMs are fantastic at writing code, and not so good at issuing tool calls.
reply