My question, not clear from the front page, was if it runs faster on MacOS than colima with vz. Full benchmarks claim that it does.

So that's interesting. The offering of container runtimes (also thin VMs in general) on MacOS has been improving a lot.

Didn't read the post but two observations:

1. The AI disclosure up front is very useful for cutting my blog filter time from 10 seconds down to 1, which is significant in the age of content overload. Hopefully disclosure becomes a point of pride for vibebloggers and they'll add it more often.

2. While it makes sense that the popularity of TUIs (driven mostly by CLI coding agents) sees maintainers try and push more spec into emulators, I'm hoping this doesn't become the standard. The whole TUI mentality just runs counter to what makes terminals such sticky tech in the first place.

1. I doubt anybody on HN has any interest in what your personal criteria are for reading blogs. Please, please, please let's stop polluting the comments with arguments about how a piece of software was made instead of about the thing itself.

2. I agree if you refer to TUIs that try to emulate/substitute complex GUIs, with sub-panes, dialogs, graphics, etc. I happen to love TUIs for simple text-only visualizations, though. They are usually quicker than GUIs and consistent among various OS, desktop...

> Please, please, please let's stop polluting the comments with arguments about how a piece of software was made instead of about the thing itself.

But it IS relevant how something was made! It tells us how much of the detail that's presented in code & blogpost is the authors intent, and how much of it is "filler". It tells us whether the author can answer detailed question as to why they chose a specific implementation, or novel technique, or not.

It tells us whether the author wants us to read every syllable, or whether readers are expected to let their own summarize the article for them instead (as would be the case here).

It's never worth it to spend more effort reading something than the author spent writing it. The important part is the human intent, not the filler surrounding it!

Your reasoning could be applied word by word to the latest novel by Stephen King. I may know that it has been written by an army of mercenary ghost writers and nonetheless enjoy it and warmly recommend it to all my friends. Judge a book by its content, not by its author. Do the same for software.

So you enjoyed a book written as a collaborative process between multiple human writers and somehow this is an argument to have less humans involved...?

I would rather frame it as an argument against credentialism.

I'm specifically referring to maintainers trying to get new protocols (like border draw calls) into emulators. As these TUI frameworks grow in popularity itincreases pressure on emulator maintainers to support their proposed spec. There's some TUIs I like myself but these generally respect and try to work around the limitations of the terminal. When emulators start shipping with boatloads of TUI-enabling functionality they stop being emulators and start being app frameworks (arguably hard to decide where to draw the line, and everyone will draw it somewhere differently. I draw it in its own cell)

Snark and a winky face emoticon really negate any insight you could have provided here. These types of comments are becoming too frequent here.

No one said don't do anything new. Multiple people said that a proposed new feature to a standard should have proved value, and that patching a standard and its related tools could be a sign the feature isn't as needed as you think.

That's useful feedback to audiences developing against, consuming, and even writing those standards.

> Snark and a winky face emoticon really negate any insight you could have provided here. These types of comments are becoming too frequent here.

I added the ;) after posting to indicate some amount of good humor. Feel free to read it how you like, but I'm not here to provide insight to someone that literally said they didn't read the post as their first ever comment on this site. Was this your alt?

> No one said don't do anything new.

No. It's literally the first line of the comment I replied to:

> I'm specifically referring to maintainers trying to get new protocols (like border draw calls) into emulators.

> Multiple people said that a proposed new feature to a standard should have proved value, and that patching a standard and its related tools could be a sign the feature isn't as needed as you think.

For some actual insight - I don't think that requiring a standard to have proved itself is a good place to be here. It's literally what I'm asking for here. Find a way to prove this out. Does it work, does it fail in some bad ways. I don't care about the 'make this a standard part'. I literally wrote "I'm not attached to this being the exact solution, but I think it's a problem worth solving, and I'd like it to be more than one terminal's feature (and more than one weekend's worth of yak shaving)." in TFA.

We're living in an age where experimentation is cheap. We can look at ways to find out if these things are valuable by trying them. My blog post isn't about making a standard a standard, we're a long way from that here, it's about working out if it's something people would find interesting and useful in the terminal. As a library maintainer in that space, having seen many many terminal user interfaces, I feel identifying gaps like this is a necessary part that makes things move forward. One thing to note is that experimentation down a path doesn't mean that that path will be accepted / used / useful. We do that in software all the time - HTML blink tag, DHTML, Java Applets, ...

For the record I do think ratatui enabled some really nice terminal apps. There's a use case for it. But yes I do think terminal emulators should move slowly. Definitely not at the speed of AI. Reasonable people can disagree.