You may be relieved to hear that there's a straightforward process to have an RFC revised. Step 1 of that process, however, is reading the the RFC and the archived email about the RFC.
You can't just arrive after publication, ignore what others said before you, and expect anyone to listen to you.
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?
How fast my terminal can print 10000 lines is pretty far down the list of requirements I have, who cares as long as it is fast enough? To me it is as irrelevant as who has the best unicode support.
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.
You are right that the simplicity of the state file is a strength and we do not want to lose that. One of our goals with Stategraph is to make state just as easy to inspect through both the command line and the UI.
Not every Terraform setup runs into scaling pain. The trouble tends to show up in larger repos with thousands of resources where teams share big chunks of infra. That is where global locks and full refreshes become a bottleneck and where we think graph semantics help.
This is a bit worrying, though. Do you mean through regular tools like cat or vim, or do we have to install a stategraph-manager tool (and upgrade it ad nauseum) just to look at the state?
predict is the operative word there, because Terraform is so disconnected from the underlying provider's mental model that it is the expression "no plan survives first contact with the enemy" made manifest
Now, I am one million percent open to the pushback that "well, that's a provider's problem" but I also can't easily tell if they are operating within the bounds of TF's mental model, or is it literally that every provider ever is just that lazy?
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
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.
My big gripe with Music is that big butt-ugly modal ad they prompt you with if you're one of the billions of humans that don't pay for Apple Music: https://discussions.apple.com/thread/253368403
It's something I'd have expected out of Microsoft, but from Apple it's a particularly shitty gesture. A big warning sign to the user that "your" device hasn't been fully paid-off yet.
> The longevity is the biggest concern to me when considering the third party apps.
And that's why I had to stop using MacOS entirely. It's absurd for a culture of paid software to have such horrible runtime compatibility. Meanwhile on Windows, you don't ever buy software that stops working. Even Linux has largely circumvented it's own ABI woes with sandboxed packaging. MacOS's statically linked app framework has every advantage in pushing out support timelines as far as Apple wants - they just don't want to push it very far, sadly.
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.
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.
> The error wrapping(s) produce a log line containing a brief message from each layer in the codebase that expected no errors — subtle difference
Agreed. How I articulate it, often a function is just another layer, does one core thing and one-two extras. I wrap meticulously the errors of the extras. The core errors mainly speak for themselves, so they rarely need any wrapping.
Avoids:
cannot load config: cannot load config: cannot load config: file not found
Mind boggling