Because I don't need to. I've never even once thought "my terminal feels slow and I want to find a different one". My terminal (xfce4-terminal) also uses a GUI toolkit that makes it visually fit in my desktop, and I like that. Regardless, sometimes you just gotta write some code because there's an itch that needs to be scratched. Sounds like this author really wanted to see if he could write a super fast terminal, an…
> I've never even once thought "my terminal feels slow and I want to find a different one"
It's VERY difficult to measure. But I can say that shitty has the best damage tracking model among foot/kitty/alacritty/ghostty. It's best in the sense that it's cell-exact; I only draw to the screen what has actually changed. Furthermore, on Linux, I reuse buffers from the swapchain after the wayland compositor returns them, and I only update the areas that changed after I sent the buffer to the window system. In ot…
> I'm provably doing the minimum amount of work possible. That is a very bold claim to make for the amount of render code generated by the LLM. It's not obvious what the critical path even is, which is what would bound the latency. And I mean actual code, not just some informal description of what happens.
Expert opinion versus expert opinion. I will probably stick to my point of view and suggest that you either offer a benchmark or show a specific problem in my code, without speculation on the topic of LLM.
> Shitty is moving from the imported GPL baseline to an MIT-only codebase. It does not intend to retain the GPL as the final project license. that's really something that cannot be done if you don't have the original right of the code. It's 100% derived work and thus has to preserve GPL license, even if you rewrite every single line.
I'll probably stick to the perspective expressed to me by the lawyer (I actually consulted on this topic), rather than the opinion of some random "GPL zealot" on the internet.
The procedure described has been done many times, is well described, and is quite feasible, albeit quite complex.
I think I can handle it!
And, in any case, anyone who wants to can sue me in a real court, not an online one.
> Shitty is moving from the imported GPL baseline to an MIT-only codebase. It does not intend to retain the GPL as the final project license. that's really something that cannot be done if you don't have the original right of the code. It's 100% derived work and thus has to preserve GPL license, even if you rewrite every single line.
I'll probably stick to the perspective expressed to me by the lawyer (I actually consulted on this topic), rather than the opinion of some random "GPL zealot" on the internet. The procedure described has been done many times, is well described, and is quite feasible, albeit quite complex. I think I can handle it! And, in any case, anyone who wants to can sue me in a real court, not an online one.
The procedure is quite simple in principle: each new contributor confirms their permission to use their code under two licenses—MIT and GPL3. After a while, the entire codebase becomes dual-licensed. At that point, I leave it as is and (tentatively) copy the MIT portion to another location. Yes, the derived work will still remain under the dual license, and therefore under the GPL3 as well, but no one can stop me from copying the MIT portion, which, by coincidence, will cover the entire project. This isn't relicensing; it's rewriting it under a dual license.
Going by the childish naming of the project, it doesn't inspire confidence in the professionalism of the author going forward, and neither will it help with getting it installed on corporate networks. I'm all for vulgar wit but this isn't that (yes I'm aware of the -tty convention) & just reinforces the cliche of tech skills inversely proportional to social ones
> and neither will it help with getting it installed on corporate networks
This might not be something the author cares about. Compliance with corporate policies is certainly not something I've prioritized when giving away open source software for free.
Nice work! I do wonder, however, whether people really have issues with perf on any terminal emulator in 2026 I’ve been living in Terminal.app / zsh / tmux / vim for 15 years and have never once thought “this is slower than I want.”
the new Windows Terminal had horrendous performance when it first came out. in the aftermath of the drama surrounding that, was when I first started seeing a lot of terminal emulator projects bragging about their throughput.
Nice work! I do wonder, however, whether people really have issues with perf on any terminal emulator in 2026 I’ve been living in Terminal.app / zsh / tmux / vim for 15 years and have never once thought “this is slower than I want.”
To me, the most relevant aspect is the time it takes to open. I can't believe how slow the startup time in common linux distributions is by default, it's so annoying, by the time it opens I already forgot what I wanted to do. Alacritty has this cool feature where you only ever have to "open" a single terminal, whereas new windows can be created very efficiently with `alacritty msg create-window`, being forks of the i…
Foot is instant. Ghostty takes ages. I don’t know why there’s such a difference, but I can’t use anything slower than Foot now without getting annoyed.
> Shitty is moving from the imported GPL baseline to an MIT-only codebase. It does not intend to retain the GPL as the final project license. An interesting, and disappointing choice. Shitty, one may say.
I never understood this stance. I’ve heard this for 30 years and I still don’t understand why people feel entitled enough to enjoy the benefits of someone else’s work without giving anything back. Forcing someone to release their code for free isn’t freedom, that’s a lack of freedom. Oh, you want the code to be free. Well guess what? MIT licensed means you can have it. Oh, you want a third party’s changes to be made…