That said, I still find it very bizzare that it's so hard to find a tangible example to see how it is in practice.

The rfc has none. Another spec including the use of it has none. In the end only completed service provider/implementers show it.

Before programmatic access happens, it needs to be written by a human. Yet the whole thing feels so human-unfriendly.

Perhaps I am biased robots.txt sets a high bar on how easy it is to find and work with?

Here's one I could find: https://accounts.google.com/.well-known/openid-configuration

But how does one even find this?

I did read one before while working with github oidc, and I did find it very useful.

What is it with technical documentations that go deep describing what it is in plenty words but refusing to give a single example? This far from the first case I've ran into either.

One thing I notice, which may be the worst part of it, although I realize it might be bit too pessimistic: It doesn't matter whether A identifies with X — if B thinks A identifies with X, the discussion still breaks down and it becomes difficult to have a fruitful argument. In other words, one party can shut down and degenerate a discussion for both (or many).

It makes me think once again about the adage: Communication is a two-way street; can't have communication otherwise.

first paragraph begins the article upon 2 very big and flawed statements:

> Apple fans would, for years and years, sneer at Microsoft’s penchant for talking about products that may or may not ship, deriding them as vaporware.

maybe some would, but as a whole I would say this is not a common thing

> After Apple’s bungled 2024 launch of Apple Intelligence and new Siri, however, vaporware is fair game

no it's not

I didn't know about Project Solara so learned a new thing from the article, but I got the impression that it's not as big as the author tried to make it seem, felt very distant and forced.

The author addressed this; they were unable to disable it completely.

Seemingly effortless comments yelling to the void not worth starting a conversation with. Not the kind of comments that belongs or are wanted in this platform.

It just distracts the discussion away and adds nothing.

Mind boggling

Personally I also question the practicality or usefulness of this table because why should I care about having "the best unicode support"?

Curious, I briefly compared top ranked emulator (ghostty) on how fast it can print 10000 lines and it took 432ms compared to alacritty, ranked 18 (50ms), and Terminal.app, ranked 29 (50ms). If this is the trade-off to have the best unicode support, why should I want it? Why does it matter?

I don’t see the state file as a complete downside. It is very simple and very easy to understand. It makes it easy to tell or predict what terraform will do given the current state and desired state.

Its simpleness makes troubleshooting easier: the state files are easy to read and manipulate or repair in the event of a drift, mismatch, or botched provider update.

With the solution proposed it feels like the state becomes a black box I shouldn’t put my hands in. I wonder how the troubleshooting scenarios change with it.

Personally, I haven’t ran into the scaling issue described; at any given time there is usually only one entity working with the state file. We do use terragrunt for larger systems but it is manageable. ~1000 engineer org.

Very good question; what's holding us back really? If we want an open phone there should be more discussions on this. Some thoughts aided with chatgpt:

Easy: get display, sound, cellular, sensors, inputs working

Harder: (efficient) Power management, App ecosystem: distribution, SDK, compatibility, (tight) Privacy controls, (robust) Update delivery system, (vast) Hardware support, Backward compatibility, Accessibility, Localization, Customizability, Camera (apparently)

Beyond tech:

Proprietary hardware drivers: how do you get the hardware manufacturers' commitment to allocate their engineers to write drivers for the open phone system? Reverse engineering requires more effort and is not very sustainable.

Carrier requirements: Supporting and testing emergency services, lawful interceptions, certifications, possibly differing requirements for each carrier and regions.

Regulatory compliance: Constantly changing requirements by nations and geographical regions.

--

Reading from the other comments, power management seems very hard to get right.

The non-tech reasons seem to be the most challenging; it introduces the most complexity and it's not exactly something that can be achieved by a passionate person in an evening

I have been using itunes/music to do that and it honestly works just fine. I have hundreds of playlists from over 10 years ago that still works. Finding specific playlist or music to play is pretty easy, especially with Alfred.

The longevity is the biggest concern to me when considering the third party apps. If it stops being maintained in the future I would be stuck and need to do the chore of moving them properly to another application. With the native app I am sure it will work for the next 20 years.

Adding a sample trip might help a lot to give an idea of how to use it.

Inputs feel tedious and not smart enough; so much that it feels to get in the way instead of helping.

Activity date input shouldn’t be free date input; I inputted the start and end date earlier, couldn’t that be used to help limit the input range? End date/time feels tedious as well, it could be a duration input instead (eg 3h at this location).

It also lacks some extra planning features, like pooling the list of locations to visit (no dates yet), for later to be scheduled if it ends up interesting.

Personally I would remain using Wanderlog..

Semicolons bring the drama (that’s why I love them)

Semicolons bring the drama — that’s why I love them.

The semicolon somewhat works here but IMO not the best use of it (though perhaps intentional, to bring the drama).