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.
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.
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.
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.
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
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