You enjoy your horse dewormer, I'll take the mRNA gene-editing.

Not only is it better to use a direct method of measuring distance vs inferring, but it also has the benefit that direct methods of perceiving distance often detect the edge cases where inferring distance from video gives dangerously incorrect answers (see hitting the side of lorries that are too similar colour to the background).

The person you are responding to makes the unsubstantiated claim that Google are only retaining lidar due to it being a sunk cost, but it seems much more likely that Tesla is only refusing to incorporate it (given how affordable it is now) because they'd have to admit they'd be wrong and lying about it being better for years.

I want this feature like now. But to be really effective you need to be able to migrate between hosts as well. So the host needs to be able to set the device IDs, not the NVMe device.

That is not a missing piece. That is pretty much the point of the exercise. The proposal lays it all out.

I managed Citrix and VMware pools backed by NetApp filers for decades. In that world, migration was comparatively straightforward because both hosts could already see the same backing storage. Direct-assigned local NVMe buys you much better performance, but it also exposes hardware-specific identity, capabilities, topology, and internal controller state to the guest. That is not so good when the guest has to wake up on a different host attached to a different physical device.

So they present a hybrid abstraction: give the VM something that looks and smells like its own NVMe SSD, but make the identity and migratable state of that SSD virtual objects created inside the hardware. Hypervisors, good ones anyway, can trap and emulate portions of that interface to disguise differences between source and destination hardware, but that is expensive and undermines the reason for direct assignment in the first place.

This is a good compromise.

The host-side orchestrates an exported controller and namespace with guest-visible IDs that can be reproduced on another host. You are dead-on about the host setting the IDs -- under this spec, the hypervisor defines the NQN and GUIDs, not the physical silicon. The SSD implements that identity in hardware. The VM is not being handed the physical drive; it is getting a reproducible object. At the destination, the orchestration layer recreates a compatible exported subsystem, writes the extracted controller state blob into the new hardware, and resumes. The guest OS NVMe driver never even realizes the underlying silicon changed. This is a real win -- you've just turned a dock-side warehouse into a curated pret-a-porter rack at Nordstrom's.

NB: For standard local flash drives, this doesn't magically eliminate the need to move the backing data via storage vMotion or block-mirroring. this is where NVMe over TCP actually hits the nail on the head. In our hyperscaler world, a "local PCIe NVMe drive" becomes a DPU/SmartNIC that translates local PCIe commands into NVMe over TCP attached to the shared storage backend. The new spec lets us extract the PCIe controller state from one host's DPU, inject it into a different host's DPU, and viola: because the backing data is already on the network, the migration happens instantly without copying a single block of storage. This is a real win.

What this adds is a standard way to do that while preserving the device identity and operational state presented to the VM, without forcing the hypervisor to intercept and emulate the NVMe administrative path, checking it off against a vendor-specific clipboard. If you read past the executive summary, that is what most of the update is there to accomplish.

I'm assuming that they've thought of that, though. Seems like they also introduced QoS. And what about using this for RAID? NVMe over TCP seems to be in there as well.

You assume correctly. :) It is sitting there once you get past the headline and into the part of the specification where the nouns start breeding and the market-speak adjectives and adverbs dry up and blow away.

The QoS piece is separate but obviously useful here: if every VM gets an exported controller, per-controller IOPS and bandwidth limits become a very clean way to keep one noisy tenant from eating the whole device. Also, RAID can exist above the exported namespace, below it, or behind it, but this proposal is not defining RAID semantics. It is defining how an exported NVMe device can retain its identity and operational state while the VM attached to it moves elsewhere. You are right that NVMe over TCP is highly relevant to making this work at scale, but it is actually a separate, established standard that has been around for years. NVMe over TCP handles the back-end transport across the data center fabric to the shared storage array. The proposal fixes the front-end PCIe problem. It defines how an exported PCIe NVMe device can retain its identity, queues, and operational state while the VM attached to it moves to new physical hardware. It bridges the gap, allowing a VM to get bare-metal local PCIe performance while still being able to live-migrate across hosts pointing to the back-end NVMe/TCP storage

...go hang out there with the other link-spammers trying to monetize anti-AI sentiment.

AI Doesn't Simulate Reality.

Congratulations are in order: you have successfully established that MCP is not a conscious mind.

Neither are HTTP, OAuth, JSON-RPC, load balancers, or any of the other infrastructure actually being discussed here. The MCP update removes the initialization handshake and protocol-level sessions, makes each request self-contained, permits ordinary round-robin load balancing, adds header-based routing and cacheable tool lists, restructures interactive requests, hardens authorization, and formalizes extensions. Those are concrete engineering changes addressing concrete deployment problems. None requires a soul to emerge from a server rack.

It simulates fluency. It calculates text. We are living through the greatest psychological gaslighting in the history of technology.

“It calculates text” is reductionism masquerading as analysis. A compiler calculates symbols. A database rearranges bits. A CPU flips transistors. Describing the mechanism at its lowest level does not establish that the resulting representations are meaningless or unreal.

There is substantial evidence that models trained through next-token prediction can develop internal representations of board states, spatial structure, temporal structure, and even human-interpretable latent concepts. That does not establish consciousness or AGI, but it does dispose of the claim that these systems necessarily produce nothing beyond surface fluency. The resulting representation does not become unreal merely because every step that produced it was computational.

And “gaslighting” is doing some heroic unpaid labor here. Gaslighting requires deliberate psychological manipulation. Disagreeing with your philosophy of mind does not qualify.

Every day, Silicon Valley founders stand on stages and promise that if we just feed enough internet data into a massive GPU cluster, a conscious mind will magically emerge from the server rack.

Perhaps some founders have made extravagant AGI claims. The MCP specification does not.

This is a bait-and-switch. The article describes an interoperability protocol for connecting models to tools and data sources. You have replaced that engineering discussion with the most inflated claim you could find somewhere in Silicon Valley, then demanded that MCP answer for it.

It is the philosophical equivalent of crashing a discussion about an HTTP revision to announce that the Internet has failed to become sentient.

They show us models that can write poetry, pass the bar exam, and simulate empathy, and they tell us we are standing on the brink of Artificial General Intelligence.

Even granting your premise that an LLM merely “simulates fluency,” your conclusion runs backward. If a model cannot maintain a sufficiently accurate representation of reality internally, then giving it controlled access to external tools, databases, and authoritative sources becomes more useful, not less.

“AI does not simulate reality” is not an argument against MCP. It is practically the requirements document.

MCP exists because useful systems need access to information and capabilities beyond whatever is encoded in their parameters. You have mistaken the problem the protocol addresses for an objection to the protocol.

They are lying to you. Not maliciously, but because they have confused the map with the territory.

That is rhetorical packet corruption.

Lying implies deliberate deception. Gaslighting implies it even more strongly. Someone who has confused the map with the territory is mistaken, not lying. Pick an accusation and establish it.

You have not criticized the protocol, its architecture, its security model, or a single change in the new specification. You have simply hung an anti-AI placard on an unrelated technical thread and supplied an X link for anyone who wants the rest of the sermon.

Clearly you know nothing about the spiritual satisfaction of using a hand-whittled oak NVIDIA Blackwell Ultra B300 rather some soulless chip made in a factory.

This story is being reported incredibly poorly in most places. He isn't being prosecuted for destroying evidence, the statute he is charged under covers destroying something to stop it being seized. There is no requirement that what was destroyed be criminal in nature or evidence relating to some other crime. The government are asserting that they have broad powers to seize items at borders without the need for warrants etc which worrying is true as there are laws allowing this that have been around long enough to be challenged all the way up to the Supreme Court without being found to be unconstitutional. If he had wiped the phone before being detained, or potentially after being detained but when he had plausible deniability that they may want to seize his phone, then he wouldn't have done anything wrong under that statute.

Every time you speak to another human being, two cameras and two directional microphones are already pointed at you. They are called eyes and ears. So the mere presence of sensors in a pair of glasses does not create some unprecedented privacy apocalypse. The real discontinuity is simpler and far more dangerous: carbon forgets; silicon does not. The problem with wearable AI is not that it can see and hear. The problem is that it may never forget.

Human memory is lossy, selective, contextual, and unreliable. Wearable AI can preserve exact language, identify speakers, timestamp encounters, correlate remarks across years, and retrieve a contradiction while the other person is still speaking. What was once an informal conversation can become permanent, searchable evidence.

Keeping the processing local would solve some very serious problems. It could prevent Meta, Apple, OpenAI, advertisers, data brokers, and governments from quietly accumulating everyone’s conversations in centralized databases. That matters. But it would not solve persistence itself. A private archive is still an archive, and the people inside it may never have agreed to become permanent entries in someone else’s searchable memory.

I say that as someone who strongly supports wearable AI and can imagine an immediate use for it. I would love glasses that could recall my previous conversations with someone, compare what they are saying now with what they said before, and help me identify equivocation, rhetorical sleight of hand, or a logical fallacy in real time. Having that capability in a coffee shop or at a political rally would be enormously useful to me.

But I understand the social friction that creates. Human relationships evolved around imperfect memories; introducing a memory system that never forgets creates a profound asymmetry. One participant would be relying on ordinary, fallible human memory. The other would be carrying a complete evidentiary history of the relationship, backed by an LLM capable of searching, comparing, and prosecuting every inconsistency.

Perfect retrieval is not perfect understanding. People change their minds, test ideas, speak imprecisely, joke, and respond to different contexts. LLMs can also hallucinate, misread context, and state questionable conclusions with unnerving confidence. That is why they remain tools rather than replacements for human judgment. I can conduct a smell test of anything an LLM regurgitates. Until an LLM can reliably do the same, it remains a really smart, really fast intern that still makes intern-level mistakes.

And that capability cannot be legislated away or penned up in some corporate patent stable. The technology will not remain confined to whatever boundaries governments or corporations draw around it. Once the cameras, microphones, radios, storage, and local models exist in a commodity device, technically capable users will repurpose them.

I was a CS undergrad when Phil Zimmermann gave the world PGP. It was just f'ing funny when the US government discovered that mathematics does not climb back into the box when ordered. Wearable AI will follow the same general pattern. The hardware may be harder to copy than software, but the capability will diffuse across the planet, the tools will improve, and LLM-assisted development will continue lowering the expertise required to stitch the pieces together.

I think Stanley Kubrick understood this before most of us had computers on our desks. The bone in 2001 was not merely a tool for obtaining dinner. Almost immediately, it became a weapon, a status amplifier, and a means of domination. The lesson was not that tools are evil; it was that any technology which extends human capability also extends human intention.

Perfect recall of every conversation is not merely a memory aid. It is immense social leverage. That leverage can be weaponized by bad actors or converted into a predatory business model by corporations. The question is not how we shove the technology back into the box, but how we mitigate those intentions without crippling the capability itself.

In a bucket, I do not think the answer is to reject wearable AI. That is neither realistic nor desirable. The answer is to regulate the things that can still be regulated: make persistent retention an explicit and disclosed act rather than the invisible default, require unmistakable notification, attach serious penalties to covert misuse, protect spaces where recording is prohibited, and prevent manufacturers from quietly converting ambient life into corporate training data.

Privacy law needs to distinguish between a machine that remembers what its wearer witnessed and a machine that allows its wearer to perceive anything at all. A blind person’s camera may be functioning as an eye, and a deaf person’s microphone may be functioning as an ear. We need to regulate retention, identification, transmission, and misuse without legislating those people back into darkness or silence.

We probably cannot make persistent memory technically impossible. What we can do is make it socially visible, legally consequential, and commercially abnormal, even if we cannot prevent every abuse.

I think you are making a couple of assumptions that don't pass muster. If they ask you for a PIN, you provide a PIN, they enter the PIN, the phone then likely shows some form of reset notification, then the next time a screen comes up it is to setup a fresh device then they have plenty of evidence the device wasn't wiped until they entered the PIN. Why that matters in this case is they aren't pursuing him specifically because the device is wiped, but because of dishonesty/trickery in providing a reset code instead of the unlock code when asked which is against the law in this scenario. If the phone was blank, or he wiped it himself, there would have been no criminality; which is why your position (don't fly there without wiping the phone first) is the one I'd advocate to anyone it is viable for.

So take Torvalds' advice and walk away, friend. The immediate subject here is Sashiko, an AI system that reviews patches submitted to the kernel. It does not write patches, merge patches, or waive the kernel's standards. You have silently replaced that subject with an imaginary “slopped Linux kernel,” then left reality behind. Sashiko's own documentation describes a multistage review system whose final product is an ordinary LKML review message, not code smuggled into the tree.

I wouldn't say pragmatic, no.

“No” is not an argument. Torvalds evaluated a tool, found that it produces useful results, acknowledged its failure modes, and concluded that the answer is to manage those failure modes rather than prohibit the tool. That is almost a dictionary illustration of pragmatism. You may dislike his conclusion. You do not get to redefine the word merely because it reached a destination you dislike.

He's tried it, found it works, and now won't listen to the people pointing out the numerous problems with it.

Torvalds explicitly mentions maintainer workload, bad output, imperfect results, economic uncertainty, and the embarrassment of having tools uncover bugs humans missed. His stated objective is to make these tools help maintainers rather than burden them. So your evidence that he “won't listen” is a post in which he explicitly lists the problems and discusses what should be done about them? You are impeaching him with evidence that contradicts your own assertion.

The slopped Linux kernel may well be a violation of the copyrights of several unknowns in Europe, for example.

“Slopped” assumes the conclusion before you have identified a single defective patch. “May well” supplies insinuation without assuming the inconvenience of evidence. “Several unknowns in Europe” supplies neither a copyrighted work, an allegedly infringing kernel passage, a claimant, a contributor, nor even a coherent theory connecting Sashiko's review comments to infringement.

Sashiko is reviewing human-submitted code. You have switched from “an LLM commented on this patch” to “the kernel contains copied LLM output.” Even where AI-assisted code is submitted, kernel policy does not confer some mystical robot exemption. A human must review it, ensure license compliance, sign the Developer Certificate of Origin, and accept responsibility for the contribution. Maintainers can apply extra scrutiny or reject it outright. The DCO is not a magic anti-lawsuit talisman, but it demolishes your pretense that Torvalds has ordered the gates opened and dismissed provenance as somebody else's problem. Bring us an actual patch and an actual infringement allegation. Until then, “unknown Europeans may object” is pure insinuation.

If you're not planning to build a Linux-based product in Europe, not a big issue I guess.

You have not established a European violation, so you cannot derive business advice from one. Geographical hand-waving does not transmute “perhaps some unknown person owns something somewhere” into evidence. The word “Europe” is not an incantation that relieves you of identifying what was copied.

Not an issue in the US.

One sentence ago, the law was apparently so subtle that everyone else was irresponsibly overlooking international complexity. Now the copyright status of an unspecified patch, containing unspecified material from an unspecified source, has been conclusively resolved for the entire United States in one sweeping sentence. That is jurisdictional Mad Libs, not a coherent argument.

But it's amazing how many people think US copyright law is the only type of copyright law.

Who said that? Torvalds did not. The Sashiko devs did not. The GP did not.You manufactured a provincially ignorant opponent because refuting that strawman is easier than demonstrating infringement in the Linux kernel. Announcing that foreign laws exist is not a substitute for applying one of them to an identifiable set of facts.

And that's before we get to changing the entire nature of Linux so it's no longer a project understood by human beings.

An AI reviewer does not make the reviewed C code incomprehensible. It produces comments about a diff. A human still submits the patch and accepts responsibility for it; humans still review it, humans still test it, and humans still decide whether it enters the tree. Kernel guidance is explicit: submitters are expected to understand and defend everything they submit. If they cannot, maintainers are entitled to reject the series without detailed review.

As for your prophecy that Linux will cease to be understood by human beings, Hitchens’s razor applies: what can be asserted without evidence can be dismissed without evidence. Consider it etched in silicon.

A compiler does not make C unknowable. The kernel already uses Coccinelle semantic patches to detect problematic patterns and generate complex, tree-wide changes. Nobody claims the resulting code has ceased to be understandable by humans merely because software helped produce the patch. And the kernel does not become occult because one of its reviewers is silicon. “Humans might stop understanding Linux” is a legitimate risk to watch for. It is not evidence that this has happened, and certainly not evidence that an automated reviewer caused it.

This is Bitkeeper all over again.

BitKeeper was proprietary source-control infrastructure used to manage kernel history. Sashiko is an optional review tool that comments on proposed patches. BitKeeper occupied the repository-management layer. Sashiko supplies another opinion during review. BitKeeper's continued availability depended upon a commercial vendor's license. Sashiko's code is Apache-licensed and supports multiple LLM providers. If one provider disappears, Sashiko can be pointed at another; the kernel development infrastructure remains exactly where it was.

The only overlap between these two different tools is that “Torvalds approved a tool.”

That was the last time Torvalds made a "pragmatic" decision, effectively locking out a large number of kernel devs from kernel development, until he was forced to build Git to replace it.

That assertion is so reality-warping it has a Schwarzschild radius. Kernel contributors were not required to use BitKeeper. Contemporary kernel documentation explicitly stated that no developer was required to use BitKeeper to contribute. And the official Git history says Git followed the breakdown of the vendor relationship and revocation of BitKeeper's free-of-charge status, not some mass expulsion of non-BitKeeper developers. I was there; I watched it happen in real-time. The arrangement ended when BitKeeper's free-of-charge availability was withdrawn after the relationship with its vendor broke down. Torvalds and the community then created Git using lessons learned from BitKeeper. The official Git history describes exactly that sequence, completely contradicting your revisionism. Furthermore, calling this “the last time Torvalds made a pragmatic decision” requires us to believe that the top-level maintainer of the kernel has made no pragmatic technical decisions since 2005. That claim collapses under its own theatrical weight.

If anything, BitKeeper demonstrates the opposite of your intended lesson: Torvalds adopted a tool because it improved development, tolerated ideological criticism while it remained technically useful, and replaced it when the dependency became untenable. The result was Git. That is not an indictment of pragmatism. That is pragmatism successfully handling both adoption and failure.

Ultimately, you have not demonstrated slop, infringement, developer lockout, or the disappearance of human comprehension. You have substituted an epithet for a quality analysis, hypothetical claimants for an infringement case, a slippery slope for evidence, and BitKeeper for a relevant analogy.

Torvalds did not say that AI output gets a pass. He said AI is a tool, and that contributions will continue to stand or fall on technical merit. That is the whole point you are trying to obscure. If the code meets the kernel's standards, it is not “slop.” If it does not, reject the patch. That is the standard we use for human work, compiler-generated work, transformation tools, static-analysis fixes, and every other contribution.

Demanding that one disliked tool be judged by tribal affiliation instead of its output is not a tenable position. Your whole post is an attempt to import your anti-AI ideology into the review process, despite Torvalds's explicit rejection of ideological vetoes over technical merit.

17 more years? I can't wait to see people in their 70's through 90's adventuring through the universe. Are stargates handicap-accessible?

Seriously though dude this is actually interesting science news vastly more important than some cheesy show.

I regret to inform you that you have woefully underestimated it. The actual retail rate offered to consumers is closer to $2200 US per gallon. Sources: internet-ink.com, cbc.ca. This $14 million fine is only worth like, seven thousand gallons, or less than 200 oil barrels of ink.

I don't agree with Trump on just about everything but I really don't think this is dumb. Sure there are issues around it, but having basically no ability to access the core components of any computing device without being reliant on China should be a major concern to any major economy.

It's arguably considerably simpler to migrate putting electronic devices together relatively quickly than to go from having no chip-manufacturing capability to having it given the specialist equipment and other complexities. It also makes producing downstream products in the US more attractive if the components don't have to be bought and shipped from China. Governments in countries like the US should be treating the entire supply chain for eletronics like they treat energy and other critical infrastructure, all the way through from sourcing rare earth minerals etc to products in stores or weapons in armouries.

Are there really Cyber-Insurance vendors people are picking that don't include considerable cover for disruption? I've met with two IT leadership teams who've been through major incidents with two different insurance vendors where they had faced significant disruption; in both cases the insurer helped them source and deploy alternative infrastructure/services and were willing to spend a considerable amount to minimise the impact of the incident. The assumption is that this was motivated by the fact the insurer benefits by limiting the cost of the incident.

"The notion that there is a shortage of physicians is preposterous - the residency programs will continue to be filled every single year."

How on earth are those two things contradictory? The problem is there are too few residencies for how many physicians we need.

From a legal perspective a random number generator deciding who to refuse to do business would be perfectly legal so that really isn't an issue for the stores; unless someone barred could prove something like it disproportionately flagging black people incorrectly or similar.

There is nothing in the description saying people are being detained, and I doubt that is happening in the vast majority of cases, but obviously detaining someone who hasn't committed a crime would be a really dumb thing to do that could get both the store and the person who unlawfully detained someone in trouble.https://news.slashdot.org/story/26/07/12/0259226/facial-recognition-in-uk-shops-will-soon-instantly-alert-police-about-offenders#