skhameneh

I wouldn’t say it’s better, because that’s very subjective, but it is more “feature complete”. Alacritty is very minimal and rejects community PRs for features often driven by their general ethos. libghostty supports a lot of features I don’t foresee making their way into Alacritty.

I use Alacritty and GNOME Terminal. I don’t have a great reason for not using or trying Ghostty other than I have a minor aversion to Zig. (Again, not a great reason and arguably a not good reason)

Well they did pull back on ZDR a few times and at least Anthropic has made their arguments (that I disagree with) that model outputs, no matter how much user context was fed, do not fall under their definition of "user data".

Are these prices subsidized by user generated outputs? Can I even trust any answer to not be carefully worded and rephrase the response to "user data"? Even so, what's to prevent some "oops" event that seems to be all too common? At least some months back Bedrock seemed to be properly isolated, but I've heard of many getting non-ZDR notices for new models.

This made me laugh, I have no idea if this was LLM assisted (I'm assuming not) but also I really don't care (because it gave me enjoyment).

I find it so weird the wall mounted version is a different product, it seems like a lost opportunity to do more interesting things with a speaker base.

Reading the “paper”, this is just a job runner built on Ollama. Exo, and the teams at Apple that built the foundations Exo uses, actually use modern distributed compute.

Other commenters are suggesting you can’t blame the spec for end implementation mistakes, except that’s one of the many issues - JWT being so error-prone is a problem.

I use JWT just for handling of tokens, because it’s so well supported, but I won’t use it for anything more than token storage _because_ it is so vulnerable to mistakes.

The fact that mistakes are so easy to make is indicative of poor design in the spec itself.

This is a bit nuanced, because if there’s redundant constructs then that does impact maintainability and efficiency with both runtime and LLMs working with the code.

I’d push this more towards personal preference of how code is expressed matters much less now than how maintainable it is.

There is the aspect of long type names, they often don’t have much impact when tokenized. The character count of words is nearly negligible - they often become one or two tokens anyways. But, the choice of words may have a greater impact on how the word choice weights an LLMs contextual processing of that word (a human may be able to ignore an inaccuracy in naming a bit more flexibly than some LLMs).

There's a number of comments already about how this page looks vibe coded, I'd add that I'm actually shocked at how much this looks like the output of a one-shot prompt. It's not so much that an LLM was used, but a callout on just how generic this page is. How much iteration went into this? At surface it looks like nearly no iteration.

Edit: Well, they just re-vibed it. Went from the most generic Claude 4.6 era to today’s models, quality wise. I wish I had saved a copy of the original, because it would have taken me actual solid effort to make a page that generic out of an LLM.