How is everyone wildly misunderstanding this article?
It's lack of linux driver support for firmware designed for windows only laptops.
What is going on here? Commenters here are clearly extremely paranoid about NVIDIA centralizing inference. This is not reflected in the facts nor narrative of the article - it's completely fabricated out of left field her in the comments.
This is a problem on the MSI Prestige laptop using the RTX Spark platform with Linux. Lets assume it also applies to the Asus and Dell machines using RTX spark and Linux.
RTX Spark is a new platform and all of these laptops ship with Windows. You cant get Linux on any of these machines from the factory. NVIDIA may even ship drivers for linux later as they did with Dynamic Boost.
Most nvidia consumer/desktop GPUs are crippled intentionally in various subtle ways - tensor cores for example are capped at half speed on all GeForce cards, which is why https://github.com/Zagitta/gpu-unlock exists. The intent is to force you to spend significantly more for the exact same silicon under commercial packaging if you want to do inference tasks.
Can someone ELI5 how this "Leads to AGI"? I can kind of understand some sort of "theory of mind" going on here, but how would having a complex world model enable, say, an AGI that could file my taxes for me?
AGI is a loaded phrase these days. But if we focus on how it will improve the quality of training data for LLMs, I can prob talk about that.
Right now LLMs only have text, images, and videos to train from. Anything it understands about physics is from an abstract level. It's like learning how to calculate throwing a baseball before you've ever even thrown a baseball. Imagine having to learn force = mass x acceleration before you've even picked up a ball.
What this world generation Google is doing appears to be something Nvidia has spoken about too. Letting LLMs/AI learn from a world physics simulation. Meaning LLMs having the opportunity to "experience" physics, the same way you intuitively know how to throw a ball after attempting a few times yourself.
If an LLM can better understand how our real world works the quality of its output improves -- theoretically.
As far as your taxes go, you can create an intelligent workflow right now to do that for you. Don't need AGI for that.
Plenty of issues that have been patched recently found using such tools as well. OpenBSD's policy remains largely the same as always: You need to understand the patch you propose and it needs to be maintainable. The link elsewhere in this thread is mainly discussing large patches where it is unclear if the LLM drew too heavily on code elsewhere.
OpenBSD's errata list has recently started growing rapidly, and the scale is a real departure from the past. I have taken to running syspatch much more regularly than in the past. Anyway, it's clear that the project's stance on AI is "as long as reports are detailed and high-quality (and probably from a person with a record of such work) the project will act on it." See slide 17 here: https://events.eurobsdcon.org/media/2026/submissions/ZGDXQR/...
Talked to bluhm@ after that talk in Brussels and the general feeling (from what I can remember from the conversation) so far is that there is a large increase in overall reports (good and bad), but that the severity of what is reported has not really increased. This also mirrors my own experience from reading source-changes@. In essence, it seems like we have known how to build secure software for the last thirty or so years, just that most do not seem to have bothered to do so.
I think it's the complete saturation of the platform with members who make it feel like HN is a platform for people to boast about how many tokens they burnt to rewrite something that already worked fine.
It polarizes people to either join the "the LLM is my god" crowd or the "if AI touches the repo, it's all slop" crowd.
The careful balance is rarely discussed, probably because that's the part that still takes work.
It really depends on the post anymore. Have had a lot of really thoughtful discussions about the nuance that came out of HN convos. Seems like most businesses and people are still just trying to figure out.
I think "careful balance" is the status quo even if people are unaware of it being so.
Agents and LLM-assisted coding currently work within the confines of already working hand-coded OSes, language frameworks, test harnesses and even CLI tooling. Pull one of those out, and agents become unhinged and they lose direction.
I think this is fairly common practice when writing compilers. You ideally want to be able to bootstrap from other languages, and C is a much simpler starting point.
Not true in this case; the original intent for BYOB (Build Your Own Blocks) was as an extension to Scratch. When the Scratch team decided not to merge it, the BYOB folks decided to build it into Snap! instead of abandoning the perfectly-functional code they'd written.
reply