I agree, especially with that last part. They have no idea what they are missing. I'm a gamer, and I have nothing but respect for game devs. You guys make life *fun*. :) As I mentioned, I am a sysadmin, not a coder. But -- with the help of an LLM I vibe coded two successful mods for a couple of my favorite games and figured out (again, with the help of an LLM) to get one of them published to Steam's workshop. At my college commencement thirty-odd years ago, my CS advisor noted that in his 25 years on faculty, I was the only graduate who genuinely couldn't code his way out of a wet paper bag. Fair assessment. But an LLM bridges the gap between architectural intent and actual syntax, which lets me build things in my head. I keep getting the feeling that the anti-AI backlash is coming from the same kind of people that blame their tools when they screw up. I'm a baby with a flamethrower when it comes to using an LLM to write code for me, but I figured out (eventually) how to put guardrails around *everything* so that the LLM converges on my intent, and not the semantics I used to convey that intent. That's the real hard part, I think. Sounds like you figured that out as well.

Torvalds is right. This is a bit of a me too post, although my use case is a little less kernel-adjacent. :)

Up front -- I'm not a dev. I'm a retired sysadmin with a BS in CS and several decades in cubicle land managing systems and networks for a very, very large defense contractor. And I hate coding with a purple passion...if I couldn't solve it with a shell script, I would hand it off to a real coder. With that said, I've spent the last several days using an LLM as a development partner to build a fairly ridiculous personal music system. What surprised me wasn't that it could generate Python. That's useful, but not especially interesting.

What became interesting was using it as a persistent collaborator. My sysadmin lizard brain imposed enough engineering discipline that neither of us was allowed to hand-wave about system state. The result was actually amazingly useful to me: a user-specific taste model from actual listening evidence rather than genres. It (currently) has nine weighted dimensions: melodic continuity, spatial/textural architecture, emotional landscape, developmental architecture, background-to-foreground permeability, conceptual/lyrical reach, contextual integrity, arrangement integration, and register/timbral fit, and two engines, one cloud and one local, that actually can generate context aware playlists, one from the music mines available from my Spotify subscription, or one from my local mp3 media library managed by my wine-supported Winamp install. And fine, go ahead and insert Ok, boomer jokes here. :)

Both engines reduce requests like "I'm surfing slashdot for a couple of hours and don't want the music getting in my way" or "I'm about to try this damn slaughterspine fight for the umpteenth time and I need something to propel me into a flow state" into an activity envelope, apply the taste model, and then produce something that both Spotify's API and winamp can grok. The end result is a private playlist in my spotify account, or a .m3u8 playlist for winamp. The taste matrix guarantees the list will be generated from music that I genuinely like to listen to, and still match the context I want to listen to it in.

As a pleasant surprise when I was building the local model, I ended up creating a seriously functional ID3 metadata scrubber. Did you know that there is an entire cottage industry out there for figuring out what exact physical carrier your MP3s were derived from? I didn't, but the LLM did. It fingerprinted all my mp3s, matched them to online digital signatures, record label catalogs, and even pulled down and digitally fingerprinted free samples from Apple/Amazon music when it couldn't find a good fit elsewhere, including deep dives in USENET alt.music.mp3 archives. These forensic tactics were brand new to me, and they helped to completely fix my Winamp ID3 tag jungle. I ended up with a very decent forensic model with a control surface that let me find provenance and preserve it in a SQLite catalog for almost my entire winamp library; I'm down to just 17 holdouts out of the 914 mp3s I've ripped from CDs over the course of the last four decades or so -- many of which I no longer possess and can't consult for provenance.

But the part that made the LLM genuinely useful was the boundary between its world and me. The development loop was roughly:

wild ass idea -> generate helper -> run locally -> deterministic evidence -> inspect/adjudicate -> next operation

rather than:

AI says it probably will work -> continue

The LLM has been exceptionally useful for finding contradictions in my schemas, designing forensic queries, generating one-off analysis tools, keeping long dependency chains straight, spotting places where I was promoting an inference into a fact, and remembering why some ugly-looking safeguard exists after I had long forgotten the incident that created it.

TBH, It has also confidently proposed things that were just plain wrong, misunderstood what layer owned a fact, tried to solve problems more broadly than the evidence justified, and occasionally decided that some particularly unpleasant corner was probably not worth pursuing. Which is where Torvalds' comment made me laugh. The useful mode isn't "tell the AI to build a system." It's much closer to "keep track of this shit for me, please, and try to keep us from shooting ourselves in the foot."

It's like having a very fast, very sharp indefatigable summer intern with an absurdly large working notebook, broad technical knowledge, apparently no need for sleep, and a tendency to press shiny red buttons just to see what happens. If you give an LLM observable state, narrow authority, regression checks, and provenance, and are willing to accept that you might have to herd some hallucinating cats, it can become one hell of a collaborator.

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.

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.

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.

Why do they always push for DST instead of regular time.
(Yes this is AI summarized but it illustrates the point.)

The primary argument for permanent standard time (regular time) over daylight saving time is that it aligns much better with natural human biology, leading to superior sleep health and fewer accidents. Sleep experts and health organizations overwhelmingly prefer year-round standard time.

Economic and Social Context
        The DST Preference: Despite health warnings, lawmakers often push for permanent DST because retail, tourism, and golf industries lobby heavily for extra evening daylight, which increases consumer spending.

Health and Biology
        Circadian Rhythm: Standard time aligns the clock with the solar cycle, providing natural morning light that signals the brain to wake up.
        Melatonin Production: DST creates darker mornings and late-evening light, delaying the body's natural production of melatonin needed for sleep.
        Chronic Sleep Loss: Medical groups like the American Academy of Sleep Medicine warn that permanent DST leads to a permanent state of "social jetlag" and chronic sleep deprivation.
        Health Risks: Studies link the circadian misalignment of DST to higher rates of cardiovascular disease, obesity, and mental health struggles.

Safety and Practicality

        Morning Safety: Permanent standard time ensures the sun rises earlier in the winter, preventing children from waiting for school buses in pitch-black darkness. [24, 25, 26]
        Accident Reduction: Better sleep quality under standard time reduces daytime fatigue, lowering the risk of drowsy-driving traffic accidents and workplace injuries. [27]
        Historical Precedent: The U.S. repealed its 1974 permanent DST experiment specifically because dark winter mornings caused a spike in schoolchild traffic fatalities. [28, 29]

So in your mind "spread the word" is actually marketing to the students.
Did they have to market lawyer or finance bro, or doctor?
Or did those jobs Demand higher salaries that then caused the students to pick those jobs. Raise the salaries raise the job opportunities instead of importing workers, and the students will already know before picking a major.

maybe it is not that they don't want to work, but don't want to work for minimum wage and tie that to maybe 20 hours a week. (so no benefits).

If users create little interactive toys and shove them into their friends’ feeds, Meta gets more feed inventory, more engagement, more impressions, and more chances to drop sponsored units into the attention stream. You got that part right. But the ad does not have to be literally stapled to the gizmo. The gizmo just has to keep users’ eyeballs fixed in the feed for one more pass through the variable-reward slot machine. Same dopamine-tuned engagement model as TikTok, YouTube, Instagram, and the rest of the scroll-farm economy.

And I would not let the prompt/data angle off the hook, either. FB has already said it can use interactions with generative AI features to personalize content and ad recommendations. So FB’s business model becomes: users generate the bait -> users distribute the bait -> FB monetizes the attention around the bait -> the interaction telemetry improves the next round of bait. Wash, rinse, optimize, repeat. That is not copyright theft. It is much more boring, much more scalable, and much more on-brand for Zuckerberg.

“Effectively theft” is a great way to waste a useful point by stapling it to a strawman.

Meta does not need to own everything users create for this to be a bad deal. In fact, the Pocket terms point straight back to Meta’s standard deal: users retain their IP rights, while Meta gets the license, platform control, engagement data, and AI-improvement exhaust. That is not copyright theft. It is surveillance capitalism with a toy-box UI.

And that distinction matters, because Slashdot is full of pedants with calipers. Say “Meta steals your copyright,” and the thread immediately bogs down in ownership, licenses, assignment, fair use, AI authorship, and whether prompt output is even copyrightable in the first place. Meanwhile, the real criticism quietly escapes through the server-room vent.

The real criticism is simpler and nastier: Pocket turns user creativity into product telemetry. Prompts, revisions, remixes, plays, shares, camera/mic-adjacent interactions where users grant permission, abandonment points, and feed behavior. Meta does not have to pick your Pocket (nice analogy, btw, if a bit misguided) by taking title to your idea. It can just watch millions of people prototype tiny attention traps and then build a behavioral graph from the telemetry. That is the gold they are farming, not IP rights

So yes, distrust Meta. Absolutely. But do not replace threat modeling with pocket puns and call it analysis. Strawmen are bad arguments anywhere; on Slashdot they are worse, because they give the opposition a nice clean target while the actual monster keeps eating the village.

“Malware Gizmos” is a nice scary phrase, but it is doing a lot of unearned work here.

These are not random APKs being passed around the cafeteria with “install unknown sources” turned on. Pocket gizmos are AI-generated interactive experiences running inside Meta’s app/feed, under Meta’s account system, Meta’s Community Standards, Meta’s reporting/removal process, and the mobile OS permission model. That does not make them safe. It does make the “new STD” metaphor sound more like Slashdot drive-by trolling than threat modeling.

The real risk is not that Grandma is going to catch a polymorphic worm from a dancing cat gizmo. The real risk is that Meta now has another low-friction funnel for collecting prompts, edits, remixes, interaction patterns, camera/mic-adjacent behaviors where users grant access, and engagement telemetry. That is the actual trap. Not vibe-coded malware.

By all means, distrust Meta. I do. Meta has earned every ounce of side-eye it gets. But if we are going to criticize the thing, criticize the thing that exists: an AI toy-feed wrapped around data extraction and engagement optimization. Calling it malware because “AI bad” just lets Meta defenders dismiss the valid critique as drive-by Slashdot hysteria.

What Meta is almost certainly farming is user intent.

Prompts. Edits. Remixes. Likes. Abandonment. Which tiny games get played, which ones get shared, which mechanics make people tilt the phone, which ones ask for camera/mic access, which ones train the next interaction model, and which ones can be shoved into a feed until the dopamine lever squeaks. Pocket looks less like vibe coding in the programmer sense and more like TikTok plus Roblox plus a telemetry tap directly into Meta’s AI stack.

So yes, be suspicious of Meta. That part is just good hygiene. But “AI bad” is the lazy Slashdot version of thinking. The real critique is more specific: Meta is trying to turn user creativity, user attention, and user interaction traces into training data and engagement inventory. The gizmo is the bait. The behavioral graph is Meta's real target.

Basic question since I have not researched Nuclear power in a long time. The last time there was a big push and building of nuclear reactors the main problem was the spent fuel rods. The response back then was we will have developed the tech to deal with it in the future when the rods are used up. Has this happened? or are we still doing the bury it in the earth until the future when we have developed the tech to deal with it?

First, apologies to Motown, Edwin Starr, Norman Whitfield and Barrett Strong. But this is obligatory... :)

  Q-C (What Is It Good For?)

Q-C! (Huh, yeah!)
What is it good for?
Well, it ain't good for nothing!
(Uh-huh!)
Q-C! (Huh, yeah!)
What is it good for?
Just don't hype the scaling!
Listen to me...

Q-C... it ain't nothing but a heartbreaker.
Q-C... friend only to the dilution refrigerator!
Oh, you wanted perfect gates, but Physics gave you error rates,
An RF knife fight with a pipe organ, sealing your fate!
I said...

Q-C! (Huh, yeah!)
What is it good for?
Simulating chemistry!
(Absolutely!)
Q-C! (Huh, yeah!)
What is it good for?
But Physics is the border guard!
Say it again, y'all!

Q-C... I despise,
The impossible roadmap with the confident fonts and lies!
They think it tries every answer all at once, it's true,
But a millikelvin chip ain't a magic GPU!
I said...

Q-C! (Good God, y'all!)
What is it good for?
Well, it ain't good for nothing!
(Listen to me...)

Q-C... has shattered many an engineer's dreams,
Made VC's invest in fault-tolerant schemes.
But amplitude ain't permission, and interference ain't omniscience,
Measurement is where the magic trick meets physics' strict conditions!
Lord knows...

Q-C! (Huh, yeah!)
What is it good for?
Material science!
(Uh-huh!)
Q-C! (Huh, yeah!)
What is it good for?
Just don't hype the scaling!

Q-C... hear me today,
The traveling salesman still has to travel anyway!
The exponential search space is grinning in the tall grass,
While a classical processor kicks your millikelvin ass!
I said, Q-C!