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

Alacritty – A fast, cross-platform, OpenGL terminal emulator

github.com

Post reply on HN
Print view View original

71–80 of 174 posts

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#71

Post by lupusreal »

Shorel wrote: post #34

Modern terminal emulators not being compatible with the TERM environment variable seems insane to me. Yes, it can be unreliable at first, when your software is new. This is expected, and it changes when people start using your software. But if you don't implement compatibility with this env variable, then you are the reason it will not be reliable in any point in the future.

But... Alacritty does support and use the TERM variable. What you talking about? TERM should be set to alacritty, which has been in terminfo for years.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#72

Post by barmic12 »

5e92cb50239222b wrote: post #50
squigz wrote: post #42

What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?

I only really notice it when accidentally catting a really large file. Although I prefer kitty, any of these modern terminal emulators just rip through megabytes of text in less than a second, while in older ones you have to wait for half a minute or just sigkill them.

Each time I see a new "fast" terminal emulator I bench it with my only way to do it (`time cat large-text-file`) and urxvt is really quicker than other.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#73

Post by datadeft »

squigz wrote: post #42

What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?

You can ask these questions about pretty much every single performance improvement project. At the end there is always a win:

- cost (this is more relevant to large scale infra perf opt)

- UX (this is what a fast terminal might be achieving)

- energy efficiency (because energy is super cheap these are often overlooked, however battery life might be still relevant)

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#74

Post by sudo_chmod777 »

skywal_l wrote: post #67
aumerle wrote: post #66

Earlier quoted context omitted.

Nope, that's an update notification not an update. And its opt-in if you use kitty via a distribution package and opt-out if you use the standalone kitty binaries distributed by the developer. See https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.update_check...

Funny, I always use the binaries distributed by the developers whenever I can thinking that the less intermediaries the better. Maybe I need to revise that position.

That's... quite a Windows mindset.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#75

Post by gorgoiler »

bjoli wrote: post #30

It says to use a multiplexer for tabs and splits, but doesn't that negate some of the performance claims? Tmux and screen are pretty notorious for slowing things down.

Oh that’s very interesting to hear about tmux increasing latency. I’ve not heard this before but now you mention it, it seems obvious. Could you elaborate?

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#76

Post by lupusreal »

skywal_l wrote: post #67
aumerle wrote: post #66

Earlier quoted context omitted.

Nope, that's an update notification not an update. And its opt-in if you use kitty via a distribution package and opt-out if you use the standalone kitty binaries distributed by the developer. See https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.update_check...

Funny, I always use the binaries distributed by the developers whenever I can thinking that the less intermediaries the better. Maybe I need to revise that position.

Malicious distro packagers are virtually unheard of, and another set of eyes on the software is generally better. For instance, if the developer sells out the packager can save your bacon. This is especially true on Android where selling out is more common (see: the Simple Apps situation and F-Droid) but also a valid consideration on desktop Linux.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#77

Post by pleasecalllater »

rsp1984 wrote: post #46

At the risk of missing something completely obvious: where's the "emulator" part in it? What is it emulating? It looks like a terminal (no emulator) to me. Not trolling, just trying to learn.

This is a terminal https://en.wikipedia.org/wiki/Computer_terminal#/media/File:...

The software is just emulating the terminal behavior.

https://en.wikipedia.org/wiki/Computer_terminal

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#79

Post by jnsaff2 »

datadeft wrote: post #73
squigz wrote: post #42

What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?

You can ask these questions about pretty much every single performance improvement project. At the end there is always a win: - cost (this is more relevant to large scale infra perf opt) - UX (this is what a fast terminal might be achieving) - energy efficiency (because energy is super cheap these are often overlooked, however battery life might be still relevant)

> energy efficiency

I care about energy efficiency deeply. But in a terminal? You can't be serious.

Each terminal is in the end tied to a single person so there is no runaway scaling of instances possible. Your win in energy consumption is in the single digit watt-hours per person.

One could probably compare the energy savings coming from the terminal rendering to the extra energy consumed by the developer trying to improve performance and it might turn out to be a wash.

As for the perception of speed by people using the terminal. I too am very puzzled how this is different from audiophile movement where people claim to perceive minuscule differences in THD whatever metric they focus on today.

It might be that I've been working over dial-up sessions and intercontinental ssh sessions and the perception of slow starts to creep in when RTT gets to 100ms range. Which is probably orders of magnitude worse and more limiting than the difference between kitty and alacritty.

Re: Alacritty – A fast, cross-platform, OpenGL terminal emulator

#80

Post by berkes »

datadeft wrote: post #73
squigz wrote: post #42

What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?

You can ask these questions about pretty much every single performance improvement project. At the end there is always a win: - cost (this is more relevant to large scale infra perf opt) - UX (this is what a fast terminal might be achieving) - energy efficiency (because energy is super cheap these are often overlooked, however battery life might be still relevant)

> energy efficiency

I highly doubt that offloading the rendering to a GPU is more energy efficient. I'm quite sure it's the exact opposite: GPUs are power hungry energy-eaters; commonly.

Post reply on HN