Forgot your password?
typodupeerror

Comment Re:AI as collaborator, not competitor. (Score 1) 59

The thing is, you and I have both discovered this.
I'm consistently working on my Arcade game passion with Local LLMs. And every time I mention this, the world goes into hate mode, it's just fashionable to do this right now.

I've been coding arcade games since the 80s on my own, it was slow, tedious and took forever, but it was fun in the long run. I code apps too, and I do music by hand, artwork by hand, and I do most of the project management, this is where AI comes in as an absolutely game-changer of a tool, but yes - it's a junior dev. you have at hand and at will, the hardware was expensive however, but totally worth it.

Now I even get it to work with me on AI tools that I use for making my projects, my latest integrator beats the living lights out of the agentic setup most people use, I have special templates for AI tuning which means it spits out clean code and documentation depending on the project that is made, and I have created plug-ins for project management for the projects, it's a blast, all done locally. And it's working.

It's rare for me to have showstopper bugs now, I had that 3-4 months ago, but the latest models in combination with my plug-ins, yeah, you know what, we're gonna let everyone else yell at the clouds. We're having fun.

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.

Comment Re: The climate is going extreme (Score 1) 114

And you think the fact that carbon dioxide has steadily increased over the past 150 years or as we pump a lot of carbon dioxide into the atmosphere is a coincidence? You honestly believe that there is zero connection between pumping gigatons of carbon dioxide into the atmosphere, and there being gigatons more carbon dioxide in the air than pre-industrial times? Completely unrelated events?

Comment AI as collaborator, not competitor. (Score 1) 59

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.

Comment Re:Meaningless statements? (Score 1) 219

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.

Comment Re:This is neat! (Score 1) 22

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

Comment Your map is in another thread... (Score 1) 49

...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.

Comment Re:it is destroying evidence like it or not (Score 1) 182

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.

Comment It’s Not the Surveillance, It’s the Pe (Score 4, Interesting) 47

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.

Comment Re:Can't prove when it was cleared (Score 1) 218

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.

Slashdot Top Deals

interlard - vt., to intersperse; diversify -- Webster's New World Dictionary Of The American Language

Working...