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

141–150 of 168 posts

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

#141

Post by cyanregiment »

entrope wrote: post #125
chowells wrote: post #124

Earlier quoted context omitted.

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

One of the reason they gave CSS access to the GPU I guess - it would be so choppy without it

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

#142

Post by mrtesthah »

p1necone wrote: post #38

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

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

#145

Post by moderation »

monstar [0] from rockorager is an fast Wayland that leverages libghostty. It is easy to build from source. I can't build shitty from source on OpenSUSE Tumbleweed. Tons of issues with Ragel versions and flags and linker issues. All dependencies are installed.

0. https://github.com/rockorager/monstar

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

#146

Post by zamadatix »

pg83 wrote: post #8
yjftsjthsd-h wrote: post #5

> The executable is named st; the desktop application and icon are named shitty That conflicts with the already existing suckless st. Also I am suitably impressed with the perf numbers, but I also somewhat take away that I could stick with (at least) alacritty or ghostty and not be much slower.

I know, but there aren't that many two-letter abbreviations!

Does "shitty" really need a default abbreviation, let alone a 2 letter one? It's already a quite short dictionary word which is easy to type and recognize.

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

#147

Post by rdslw »

pg83 wrote: post #92
grg0 wrote: post #86

Earlier quoted context omitted.

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

these days on HN, if you oppose someone, you get dead-flagged.

I vouched for your comment, as I find it perfectly 'not agreeing' answer.

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

#148

Post by zamadatix »

functionmouse wrote: post #9
pg83 wrote: post #8

Earlier quoted context omitted.

I know, but there aren't that many two-letter abbreviations!

on one hand I wanna say you shouldn't make conflicting names on the other hand what gives them the right to st but not you?

st both gains more from the abbreviation plus put it into use first and even then I'm not sure it really needs to be 2 letter either.

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

#149

Post by rdslw »

It is still slow.

Honestly I do not understand those last ten years craziness about 'new-native-gpu-turbo-ultra-xhigh-max-terminal' .

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

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

#150

Post by the_onion_hater »

tdeck wrote: post #121
nine_k wrote: post #72

Earlier quoted context omitted.

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.

I have reduced build times of Java projects on our Jenkins CI by half (like from 15min to 7min) just by disabling extra logging the application did during tests. Logs can be real slow.
Post reply on HN