Wow, I was wondering if e.g. Ghostty could implement something like this but that's cool it's already proven out.
Does everything still go "through" tmux (so parsing etc. is still done twice), or does iTerm handle most of the rendering and just delegate scrollback storage/session persistence to tmux? The latter seems like the best of both worlds.
So am I identifying the bottlenecks that motivate this design correctly?
1. Go FFI is slow
2. Per-proto generated code specialization is slow, because of icache pressure
I know there's more to the optimization story here, but I guess these are the primary motivations for the VM over just better code generation or implementing a parser in non-Go?
Tried starting a "run every day for a year" initiative last year. Wish it was for me, after 42 days I realized that I actually actively despise running and spend most of my time not running dreading the next one. Easiest habit I've ever dropped :(
A couple weeks ago, one of my physical stick of RAM completely stopped working after yet another Linux out-of-memory-force-poweroff situation. No idea if that could be the proper cause, but I do find it a little funny.
I just arrived at this thread after my entire system stalling completely at yet another low memory situation.
Let's just say I'm extrememly grateful to discover some of these userspace early OOM solutions in this thread.