eschatology

in macos it is trivial to input em dash in any context

Thank you, that it is part of OIDC provider discovery spec explains a lot.

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?

I spent 10 minutes searching for one in the article, in the RFC, in the wikipedia page, on google, to search for a .well-known example. Couldn't find one.

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.

As with sibling comment, it's my first time reading this, it's a great read, and author really managed to write down into words some things I have vaguely thought about before.

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.

title is too biased and sensational

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.

Did you read it?

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

Because new user, ostensibly bad faith, throwing short cliched statements with no clear intent to start a meaningful discussion.

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.

These ai authorship accusations are now everywhere and it's getting really annoying.

It just distracts the discussion away and adds nothing.

Exactly the attitude described by GP comment

Mind boggling

While the article title is true (errant is a very specific and concise word), to me it did not convey clear enough that this is just ucs-detect / unicode support (compliance?) ranking. The article title "State of Terminal Emulators in 2025" implied a larger comparison of terminal emulators than just ucs-detect.

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?

With rubber products, it’s usually the plasticizers leaking over years. I have learned this the painful way (massive migration of plasticizers from the underside of my mousepad to other things), and now actively avoid any rubber products, usually in favour of silicone instead.

Hmm

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.