- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
Render anything inline. Save sessions and history. Powered by open web standards.
I’m trying it, and it does looks nice.
Render anything inline. Save sessions and history. Powered by open web standards.
I’m trying it, and it does looks nice.
I never understand the whole thing around “fast” terminals. How can a terminal be “slow”? Surely the terminal you’re using has no effect on the programs you’re calling, so what’s being measured here?
I get what you mean, it is an interesting question to explore.
For me, it think it appeals to my obsessive engineer-brain, I am hooked on chasing efficiency.
Eg, if one tool uses 10MB ram and takes 1second to complete a task, and another tool takes 50MB ram and 5 seconds to complete the same task, then clearly I want to use the more efficient one. The other must be wasting resources, right?
When it comes to real life software and real tasks, it is a lot more complicated than that, there are hundreds of variables to take into account and compare. But if one tool stands out among the others, optimising to achieve the best number (fastest time, lowest power draw, lowest ram use, etc) in each comparable variable, then I absolutely must use that one, it would be irresponsible not to, right?
Throw hardware acceleration into the mix, and it takes the situation to a new level. Why make my poor CPU render the text on the screen 60 times per second, when I can get the GPU to do it? It’s just sitting there doing nothing, and it’s better at the job anyway, and as a bonus you get even lower CPU utilisation and lower ram usage.
However, as I described in my previous post, chasing these numbers can come at the cost of usability. That’s the case with Alacritty, and why I will be switching to wezterm.
The very few times your programs end up spamming a ton to stdout I guess