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?

Not one of them links to the actual well-known resource, only pdf specifications. And several I picked randomly leads to dead ends.

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

But how does one even find this?

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.

> What's the hardest part about an open phone?

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

Feels like none of what you wrote is about how the native app compares to the app being discussed, Petrichor, which is an offline music organizer/player.

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.

Weird outrage

You gotta add debouncing or disable the button(s) once clicked and are pending for results; got several email codes and random errors because I clicked again thinking the button(s) didn’t work

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

I would add a small asterisk that a given sentence may result in different number of tokens depending on the model and the tokenization method they use, so it’s unfortunately not as straightforward to get the precise dollar value for a given input.

Stack trace is much more verbose and shows the symbols leading to the failing function call The error wrapping(s) produce a log line containing a brief message from each layer in the codebase that expected no errors — subtle difference but one is a dump and the other is much more meaningful.

Agreed, I would have used either em dash or parens here:

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

My understanding is that on the darker scenes (say, 0 to 5 in the brightness slider example), there is difference in luminance value with HDR but not SDR, so there is increased contrast and detail.

This matches my experience; 0 to 5 look identically black if I turn off HDR

Yes but with asterisks; Best way I can describe it:

You know the 0-10 brightness slider you have to pick at the start of a game? Imagine setting it to 0 and still being able to spot the faint dark spot. The dynamic range of things you can see is so much expanded.

Early HDR screens were very limited (limited dimming zones, buggy implementation) but if you get one post 2024 (esp the oled ones) they are quite decent. However it needs to be supported at many layers: not just the monitor, but also the operating system, and the content. There are not many games with proper HDR implementation; and even if there is, it may be bad and look worse — the OS can hijack the rendering pipeline and provide HDR map for you (Nvidia RTX HDR) which is a gamble: it may look bleh, but sometimes also better than the native HDR implementation the game has).

But when everything works properly, wow it looks amazing.

Just because you are out of the loop does not mean it’s meaningless — in some spaces the term is very straightforward and concise

I’d cut down the snark; this news aggregator is not built for you specifically, there will be many things that you are unaware of and I don't think they should be met with snark (there must be some reason why people invent a new term for it; in this case, it is to refer specifically to an animated avatar rigged to a face (or body) camera usually for a video streaming activity. Usually it is comprised of many moving components and assets, a PNGtuber works off a single PNG file, and thus easier/cheaper to get started with).

I’ve personally replaced about 2 out of 5 searches with chatgpt queries so I do believe it’s in the right direction

I think the first paragraph while true is not indicative of anything since it can be fixed and improved

If it is a new site, you can automatically choose.

If it is a site that already existed, do not make it automatically switch. Consider adding the option to switch instead.

If you insist nevertheless, then the ability to select the color scheme explicitly is absolutely mandatory.

I am using bitmap font with AA off in Terminal.app so this is incorrect

That bugzilla thread was quite a read! Thank you for sharing

Have to disagree

These critical features you mention are just nice-to-haves for me and I imagine most people as well. I am able to read and navigate fast on github.com. I think majority of code I read happens there and not in my IDE.

The shortcuts to navigate fast can be quite obscure but the capability is there, out of the box. In particular I like the t hotkey for the repository filesearch (this more often than not removes the necessity to click through directories) and the codesearch is just impressive.

if your network is compromised I can read your password but not totp

if I hacked a website you’re registered to and you had reused your password I got your password but not totp

if I broke through your computer and password manager then yes it’s all over, but this is not the only threat model and frankly the least i am worried about

Yes — because 2FA is commonly stored on a separate device (phone), people are very quick to conclude that it is pointless otherwise without thinking further.

Even if it is stored in your password manager, it is still useful. Consider the case where your network or website is compromised: the password is compromised and can be reused, but the totp 2fa that is in your password manager still prevents login by anyone who obtained your password. There are many attack scenarios but storing 2fa and enabling autocomplete definitely does not make it useless.