Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

github.com

Post reply on HN
Print view View original

121–130 of 168 posts

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#121

Post by tdeck »

nine_k wrote: post #72
3eb7988a1663 wrote: post #26

Gutenberg's copy of Moby Dick is 1.2MB[0]. Which is to say the slowest benchmarked terminal could display a paltry ~53 Moby Dicks per second, while shitty gives you ~98 Moby Dicks. I am not sure how many Moby Dicks I require per second, but it is good to have options. [0] https://www.gutenberg.org/ebooks/2701

Mere 25-30 years ago I saw some very chatty Java builds run faster if the terminal window was obscured or minimized. Slow console output held back the compilers.

In about 2013 I was an intern at Microsoft and my mentor showed me that if you were running something that streamed a lot to the terminal, it would run faster if you covered it with another window (but didn't minimize it, for some reason I don't recall). I was surprised this kind of trick was still a thing.

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#122

Post by teo_zero »

naikrovek wrote: post #87
fishgoesblub wrote: post #51

> 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…

I'm confused. You begin your post with a stance that's typical of copyleft proponents, then you end it in the opposite direction.

There is a trait in human nature that pushes us to share our knowledge. But we would like this sharing to be mutual.

When I publish a piece of software for free, I would like others to read it, comment it, give me suggestions on how to make it better, and the whole community can benefit from the process.

Unfortunately, someone might instead take it, start making profit out of it, and never giving anything back to me or the community.

As a device to get the former effect and avoid the latter, a sort of "contract" was created that mimicks a copyright licence. It is called copyleft and says that you can do whatever you want with my work except profit.

Now, someone might say that stopping a third party from profiting out of something they have not made is correct, someone might say it nevertheless means removing a freedom from them.

Whose side are you on?

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#123

Post by tdeck »

pg83 wrote: post #93
jcelerier wrote: post #90

> 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.

Seems like a missed opportunity to use a license more aligned with the project's naming convention.

https://www.wtfpl.net/

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#124

Post by chowells »

cyanregiment wrote: post #71
egeuvuvy6 wrote: post #60

Earlier quoted context omitted.

I once took around two weeks worth of evenings to get my zsh startup from 300ms down to 50ms because it felt laggy. Fuck nvm btw.

I remember the infamous 300ms delay on tap when smartphones first came out. It matters! There is some number of fps where "the human eye can't tell the difference" I bet there is one for ms delays

Yeah, there's actually been a lot of research on that. 100ms is generally considered to be the threshold between perceiving a delay or not. But even that needs some additional context. That's the threshold for feeling like you're waiting to get a response after completing an input. But a 100ms round-trip delay on a mouse cursor would feel like you were using a broken computer. And when you're doing something where you're used to continuous feedback from your input, you can sense incredibly small changes in the response time. +/- 10ms from what you're familiar with is noticeable for almost everyone. There are people who consistently notice half of that - but remember that's in the context of difference in latency of continuous feedback. 100ms is a pretty good rule of thumb for the threshold of "why am I waiting for this?"

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#125

Post by entrope »

chowells wrote: post #124
cyanregiment wrote: post #71

Earlier quoted context omitted.

I remember the infamous 300ms delay on tap when smartphones first came out. It matters! There is some number of fps where "the human eye can't tell the difference" I bet there is one for ms delays

Yeah, there's actually been a lot of research on that. 100ms is generally considered to be the threshold between perceiving a delay or not. But even that needs some additional context. That's the threshold for feeling like you're waiting to get a response after completing an input. But a 100ms round-trip delay on a mouse cursor would feel like you were using a broken computer. And when you're doing something where yo…

100 ms might be a good threshold for a lot of purposes, but for when refresh, 30 fps is painful to use compared to 60 fps: it is extremely noticeable when moving windows, but I'm old and can tell the difference even just moving the cursor. (Others will say the same about 60 fps compared to 120 or 144 fps.)

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#126

Post by pjmlp »

joncp wrote: post #30

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.”

I would still use xterm, don't really get the craze out optimising tty emulators.

Now graphical nicely powered REPL environments is another matter.

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#127

Post by pjmlp »

wavemode wrote: post #97
joncp wrote: post #30

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.

Regardless of all the twitter and Github drama, it was fast enough for me, and I don't get what is the interest running HLSL shaders, pets extensions or rainbow colours on the terminal.

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#128

Post by potamic »

pg83 wrote: post #94
pg83 wrote: post #93

Earlier quoted context omitted.

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 fro…

It does seem to be quite some (very boring) work. I'm curious about your reasons for taking it up. Is it more of a principles kind of a thing or do you see it could make a difference to the project in the end?

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#129

Post by pg83 »

potamic wrote: post #128
pg83 wrote: post #94

Earlier quoted context omitted.

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 fro…

It does seem to be quite some (very boring) work. I'm curious about your reasons for taking it up. Is it more of a principles kind of a thing or do you see it could make a difference to the project in the end?

At the very least, the ability to use the code as a library. A library under the GPL3 is unlikely to be popular.

Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

#130

Post by pg83 »

d3Xt3r wrote: post #114

Is implementing sixel, kitty graphics protocol and the kitty keyboard protocol in future scope at all? Because without these, it's not really fair to compare Shitty with other (modern) terminals.

There are no plans for this right now. I don't use graphics in the terminal myself, but if there's a need, why not?
Post reply on HN