There also needs to be some way to indicate that a JSON construct is a Set, Map, plain object, or array. You’d want a date/time type as well.

Without breaking existing JSON parsers, the way to do that is to add metadata like a _type field to an object, or to add a “sidecar” object like superjson does. Which works but is ugly IMO.

Then there’s BSON, YAML, JSON Schema, and the one we don’t mention ₓₘₗ. To my knowledge all of those could be extended in a way to support new types, but require the producer and consumer to both understand and follow whatever convention you use. They lack the universal interchangeability of JSON.

Set and Map would be more useful if they were compatible with JSON. I see a lot of people using an object as a dictionary or an array as a set because of that.

There’s no way Apple lets the automaker access app data from your phone. Apps on the phone can’t even see data from other apps on the phone.

There are two ways I can think of for the infotainment to get the messages. The first is by OCR-ing the CarPlay screen, which is shady as hell. The second is a feature like this one where the car has Bluetooth notification integration.

And of course there have been forges launched, including SourceHut, Gitea, Gogs, Forgejo…

Not Plex, but yes. I use it with Microsoft Remote Desktop if I need to access a work-related computer that I keep at home while traveling.

I also use it for the more typical use case of a cloud server that I can ssh into even though it exposes zero ports publicly.

For a complex (i.e., larger) image, I would be concerned that I didn’t exercise all of my app’s functionality and something important might be stripped out of the image.

I use Alpine instead of Ubuntu when I’m concerned about image size.