I’ve been on the receiving end where hobbyists were trying (and eventually succeeded) to hack our DRM scheme.

It was really fun to read the forums and see how, day by day, they managed to get closer. Since it wasn’t really crucial IP to begin with, we were rooting for the little guys to see how close they would get, secure in the knowledge that our algorithm was solid. :-)

The final exploit that granted them access was due to a supplier who replaced an earlier validated random generator with something not quite as random, which enabled replay attacks.

Reminds me of comfort noise in the telephone system.

Even though the system encodes silences noise free (so improve compression), it deliberately inserts noise because otherwise people think the line is dead.

Here is one of them: https://cumulis.epa.gov/supercpad/cursites/csitinfo.cfm?id=0...

Intel graciously paid for trees to brighten up the street and has a nice street sign saying so. (It doesn’t say why they did.)

This one is not directly related to silicon production, but the QA that came after.

If that were true, why didn’t they do this kind of authentication right from the start?

There is little upside in screwing over millions of existing customers.

Other phone manufacturers aren’t as prolific in updating the low level firmware of their devices once it’s on the market?

I’ve worked with many LCD panels: while they all support one of a few signaling standards, there is no standard for the cables and connectors. (Or if there is, nobody follows them.) For each LCD panel, you need to make a custom cable.

So that part is not something that’s specific to Apple.

Yes, but even for your WiFi example, fixes to work with a non-compliant third party are often reactive. In many cases, that’s the only practical way.

They already IPO’d. :-)

I assume that there might be technical reasons to do it that way.

For example: a soft delete may be just a stronger version of public vs private settings. The whole software infrastructure still assumes a link exists and doesn’t need to cover cases where it really isn’t there. I could see how that makes maintaining indexes etc easier.

Flipping a flag and then filtering out results down the line based on the delete setting is probably much easier than actively removing them from an index.

And if deleting is rare (it probably is), then the performance and resource impact should be minimal.

Last time I checked, HIP didn’t support reading from textures.

That’s something that’s not only useful for pure graphics.

So it is (or was?) not a straight substitute for CUDA.