There's 8 billion people on the planet. Are you saying 7 billion a year do get drunk?

Out of those 8 billion, 7,999,999,999 did not make as stupid a comment as you did. Let's celebrate!

That may or may not be a defect. Human eyes are also not seeing in all directions at once, unlike Tesla's cameras.

And it has nothing to do with the CEO's lie that cameras cannot be safer than humans, when it is the automation that makes automated cars safer. Mount a lidar to your roof. Are you now a safer driver? No. It is the automation which is safer, not the lidar alone.

You skipped this quote in your hurry to apologize for the liar. Are you a politician?

"If the goal were to just approximately match human performance or to build an assist product ..."

"approximately match" also means "no better than". Even if you take it to mean "only marginally better than" it's still a lie. If cameras are only as good as human eyes, they still don't get drunk, distracted, or drowsy.

No, I settled with him being a liar, because it is not the lidar which makes automated cars safer than humans, it is the automation. He said cars without lidar cannot be safer than humans. He is wrong. Lidar may add safety, but it does not add as much as automation itself.

Selection bias my left eye. There are enough drunk, distracted, and drowsy human drivers to kill thousands of people every year, and they are statistically significant; there are no drunk, distracted, or drowsy automated drivers, and that zero is also statistically significant. So is the difference, and it is entirely due to automation, not cameras vs lidar. And getting back to my original post, that is why I call that CEO a liar, and you have not addressed that.

In principle, it should be possible to develop a vaccine for certain forms of mental illness. Regrettably, no such thing currently exists and antivaxers are probably too far gone.

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

No. That is not what he said. He said cameras-only driverless cars cannot be better than humans.

That is a lie, and that's what I called him out for. Research be damned; cameras already have better resolution than the human eye, but that's not where the safety comes from. It comes from being automated, and not getting distracted, drunk, or drowsy. If you won't believe that without research papers, then you're a damned fool.

Where did I say anything about perfection? It's true that automation has a perfect record of not getting drunk, but I doubt that's what you meant.

Don't make up things to blame me for. There's plenty of real things for that.

You didn't read what I wrote. The claim is that camera-only automated cars can never be safer than human cars. That's wrong, because the safety comes from automation itself being a better driver than a human, even if it only has cameras. Other sensors may or may not add safety. The do not guarantee additional safety.

An automated car can also be worse than a human driver, even with a dozen sensors. But it won't be because of the sensors.

Automation is safer because it doesn't get distracted, drunk, or drowsy, not because it uses lidar. Adding lidar can add safety, but it doesn't guarantee it.

No you don't. Humans get distracted, drunk, and drowsy. Automation doesn't. That's where automation is safer than humans.

Lidar and radar can add safety, but they do not guarantee it.

He's lying.

"Better than humans" is possible with cameras only, because most of the errors humans make have nothing to with their eyes. Humans get distracted, drunk, and tired. Automation doesn't.

I'm sure lidar and radar can do better than cameras alone. But lidar and radar do not guarantee better than humans.

He's just trying to justify his expensive system.

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

Is the person who ignored Pelosi in the room with you right now?