Live data from Hacker News

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

github.com

81–90 of 168 posts

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

#81
post #79

Earlier quoted context omitted.

The name screams for attention, so of course it's on topic. I made no appeal to authority, just maturity.

They aren't asking for money or literally anything from you, it's just someone's project with a silly name.

They're asking us to engage and try it, that's what ShowHN is.

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

#82
post #70

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

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…

lol fuck this guy, the name and branding are awesome dude

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

#83

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…

There was also the video where he did write the doctoral research project in a weekend.

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

#84
post #70

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

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…

How much of it was written by AI?

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

#85
post #76

Earlier quoted context omitted.

[flagged]

> The moronic naming immediately undermines that claim. It's quite obvious to me that professionalism in product manufacturing correlates very weakly with naming :) Proof me wrong.

Nothing else on any market called “shitty” that I’ve ever seen, and if I had, I would avoid it.

Any sales or marketing person will gladly tell you how bad an idea it is to use this name. “Shitty” is slang for “terrible quality”, for one.

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

#86
post #62

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.

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.

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

#87

> 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 free. No. Expecting that is batshit insane.

If someone forks this, changes it, and doesn’t release their changes, this still exists. Nothing is lost.

When something is released under MIT, it is “released”. When GPL software is released, it “binds” anyone that works on it, adding requirements to the entity doing the work. I.e. not free.

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

#88
post #70

Earlier quoted context omitted.

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…

How much of it was written by AI?

If we are talking about the process of direct code production according to a given specification, then 100%.

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

#89

Excellent use of Ragel to generate fast state machines. Everyone should check it out: https://www.colm.net/open-source/ragel/ The author of shitty encoded the whole terminal state machine in Ragel: https://github.com/pg83/shitty/blob/master/parser.rl The thing generates one of big DFA with actions for everything that can ever happen in the terminal. Precisely correct way to do it. Plus, Ragel is a joy to program once…

I'm glad someone noticed this, but ragel is a very niche tool; few people have heard of it! I believe my parser is the first complete description of a terminal output parser in FSM form, and that alone is quite valuable.

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

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

Post reply on HN