It is.

Wow.

I think that that's the point.

Optimal intelligence would know.

What can Sixel do for me? Any interesting examples?

It can display images in your terminal. This is made pretty clear by the first paragraph on the page and also by the Wikipedia article it links to[0]; I'm wondering what else you're asking for.

[0]: https://en.wikipedia.org/wiki/Sixel

Interesting use cases. Can TUIs benefit? Any prominent examples?

Yazi, If, and Ranger file managers use it to display images inline. Euporie allows you to run a graphical Jupyter console session.

Sixel is a very old standard and has been used to display graphics in terminals since the 80s. It fell out of favor when high-resolution bitmapped desktop environments became mainstream (and affordable), but it is still useful if you are doing remote console work and don't want to set up network hoops with ad hoc HTTP servers just to view a remote diagram.

Feels to me like it violates the only real assumption for a terminal.

Which is?

Everything is text.

People have been drawing ASCII art since ASCII was invented, and control codes like the bell "character" existed even before computers did.

Which is still linear text all tools work with.

What's your definition of "text"?

(I define it as "written words in a human-readable language". You must have something else in mind, because neither ASCII art nor control codes fit my definition.)

A linear stream of non-null characters, the majority of content being printable glyphs.

Tell that to something as fundamental as ASCII 0x07!

That's assuming you don't separate concerns in your monolith into modules with clear boundaries and dependencies. If you did that from day one, splitting a module off to a different service is easy.

If you can manage that then there's no real benefit to microservices though. The reason for splitting is to solve the problem of failing to separate concerns, so a team that can't do that well is better off building microservices from the start because the alternative for them is building a monolith that will be hard to split.

That's my belief as well: modular architecture and separation of concerns is orthogonal to monolith <-> microservice infrastructure axis.

And Service Oriented Architecture is the nice middle ground of that infrastructure axis

I don’t agree. The technical device we use for creating clear boundaries, useful abstractions and managing dependencies in monolithic code is the function/method/procedure call.

The history of distributed software is littered with the corpses of attempts to make the RPC look like a function/method call (I worked for a CORBA vendor decades ago). But these two techniques are so different on a fundamental level they are not substitutable except in the most trivial cases. The compute and elapsed time RPC overhead which makes perfectly good local abstractions completely impractical across a network. And then there are the differences in terms of failure modes, concurrency and synchronicity.

So even a beautifully designed and layered piece of “monolithic” software with a code base costing of coherent and clean abstractions will not be easy to port to a microservices/distributed architecture.

Oh wow, I thought those were stars at first.

AI can be used to write E2E tests, unit tests, etc. The issue I find is that I would like a different model with a different context to design and write the tests. I haven't found the right technical solution to this yet.

When models write both the code and the tests, they might go back and forth between the code and tests until they reach a working solution. This seems dangerous.

Thanks. I hate it. I just want my agents to be able to read and edit messages and canvases on Slack.

What are your plans for actions, workflows, checks, etc.