FWIW it's entirely possible (and not uncommon) for a single executable to behave differently depending on the name it was launched under.

I have no idea in this case, but it's possible that "Siri" and "Siri AI" are genuinely different in behaviours and interfaces and dependencies, even if they are the same binary.

I'm sure you've considered and rejected tmux, but is this only because it has a different UI than a native OS app?

In some states, until the early 1990s, SSNs were also used as drivers license numbers.

I struggle to see the difference between "bringing an extra battery" and "bringing a power bank".

Except that the latter has more functionality than the former, and should be prefereable.

Grand solutions require broad coordination, and they often devolve back into a modified-but-equivalent version of the previous problem. :(

Stream-of-bytes is classically difficult model to escape. Many have tried.

Yeah. There are good reasons things are bad. But there's also a foolish consistency. Like, you can just do things! If you decide monitoring is important you can decide not to outsource it. Most everyone doesn't, though. Probably because they don't think it's very important, and the existing tools get it done well enough, and it's the muscle memory of the subjectively familiar (if objectively fantastically overpriced).

Well, in the early days of infrastructure growth, when designing bespoke monitoring systems and protocols would be relatively low-cost, it's still nowhere near the highest-ROI way to spend your tech team's time and energy.

And to do it right (i.e. low-risk of of having it blow up with negative effects on the larger business goals), you need someone fairly experienced or maybe even specialized in that area. If you have that person, they are on the team because of their other skills, which you need more urgently.

SaaS, COTS, and open source monitoring tools have to cater to the existing customers. The sales pitch is "easy to integrate". So even they are not incentivized to build something new.

It boils down to the fact that stream-of-bytes is extremely well-understood, and almost always good enough. Infinitely flexible, low-ceremony, no patents, and comes preinstalled on everything (emitters and consumers). It's like HTTP in that way.

And the evolution is similar too. It'll always be stream-of-bytes, but you can emit in JSON or protobuf etc, if it's worth the cognitive overhead to do so. All the hyperscalers do this, even when the original emitter (web servers, etc) is just blindly spewing atrocious CLF/quirky-SSV text.

> It'll always be stream-of-bytes, but you can emit in JSON or protobuf etc, if it's worth the cognitive overhead to do so.

This is the crux of it. That's great until you encounter a need for a schema, and then it's "schema-on-read" or some similar abomination. And the need might not manifest until you're pushing like 1TB/day or more of telemetry data with hundreds or thousands of engineers working on some >1MLoC monstrosity. Hard to dig out of that hole.

The situation is tragically optimal--we've achieved some kind of multiobjective local maximum on a rock in the sewer at the bottom of a picturesque alpine valley and declared victory. We should do better.

Or maybe I'm overly optimistic.

> The situation is tragically optimal--we've achieved some kind of multiobjective local maximum on a rock in the sewer at the bottom of a picturesque alpine valley and declared victory. We should do better.

But it's a very comfortable rock. pointy in all the right places.

til it ain't

This reads like satire, but I've been feeling that a lot lately.

All China has to do here is stay in the game and wait patiently while the US and EU press pause on data centers. See also: solar panels.

We're making this way too easy. The rationale and logic are reasonable, but ultimately irrelevant.

If benefitting the victims is a goal, then clearly sending them money now is more valuable than sending them interest-borne money later.

If the victims don't benefit from the money now, they can bear their own interest. Time-value, etc.

Similar situation here.

My take on it is that frequent users perceive apps as desktop launchers/shortcuts.

They don't care about the difference between app and web, per se, but the bookmarking situation in mobile browsers is awful (desktop too, honestly), and an app presents a convenient launcher for the service/site/data they want.

Adding a springboard launcher for a PWA is easy but still apparently more frictional than installing an app.

Android and iOS both require user permission for apps to access contacts or location.

Are there other platforms that can't even manage this basic level of user protection?

As long as the application is made aware of the permissions and can prevent functioning when they get denied, that doesn't really help much. It's the choice between getting mugged or never leaving the house.

The ability to deny permissions without the app noticing or filling it with fake data doesn't exist on either system.

Not a single platform require permission from each individual contact in your adress book to access them and that is the real problem.

GrapheneOS allows for this. It's called Contacts Scope.

Not really it asks the user of the device, not the individual contacts whose PII data could be treated by third parties tb hey never gave consent to.

Yes, Windows.