But that all went out the window with Quake. Once PCs got 3D graphics cards, Macs just couldn't keep up because those companies wouldn't write Mac drivers for their top-end stuff. I do remember getting a Voodoo 2 once 3Dfx started selling it for the Mac, and Unreal looker absolutely gorgeous.

But if an officer gets a confession by saying, "They just passed an amendment, and you don't have the right to a lawyer anymore, so you have to answer my question or I'll send you to a torture dungeon", that is a lie that can harm anyone, regardless of guilt.

When I got the game and looked at the box, I was heartbroken. But I decided, why not put in the disk anyway. I did the Get Info on the app, and lo and behold, Lucas Arts had left what was probably a totally untested 68k slice in the binary. Double-clicked it, and I could play without a problem. Sure I had to play it in a tiny 320x240 window, but that extra 16 MB of RAM and extra 25 MHz made it playable.

Like yes, I get that in a strict engineering sense, that is the correct and least surprising behavior. But it's stupid and virtually guaranteed to not be what I wanted to happen. My expectation is what macOS does in this event -- nothing.

Passkeys are basically session cookies that are signed by a secure element in one of your devices at the time you log in. That's it. They cannot be phished because there is no password to steal. If I had to guess, the basic flow is something like this:

1. When the passkey is created, the device's secure element coughs up a public key or something to the server representing itself as a trusted device

2. When a user logs in, the server issues a challenge (basically a random number) to the device and says "sign this with a private key that corresponds to one of the trusted public keys I have"

3. The secure element signs the challenge and sends it back

4. The server goes through its list of trusted device public keys until it finds one that verifies the challenge response. If it finds one, it logs you in. If it doesn't, you don't log in

Step (1) is probably bootstrapped with a username/password and second factor like SMS 2FA, OTP, or email 2FA.

Even if this isn't exactly how they work, it's a plausible implementation. Nothing about this requires vendor lock-in. The various secure elements that can produce passkeys come from many different places, so I'm sure sufficiently motivated open source people could create a firmware TPM that is certified for use with passkeys or something if they cared enough.

I'm guessing you're talking about fruits. In which case, you consume them, but you don't digest them. The sugar in them is bound up with a ton of fiber, and the majority of it never gets digested. That's why dried fruit is so much higher in calories than its source: all the water and fiber is removed.