For the record, Apple notes that the DSA requirements only impact developers distributing through the App Store, not through alternative distribution [1].

[1]: https://developer.apple.com/help/app-store-connect/manage-co...

Technically, CVEs are meant to only affect one codebase, so a vulnerability in a shared library often means a separate CVE for each affected product. It’s only when there’s no way to use the library without being vulnerable that they’d generally make just one CVE covering all affected products. [1]

Even ignoring all that, people are incorporating Copilot into their development process, which makes it a common dependency.

[1]: https://www.redhat.com/en/topics/security/what-is-cve

Other countries have similar issues, of course, but often (not always) they have more cultural factors keeping third spaces alive. In my experience traveling Europe and Africa, community and familial ties generally have a more active role, so there’s just more opportunities for stable third places to develop. It’s not that the spaces are different, imo, but they do seem more common.

Perhaps requiring support for bill capping is the right way to go, but honestly I don’t see why providers don’t compete at all here. Customers would flock to any platform with something like “You set a budget and uptime requirements, we’ll figure out what needs to be done”, with some sort of managed auto-adjustment and a guarantee of no overage charges.

Ah well, one can only dream.

This seems more like a model-specific issue, where it’s consistently generating flawed output every time the cache gets invalid. If that’s the case, there’s not much Google can do on a case-by-case level, but we should see improvements over time as the model gets incrementally better / it becomes more financially viable to run better models at this scale.

[1]: https://www.apple.com/legal/intellectual-property/trademark/...

In any case, clearly the prevailing understanding is wrong in one way or another, and that should be reflected in curriculums alongside this new evidence.

It does tend to be used for public safety notifications, but it's strictly opt-in. There are also several apps using it for smart home security alerts, health reminders, etc. already.

The strength of these platforms is the same as their weakness: they aim to eliminate suboptimal outcomes. While that is beneficial on the surface, I take issue with how it effectively rules out any chance of unlikely matches somehow working out. The question of “Do I give them a chance based on just a feeling?” never needs to get raised. Considering how significant both personal and professional relationships are in people’s lives, to me it’s akin to deciding someone’s fate on the basis of a prediction. It doesn’t leave much room for people to exercise free will, or it at least doesn’t prioritize it.

From the standpoint of optimization above all else, these services are immensely valuable, so it makes sense to at least consider them for various purposes. However, for me, the benefits are outweighed by the feeling of infringing on people’s free will.

Apple's also been deleting more and more of its old documentation. Much of the it can only be found on aging DVDs now, or web/FTP archives if you're lucky. Even more annoying is how some of the deleted docs are _still_ referenced modern docs and code samples.

So maybe training for litmus tests isn’t the worst strategy in the absence of another entire internet of training data…

[1] https://developer.apple.com/documentation/xcode/defining-a-c...