What I don't get, which this article doesn't talk about, why would Apple’s Virtualization.framework expose a lesser Metal profile instead of reporting all capabilities supported by the host GPU?

Because nobody knows.

Apple doesn't let you "pass" the GPU through to a VM like most other ARM/x86_64 processors (forwarding interrupts and PCIe memory regions). There are symbols defined to do this within the kernel (if you dump the binary) but they aren't used in retail macos.

Instead you end up creating a paravirtual device that emulates the GPU acting like a 'normal PCI device' which you give to clients. This is usually reserved (by other hardware vendors) for when you're doing multi-tenat time sharing of higher end GPUs (like Nvidia enterprise cards can do).

These paravirtualized GPUs then just have 'less features' and Apple (being Apple) states no reason why.

my guess is apple chose a conservative profile for compatibility across different chips and guest releases

All M-series chips support Metal 4. Wonder if we can fix this with a simple override somewhere.

QEMU/kvm does this as a default, because keeping a more generic CPU / etc makes moving VMs between machines with different hardware possible. If you try to move a VM it won't work, of course, if the new machine doesn't support what the old did.

Not sure of this is why Apple does it. With KVM, you tend to pick a baseline that all your machines support.

Because it cannot be safely virtualised?

This is what most people in the comments are missing. They are removing the ability to even use Anthropic APIs not just your Max subscription.

this not true. api keys are supported. only "claude code" is being dropped.

that code is just a cli hint to which LLM they recommend using. so they stop recommending anthropic. rightfully so.

But the PR is also removing the ability to use Anthropic API key as well not just Claude Code subscription

That's just them being vindictive. Anthropic doesn't care about API use, it's paid per token anyway and they set the prices for that.

I work in big-tech and we’re only allowed to use our companies internal tools that mimic Claude Code etc. There is certainly a push to use it, and I’ve noticed a significant increase in bugs that have come along. There are so many PRs now that no one reviews them and just slaps a LGTM. Specifically with junior or less strong engineers. It’s like they don’t code anymore and push everything on the AI and say ship it without a second thought. I’ve watched engineers push AI code with a nasty NPE and then they also had it write unit tests where the AI caught the NPE and passed the test. Literally if anyone spent the time reading the code you’d see it was a ticking bomb. We went from production breakages every couple of months to every couple of days. It’s so bad but no one is saying the hard thing that less strong engineers need to be restricted on their use of these tools.

Huge caveat to hosting this server publicly is the codebase will accept any websocket connection to the /{connection_id} route. The author gives a small warning about implementing authentication in the README, but it essentially makes the project extremely dangerous to deploy as any person can use your domain to host their content.

Isn’t the whole reason the lawsuit started because the Internet Archive went above an own-to-loan ratio of 1? This blog post completely leaves this detail out and makes it seem they were always only doing 1 physical copy to 1 digital copy which is not true.

>Isn’t the whole reason the lawsuit started because the Internet Archive went above an own-to-loan ratio of 1?

No. The lawsuit was about CDL as a whole, and there's plenty of evidence showing publishers were preparing for it even without the COVID emergency library. If the lawsuit was just over the emergency library, I doubt IA would still be fighting.