This is an intresting take and the ”tooling” around pure llm-based code generation is what really matters.

AFAIK Replit and Claude code has way to reduce the rate of these kind of errors, but I havn’t deep dived into how.

Interesting project!

Two problems for me:

- I want my iPhone terminal to be built for use w/ external keyboard.

- While I really like pay-once a use-often app like a terminal you really want to try before you buy. But maybe Apples general refund-if-not-satisfied is still a thing and enough?

It says "full hardware keyboard support" in the blog post, but its not a headline so its easy to miss.

Echo works great with an external keyboard fwiw. My daily driver is using it with the iPad and keyboard

Yes, such a good game! :)

Gonna warm that up when the kids get a bit older and we start doing LAN parties.

That and Quake World Team Fortress.

Try XFS if you havn’t yet.

Very solid and no such issues.

I haven't used XFS in almost two decades, does it have compression support in the same way? Also, does it do JBOD stuff? I know it's a bit of a different thing, but I really enjoy the pool many disks together part of Btrfs, although it has its limitations.

XFS doesn't have inline compression, nor does it have volume management functionality. It's a nice filesystem (and it's very fast) but it's just a filesystem.

No compression.

Agreed!

It easy to forget we all started fresh and learned a lot the first few years.

On topic, this project looks nice but a bit too featureful for my minimalistic taste.

Thanks for the kind words and for the “beginners” encouragement—totally agree, it’s easy to lose sight of that!

I get the point about feature creep. I started “small,” then kept adding features as a way to learn and push my limits. My goal is to keep the design modular enough so people can use just the parts they need.

If you (or anyone else) would be interested in a stripped-down mode or a build with fewer features, I’d love to hear what that would look like to you!

Thanks again for the thoughtful feedback.

Neat concept and very inspirational.

Is ascii/unicode text UI the way to go here or is there other UI formats even more suited for LLMs?

It has to be suited for human consumption too though.

I wonder if this has any real benefits over just doing very simple html wireframing with highly constrained css, which is readily renderable for human consumption. I guess pure text makes it easier to ignore many stylistic factors as they are harder to represent if not impossible. But I'm sure that LLMs have a lot more training data on html/css, and I'd expect them to easily follow instructions to produce html/css for a mockup/wireframe.

LLMs are surprisingly good at extracting data from other data, so at the end of the day there is no right or wrong, it's what works best for you use case.

Bellard is such an inspiring programmer! A few of my favorites out of his works are:

- qemu user mode

- tcc

- ts_zip

Looking forward to giving this a try, especially on my first gen Raspberry Pi! :)

What are the reasons behind going with GPL-2 instead of a more permissive license like MIT or 0BSD?

You will probably at minimum build some neat helper functions and maximum code reuse is IMHO the best thing for the world.

I would for instance be curious on the ANSI routines but hesitate to invest mental energy when the code has limitations on usage.

Lastly cool to see new open source programs being built with heavy help from a code generation model. Inspiring!

I need to think about that still, you raise a good point. I'd like people to be able to use parts of the source pretty much freely, but I wouldn't want someone to replicate the entire editor as a proprietary closed-source product.

The GPL is still a great choice, keep software freedom for the users not the corporations.

Good advice!

And no need for -X GET to make a GET request with curl, it is the default HTTP method if you don’t send any content.

If you do send content with say -d curl will do a POST request, so no need for -X then either.

For PATCH though, it is the right curl option.

I really like just encoding each object as JSON and then concatinating them with a new line between.

Allows parsing and streaming without any special libraries and allow for an unlimited amount of data (with objects being reasonably sized).

Usually gives these files the .jsonlines suffix when stored on disk.

Allows for batch process without requiring huge amounts of memory.

Me too, and it's quite a common technique.

https://en.wikipedia.org/wiki/JSON_streaming

jq allows to covert normal json document to jsonlines and back, though it does it much faster if it can slurp an original doc into memory (no --stream option)

Based on this thread that's called NDJSON

Newline Delimited JSON

TIL

It's also known as JSONL (JSON Lines).

I'm pretty sure jsonl was a bit earlier as a term, but ndjson is now the more prominent term used for this... been using this approach for years though, when I first started using Mongo/Elastic for denormalized data, I'd also backup that same data to S3 as .jsonl.gz Leaps and bounds better than XMl at least.