Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • It is still slow.

    Honestly I do not understand those last ten years craziness about 'new-native-gpu-turbo-ultra-xhigh-max-terminal' <insert current trend here>.

    (my) battle tested urxvt under X11 is STILL faster then shitty (and all others):

    ## ascii (95 MiB cat, best wall of 3)

    | terminal | wall | user | sys | throughput | |---|---|---|---|---| | urxvt | 0.78s | -s | -s | ~122 MiB/s |

  • This is obligatory read: https://blog.royalsloth.eu/posts/it-takes-a-phd-to-develop-t...

    Later, Microsoft fixes the issue but fails to give Muratori credit. After backlash, they went back and gave him a footnote: https://devblogs.microsoft.com/commandline/windows-terminal-... (atlas release section)

    GitHub thread in question: https://github.com/microsoft/terminal/issues/10362#issuecomm...

    And this gem: https://github.com/microsoft/terminal/issues/10362#issuecomm...

  • There was also the video where he did write the doctoral research project in a weekend.
  • I will forever love reading or watching Casey dunking on people from so far above that they’re unaware of the delta.
  • What's the boot time for shitty?

    I can't use half of the terminal emulators because theyre so slow that after hitting my key bind to open them and I start typing half of the first word is missing.

  • I don't know, I haven't measured it. For me, it's "instantaneous" enough that I don't have to think about it.
    by pg83
  • Unironically better name than “CRM“ for a CRM https://news.ycombinator.com/item?id=49142360

    With this you can DuckDuckKagi for the crappy terminal (versus “CRM crm”… ah guess they wanted you to remember their company name)

  • Except others are already using it, with proper capitalization.

    https://github.com/fearlessgeekmedia/shiTTY

    This one just tried to reserve the name with an empty repo a year ago... probably where the LLM got the name.

    https://github.com/immz4/shitty

  • 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

  • Why did you make this comment? It's completely off topic.

    Your appeals to authority do not apply when the author is clearly telling you not to use it for that. We're well past the point where this kind of software eventually ends up under corporate use policy or any policy at all.

  • Given git is all over the corporate world, I say this is less of an issue than you make it out to be.
  • I assure you, this is a very professionally made product:

    - we have 5,000 tests covering all aspects of terminal behavior

    - we have address sanitizer and ub sanitizer runs of these tests

    - we also have regular fuzzing!

    - we even monitor code coverage

    This is definitely a top 0.1% GitHub project in terms of development approach.

    > and neither will it help with getting it installed on corporate networks.

    I'm fine with it.

    by pg83
  • Given the memory-unsafe vice signaling, maybe this can become the official terminal of Fox News and the Department of War.
    by wmf
  • > 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.

  • He took zutty (GPL licensed), shitted some claude on it, then released it MIT. A license violation, but not like it matters, since it will end up in the same heap as every other bozo's vibeslop. It is aptly named.
  • 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.
  • I keep going back to xfce-terminal after trying anything else. Ridiculously small footprint and never drew attention to itself.
  • I would still use xterm, don't really get the craze out optimising tty emulators.

    Now graphical nicely powered REPL environments is another matter.

  • Right? I have always just used whichever terminal came with the Linux desktop I was using at the time. If anything, the terminal is already the smallest and fastest gui app I have open.

    I ask this question often in the comments when a new "blazingly fast" terminal is announced and after years of doing so, have yet to read an actually practical answer that applies to modern systems.

    My guess is that some people just enjoy the process of optimizing well-understiod low-stakes graphical stuff.

  • Terminal.app is amongst the best, if these old danluu benchmarks still hold https://danluu.com/term-latency/
  • IME, usually you care more about latency than throughput for normal interactions, and there is a noticeable difference between the slowest ones, and the fastest ones, but I've tried a lot of terminal emulators, and any of the ones that put some effort into performance are plenty fast enough.

    However, there is one case when throughput matters: when an application has a lot of output. But then the problem isn't the speed that it displays the text, it's going by too fast to read anyway, the problem is that the application can be slowed down by blocking on writing to stdout when the buffer is full. And honestly, the best approach in that case is probably not to actually render all the text, but send most of the output straight to the scrollback buffer, and only render some of the frames.

  • Speed itself may not be very important, but it is a very interesting challenge in itself - to prove to yourself that you can surpass the state of the art!
    by pg83
  • 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 initial window. It makes using my pc a lot more comfortable.
  • This is cool, but I gotta say - I care much more about keypress-to-screen latency on my terminals than throughput - would love to see some numbers on that.
  • If you truly want low latency input on a Mac then your Terminal app needs to be able to run full screen to enable Game Mode: https://support.apple.com/en-euro/105118
  • 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 other words, I'm provably doing the minimum amount of work possible. Unfortunately, this isn't possible on MacOS, since the Metal documentation states that it can (and does) corrupt a buffer while displaying it.

    Basically, based on code, not actual measurements, shitty is the best terminal in terms of change delivery latency.

    by pg83
  • > 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.

    by pg83