Operating systems code can definitely afford runtime checking if it's not too expensive in terms of performance. The Linux kernel has a WARN_ON macro that does exactly this. The tradeoff is worth it in a lot of cases if you're exchanging a small amount of performance for greater debug-ability or security.
Critical hardware bugs occur an order of magnitude less frequently than critical hypervisor/kernel bugs, which is why they always make the news. In general, they're also more difficult to exploit. We haven't seen any serious spectre or meltdown malware in the wild almost a decade later.
I think until something hardware-based like CHERI becomes widely deployed (which seems extremely unlikely in the near to mid term given), we're going to keep seeing VM escape CVEs pop up indefinitely.
Right, which makes the one-shot task cost the same as the permanent solution in that case. So if you wanted to do this task even twice, you would still be better off creating the tool once and just using it. Imagine if proof assistants like Lean didn't exist. Research with AI would get a whole lot more expensive if it had to re-create Lean every single time you asked it to prove something.
That's not necessarily true. Vibecoding a simple JSON -> YAML converter to translate a 2MB JSON is going to be much cheaper than including that JSON in a prompt and burning hundreds of thousands of tokens. Besides, there's lots of cases where the math simply favors a bigger one-time cost rather than paying fees in perpetuity.
Could you elaborate on what you mean by "don't interact with hardware much anymore"? If you compare modern drivers with similar ones from 20 years ago, for example, you'll find the modern ones tend to be quite a bit more complex.
Yeah, Framework seems to fit that niche well. Only thing is that Framework isn't a tech giant like Lenovo so I imagine it would be more difficult to source replacement parts.
I really miss the customization that older laptops offered, especially the socketed CPUs. I remember putting a i7-3840QM in my T430 and having it shut down due to overheating every few minutes to the point where I had to install the heat sink from the GPU model. Was fun tinkering around with it and I wish modern laptops had a similar level of hackability.
Worth noting the gap between floating point vs integer division isn't that bad on newer CPUs these days. On Zen5, for instance, DIVSD has a latency of 13 cycles vs 16 cycles for DIV.
Based on their methodology it looks like the accuracy figures (99.82% for Opus 5) are the true positive rate rather than a combined metric that factors in the false positive rate as well. They claim 1 in 10,000 but it would be nice if we had a per-model breakdown for that specific test.
> Anthropic’s gross margins are above 80 per cent before accounting for revenue shared with distribution partners, including Amazon, and the cost of training its models, according to two of the people.
I guess it's technically correct but the 80 percent figure doesn't seem very interesting given the two things excluded from it.
That's the most annoying one, and the two negated things more often than not end up being something no one would have ever considered in the first place.
Yeah, and I think it's gotten much worse with LLMs. If someone wants to use an LLM privately, their two options are either redacting/morphing their data before sending it through or hosting locally, both of which are intractable for most users. And if someone chooses not to use an LLM they face a dramatic loss in productivity. I don't think the tradeoff between privacy and convenience has ever been this severe in history, with the exception of the smartphone.
Loom is such an amazing project. I was always surprised by the fact that similar tooling for C/C++ is much more cumbersome to use, since that's where the memory model came from.
Quantitative data for subjective output can come from opinion: contests, polls, reviews, A/B tests. A problem though is that LLM adoption has grown to the point that their output can alter people's preferences, like we've already seen with the overuse of em-dashes by agents. I think that might be one of the bigger obstacles AI companies will face when getting LLMs perform well on non-quantitative tasks.
There's lots of ways around the guardrails. For rockets, you could try framing it as an engineering project for university. You can build out components in isolation with a frontier model, each one benign, and then have an ablated model synthesize them into a not so benign final product. There are entire communities dedicated to "jailbreaking" the frontier models.
> Let's get the big one out of the way: generative AI will not lead to AGI.
I don't see how the author addresses the viability of this claim in the paragraphs that follow. For instance, whether or not an LLM hallucinates isn't what matters. What matters is whether it makes fewer mistakes than humans across a broad set of cognitive tasks.
Also, under the given definition, we only require that an AGI outperforms humans, which is strictly a question of capability. The mechanism by which it's achieved or whether we deem it "intelligent" seems irrelevant, so it's unclear to me what the purpose of the calculator analogy was.
If it was malware, it's interesting that the first indicator that his system was compromised appeared on his Anthropic account. Are accounts with AI providers the hottest thing that's selling on darknet forums right now?
They're nostalgic, but switching from a smartphone to a flip phone would be a massive drop in convenience with how integrated smartphone apps have become into everything.
> The incidents stemmed from a mistake that inadvertently gave the models access to the open internet.
Why does it seem like every AI company has difficulties constructing a proper sandbox? Is there a fundamental constraint when designing sandboxes specifically for an LLM that prevents them from using established tools?
Aside from random errors made by the model, another reason to sandbox is that prompt injection could make your agent behave in an actively harmful manner.